Generate TypeScript MCP Server

Create a complete Model Context Protocol (MCP) server in TypeScript using the MCP TypeScript SDK v2 with the following specifications:

Implementation Details

Project Setup

• Initialize with npm init and create package.json
• Install dependencies: @modelcontextprotocol/server, zod@^4.2, and the transport package — @modelcontextprotocol/node for plain Node HTTP, or a framework adapter together with its peer framework (e.g. npm install @modelcontextprotocol/express express)
• Configure TypeScript with ES modules: "type": "module" in package.json
• Add dev dependencies: tsx or ts-node for development
• Create proper .gitignore file

Server Configuration

• Use McpServer class from @modelcontextprotocol/server for high-level implementation
• Set server name and version
• Choose the appropriate transport:
  • HTTP (Node): NodeStreamableHTTPServerTransport from @modelcontextprotocol/node
  • HTTP (Web Standard runtimes): WebStandardStreamableHTTPServerTransport from @modelcontextprotocol/server
  • stdio: StdioServerTransport from @modelcontextprotocol/server/stdio
• For HTTP: prefer a framework adapter (@modelcontextprotocol/express, etc.) with proper middleware and error handling
• Note that v2 uses Web Standard Headers/Request types; read headers with ctx.http?.req?.headers.get('x-custom')

Tool Implementation

• Use registerTool() with a config object — v1 variadic .tool() signatures are gone:
  Copy

  server.registerTool('greet', {
    description: 'Greet user',
    inputSchema: z.object({ name: z.string() })
  }, async ({ name }, ctx) => {
    return { content: [{ type: 'text', text: `Hello, ${name}!` }] };
  });

• Schemas must be full Zod objects (z.object({...})) — raw shape objects ({ name: z.string() }) are deprecated
• Provide clear title and description fields
• Return both content and structuredContent in results
• The handler's second parameter is a structured ctx object (replaces v1 extra): ctx.mcpReq.signal, ctx.mcpReq.id, ctx.mcpReq.send(...), ctx.mcpReq.notify(...)
• Implement proper error handling with try-catch blocks; use the v2 error hierarchy (ProtocolError, SdkError, SdkHttpError with .status) instead of v1 McpError/StreamableHTTPError
• Support async operations where appropriate

Resource/Prompt Setup (Optional)

• Add resources using registerResource() with ResourceTemplate for dynamic URIs
• Add prompts using registerPrompt() with argument schemas (same config-object style as registerTool())
• Consider adding completion support for better UX; note the v2 completable() wrapper order: completable(z.string(), callback).optional() (optional applied outside)

Code Quality

• Use TypeScript for type safety
• Follow async/await patterns consistently
• Implement proper cleanup on transport close events
• Use environment variables for configuration
• Add inline comments for complex logic
• Structure code with clear separation of concerns

Example Tool Types to Consider

• Data processing and transformation
• External API integrations
• File system operations (read, search, analyze)
• Database queries
• Text analysis or summarization (LLM-assisted via the multi-round input_required pattern)
• System information retrieval

Migrating an Existing v1 Server

• Run the official codemod first: npx @modelcontextprotocol/codemod@latest v1-to-v2 .
• Then search for @mcp-codemod-error markers for the parts requiring manual judgment (transport choice, header reads, error classification)
• Swap McpError + ErrorCode checks for the new error classes; HTTP status now lives on error.status, not error.code
• Server.createMessage(), listRoots(), sendLoggingMessage() and the roots/sampling/logging capability fields are deprecated in v2 — avoid them in new code

Testing Guidance

• Explain how to run the server (npm start or npx tsx server.ts)
• Provide MCP Inspector command: npx @modelcontextprotocol/inspector
• For HTTP servers, include connection URL: http://localhost:PORT/mcp
• Include example tool invocations
• Add troubleshooting tips for common issues

Additional Features to Consider

• LLM-powered tools using the multi-round input_required pattern (the v2 replacement for the deprecated sampling subsystem)
• User input elicitation for interactive workflows
• Dynamic tool registration with enable/disable capabilities
• Notification debouncing for bulk updates
• Resource links for efficient data references

Generate a complete, production-ready MCP server with comprehensive documentation, type safety, and error handling.

Requirements

1. Project Structure: Create a new TypeScript/Node.js project with proper directory structure
2. NPM Packages: The v1 monolithic @modelcontextprotocol/sdk package is retired. Use the focused v2 packages:
   • @modelcontextprotocol/server — server implementation (stdio transport via the @modelcontextprotocol/server/stdio subpath)
   • @modelcontextprotocol/node — Node HTTP transport (NodeStreamableHTTPServerTransport), or a framework adapter: @modelcontextprotocol/express, @modelcontextprotocol/hono, @modelcontextprotocol/fastify — each adapter requires its peer framework to be installed alongside it (e.g. @modelcontextprotocol/express + express)
   • @modelcontextprotocol/core — shared protocol schemas (import *Schema constants from here, not from sdk/types.js)
   • zod@^4.2 — v2 requires Zod 4.2+; do not use zod@3
3. Runtime: Node.js 20+ (v2 minimum); ESM-first with "type": "module" (a CommonJS build is also shipped, so require() works if needed)
4. Server Type: Choose between HTTP (Streamable HTTP transport) or stdio-based server. SSE and WebSocket transports were removed in v2 — do not generate them.
5. Tools: Create at least one useful tool with proper schema validation
6. Error Handling: Include comprehensive error handling and validation

Configuration Options

• For HTTP Servers:

  • Port configuration via environment variables
  • CORS setup for browser clients
  • Session management (stateless vs stateful)
  • DNS rebinding protection for local servers
  • Strict Content-Type handling: v2 rejects non-application/json POST bodies

• For stdio Servers:

  • Proper stdin/stdout handling
  • Environment-based configuration
  • Process lifecycle management