typescript-sdk Documentation

1. Project Overview & Quickstart (modelcontextprotocol/typescript-sdk) Copy Chapter

File: README.md Copy Chapter

MCP TypeScript SDK

[!IMPORTANT]
This is the main branch — v2 of the SDK (@modelcontextprotocol/server, @modelcontextprotocol/client), implementing the 2026-07-28 MCP spec.

Have feedback? Please open a v2 issue — it is the most useful thing you can do for the SDK right now. The v2 documentation starts with a ten-minute server tutorial.

v2 is the stable release line, released alongside the 2026-07-28 spec. v1.x continues to receive bug fixes and security updates for at least 6 months after v2's release. v1 documentation: ts.sdk.modelcontextprotocol.io · v2: /v2/.

[!WARNING]
We're limiting pull requests to 1 per new contributor while v2 settles after the 2026-07-28 spec release.

Issues are the most useful feedback right now — we'll reopen PRs as v2 stabilizes.

Table of Contents

• Overview
• Packages
• Installation
• Getting Started
• Documentation
• Contributing
• License

Overview Copy Chapter

The Model Context Protocol (MCP) allows applications to provide context for LLMs in a standardized way, separating the concerns of providing context from the actual LLM interaction.

This repository contains the TypeScript SDK implementation of the MCP specification. It runs on Node.js, Bun, and Deno, and ships:

• MCP server libraries (tools/resources/prompts, Streamable HTTP, stdio, auth helpers)
• MCP client libraries (transports, high-level helpers, OAuth helpers)
• Optional middleware packages for specific runtimes/frameworks (Express, Fastify, Hono, Node.js HTTP)
• Runnable examples (under examples/)

Packages Copy Chapter

This monorepo publishes split packages:

• @modelcontextprotocol/server: build MCP servers
• @modelcontextprotocol/client: build MCP clients

Tool and prompt schemas use Standard Schema — bring Zod v4, Valibot, ArkType, or any compatible library.

Middleware packages (optional) Copy Section

The SDK also publishes small "middleware" packages under packages/middleware/ that help you wire MCP into a specific runtime or web framework.

They are intentionally thin adapters: they should not introduce new MCP functionality or business logic. See packages/middleware/README.md for details.

• @modelcontextprotocol/node: Node.js Streamable HTTP transport wrapper for IncomingMessage / ServerResponse
• @modelcontextprotocol/express: Express helpers (app defaults + Host header validation)
• @modelcontextprotocol/fastify: Fastify helpers (app defaults + Host header validation)
• @modelcontextprotocol/hono: Hono helpers (app defaults + JSON body parsing hook + Host header validation)

Installation Copy Chapter

Server Copy Section

npm install @modelcontextprotocol/server
# or
bun add @modelcontextprotocol/server
# or
deno add npm:@modelcontextprotocol/server

Client Copy Section

npm install @modelcontextprotocol/client
# or
bun add @modelcontextprotocol/client
# or
deno add npm:@modelcontextprotocol/client

Optional middleware packages Copy Section

The SDK also publishes optional “middleware” packages that help you wire MCP into a specific runtime or web framework (for example Express, Fastify, Hono, or Node.js http).

These packages are intentionally thin adapters and should not introduce additional MCP features or business logic. See packages/middleware/README.md for details.

# Node.js HTTP (IncomingMessage/ServerResponse) Streamable HTTP transport:
npm install @modelcontextprotocol/node

# Express integration:
npm install @modelcontextprotocol/express express

# Fastify integration:
npm install @modelcontextprotocol/fastify fastify

# Hono integration:
npm install @modelcontextprotocol/hono hono

Getting Started Copy Chapter

Here is what an MCP server looks like. This minimal example exposes a single greet tool over stdio:

import { McpServer } from '@modelcontextprotocol/server';
import { StdioServerTransport } from '@modelcontextprotocol/server/stdio';
import * as z from 'zod/v4';

const server = new McpServer({ name: 'greeting-server', version: '1.0.0' });

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

async function main() {
    const transport = new StdioServerTransport();
    await server.connect(transport);
}

main();

Ready to build something real? Follow the step-by-step tutorials:

• Build your first server — a stdio weather-alert server, from npm init to a tool call
• Build your first client — connect to that server, list its tools, and call them

For runnable, end-to-end examples beyond the tutorials, see:

• examples/README.md — runnable, self-verifying client/server example pairs (one story per directory)

Documentation Copy Chapter

• Build a server — your first MCP server, step by step
• Build a client — your first MCP client, step by step
• Documentation site — the full guides: tools, resources, prompts, serving over HTTP and stdio, clients, OAuth, and migration
• Troubleshooting — common errors and their fixes
• API reference
• MCP documentation
• MCP specification

Building docs locally Copy Section

To work on the documentation site locally:

pnpm docs:api      # Generate the API reference markdown (output: docs/api/)
pnpm docs:dev      # Start the VitePress dev server for the V2 site
pnpm docs:build    # Build the V2 site (output: docs/.vitepress/dist/)
pnpm docs:multi    # Build the combined V1 + V2 site (output: tmp/docs-combined/)

The docs:multi script builds the V2 site from the current checkout, checks out the v1.x branch via a git worktree to build the V1 site, and produces a combined site with V1 docs at the root and V2 docs under /v2/.

v1 (legacy) documentation and fixes Copy Chapter

If you are using the v1 generation of the SDK, the v1 API documentation is available at https://ts.sdk.modelcontextprotocol.io/. The v1 source code and any v1-specific fixes live on the long-lived
v1.x branch. V2 API docs are at /v2/.

Contributing Copy Chapter

Issues and pull requests are welcome on GitHub at https://github.com/modelcontextprotocol/typescript-sdk.

License Copy Chapter

This project is licensed under the Apache License 2.0 for new contributions, with existing code under MIT. See the LICENSE file for details.

File: docs/index.md Copy Chapter

shape: landing Copy Chapter

MCP TypeScript SDK

::: info v2
This is the documentation for v2 of the SDK, the stable release line implementing the 2026-07-28 spec. Report issues — and if you need v1, its documentation is at ts.sdk.modelcontextprotocol.io.
:::

The Model Context Protocol (MCP) is an open standard that connects AI applications to the systems where your data and tools live. You write a server that exposes tools, resources, and prompts; any MCP host — Claude Code, VS Code, Cursor, your own application — connects to it and lets a model use them. The protocol is defined by the MCP specification; this SDK is its TypeScript implementation, on Node.js, Bun, and Deno.

A complete server is one file:

import { McpServer } from '@modelcontextprotocol/server';
import { serveStdio } from '@modelcontextprotocol/server/stdio';
import * as z from 'zod/v4';

serveStdio(() => {
    const server = new McpServer({ name: 'weather', version: '1.0.0' });

    server.registerTool(
        'get-forecast',
        {
            inputSchema: z.object({ city: z.string() })
        },
        async ({ city }) => ({
            content: [{ type: 'text', text: `Sunny in ${city} all week.` }]
        })
    );

    return server;
});

Any MCP host that launches this program lists and calls get-forecast; the SDK validates every call against that z.object(...) schema before your handler runs. Build a server installs the packages and runs it end to end.

Pick a path Copy Chapter

• Expose your API or data to AI applications → Build a server
• Build an application that talks to MCP servers → Build a client
• Coming from v1 (@modelcontextprotocol/sdk) → Upgrade
• Drop MCP into the app you already run → Express · Hono · Fastify · Workers

For exact signatures, go to the API reference.

Recap Copy Chapter

• MCP connects AI applications to the systems where your tools and data live; you build one side, a host brings the model.
• registerTool(name, config, handler) with a z.object(...) inputSchema defines a tool; serveStdio serves it over stdio.
• Four starting points: build a server, build a client, upgrade from v1, or drop into Express, Hono, Fastify, or Workers.

2. Official Technical Reference & Guides (modelcontextprotocol/docs) Copy Chapter

File: README.md Copy Chapter

Model Context Protocol documentation

This documentation has moved to modelcontextprotocol/modelcontextprotocol.

Please file issues and pull requests for documentation changes there.

File: docs/tools/debugging.mdx Copy Chapter

title: Debugging Copy Chapter

Effective debugging is essential when developing MCP servers or integrating them with applications. This guide covers the debugging tools and approaches available in the MCP ecosystem.

This guide is for macOS. Guides for other platforms are coming soon.

Debugging tools overview Copy Chapter

MCP provides several tools for debugging at different levels:

1. MCP Inspector

   • Interactive debugging interface
   • Direct server testing
   • See the Inspector guide for details

2. Claude Desktop Developer Tools

   • Integration testing
   • Log collection
   • Chrome DevTools integration

3. Server Logging

   • Custom logging implementations
   • Error tracking
   • Performance monitoring

Debugging in Claude Desktop Copy Chapter

Checking server status Copy Section

The Claude.app interface provides basic server status information:

1. Click the icon to view:

   • Connected servers
   • Available prompts and resources

2. Click the icon to view:

   • Tools made available to the model

Viewing logs Copy Section

Review detailed MCP logs from Claude Desktop:

# Follow logs in real-time
tail -n 20 -F ~/Library/Logs/Claude/mcp*.log

The logs capture:

• Server connection events
• Configuration issues
• Runtime errors
• Message exchanges

Using Chrome DevTools Copy Section

Access Chrome's developer tools inside Claude Desktop to investigate client-side errors:

1. Create a developer_settings.json file with allowDevTools set to true:

echo '{"allowDevTools": true}' > ~/Library/Application\ Support/Claude/developer_settings.json

2. Open DevTools: Command-Option-Shift-i

Note: You'll see two DevTools windows:

• Main content window
• App title bar window

Use the Console panel to inspect client-side errors.

Use the Network panel to inspect:

• Message payloads
• Connection timing

Common issues Copy Chapter

Working directory Copy Section

When using MCP servers with Claude Desktop:

• The working directory for servers launched via claude_desktop_config.json may be undefined (like / on macOS) since Claude Desktop could be started from anywhere
• Always use absolute paths in your configuration and .env files to ensure reliable operation
• For testing servers directly via command line, the working directory will be where you run the command

For example in claude_desktop_config.json, use:

{
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/username/data"]
}

Instead of relative paths like ./data

Environment variables Copy Section

MCP servers inherit only a subset of environment variables automatically, like USER, HOME, and PATH.

To override the default variables or provide your own, you can specify an env key in claude_desktop_config.json:

{
  "myserver": {
    "command": "mcp-server-myapp",
    "env": {
      "MYAPP_API_KEY": "some_key",
    }
  }
}

Server initialization Copy Section

Common initialization problems:

1. Path Issues

   • Incorrect server executable path
   • Missing required files
   • Permission problems
   • Try using an absolute path for command

2. Configuration Errors

   • Invalid JSON syntax
   • Missing required fields
   • Type mismatches

3. Environment Problems

   • Missing environment variables
   • Incorrect variable values
   • Permission restrictions

Connection problems Copy Section

When servers fail to connect:

1. Check Claude Desktop logs
2. Verify server process is running
3. Test standalone with Inspector
4. Verify protocol compatibility

Implementing logging Copy Chapter

Server-side logging Copy Section

When building a server that uses the local stdio transport, all messages logged to stderr (standard error) will be captured by the host application (e.g., Claude Desktop) automatically.

For all transports, you can also provide logging to the client by sending a log message notification:

Important events to log:

• Initialization steps
• Resource access
• Tool execution
• Error conditions
• Performance metrics

Client-side logging Copy Section

In client applications:

1. Enable debug logging
2. Monitor network traffic
3. Track message exchanges
4. Record error states

Debugging workflow Copy Chapter

Development cycle Copy Section

1. Initial Development

   • Use Inspector for basic testing
   • Implement core functionality
   • Add logging points

2. Integration Testing

   • Test in Claude Desktop
   • Monitor logs
   • Check error handling

Testing changes Copy Section

To test changes efficiently:

• Configuration changes: Restart Claude Desktop
• Server code changes: Use Command-R to reload
• Quick iteration: Use Inspector during development

Best practices Copy Chapter

Logging strategy Copy Section

1. Structured Logging

   • Use consistent formats
   • Include context
   • Add timestamps
   • Track request IDs

2. Error Handling

   • Log stack traces
   • Include error context
   • Track error patterns
   • Monitor recovery

3. Performance Tracking

   • Log operation timing
   • Monitor resource usage
   • Track message sizes
   • Measure latency

Security considerations Copy Section

When debugging:

1. Sensitive Data

   • Sanitize logs
   • Protect credentials
   • Mask personal information

2. Access Control

   • Verify permissions
   • Check authentication
   • Monitor access patterns

Getting help Copy Chapter

When encountering issues:

1. First Steps

   • Check server logs
   • Test with Inspector
   • Review configuration
   • Verify environment

2. Support Channels

   • GitHub issues
   • GitHub discussions

3. Providing Information

   • Log excerpts
   • Configuration files
   • Steps to reproduce
   • Environment details

Next steps Copy Chapter

File: docs/tools/inspector.mdx Copy Chapter

title: Inspector Copy Chapter

The MCP Inspector is an interactive developer tool for testing and debugging MCP servers. While the Debugging Guide covers the Inspector as part of the overall debugging toolkit, this document provides a detailed exploration of the Inspector's features and capabilities.

Getting started Copy Chapter

Installation and basic usage Copy Section

The Inspector runs directly through npx without requiring installation:

npx @modelcontextprotocol/inspector <command>

npx @modelcontextprotocol/inspector <command> <arg1> <arg2>

Inspecting servers from NPM or PyPi

A common way to start server packages from NPM or PyPi.

Inspecting locally developed servers

To inspect servers locally developed or downloaded as a repository, the most common
way is:

Please carefully read any attached README for the most accurate instructions.

Feature overview Copy Chapter

The Inspector provides several features for interacting with your MCP server:

Server connection pane Copy Section

• Allows selecting the transport for connecting to the server
• For local servers, supports customizing the command-line arguments and environment

Resources tab Copy Section

• Lists all available resources
• Shows resource metadata (MIME types, descriptions)
• Allows resource content inspection
• Supports subscription testing

Prompts tab Copy Section

• Displays available prompt templates
• Shows prompt arguments and descriptions
• Enables prompt testing with custom arguments
• Previews generated messages

Tools tab Copy Section

• Lists available tools
• Shows tool schemas and descriptions
• Enables tool testing with custom inputs
• Displays tool execution results

Notifications pane Copy Section

• Presents all logs recorded from the server
• Shows notifications received from the server

Best practices Copy Chapter

Development workflow Copy Section

1. Start Development

   • Launch Inspector with your server
   • Verify basic connectivity
   • Check capability negotiation

2. Iterative testing

   • Make server changes
   • Rebuild the server
   • Reconnect the Inspector
   • Test affected features
   • Monitor messages

3. Test edge cases

   • Invalid inputs
   • Missing prompt arguments
   • Concurrent operations
   • Verify error handling and error responses

Next steps Copy Chapter

<Card
    title="Debugging Guide"
    icon="bug"
    href="/docs/tools/debugging"
>
    Learn about broader debugging strategies
</Card>

File: docs/concepts/architecture.mdx Copy Chapter

title: "Core architecture" Copy Chapter

The Model Context Protocol (MCP) is built on a flexible, extensible architecture that enables seamless communication between LLM applications and integrations. This document covers the core architectural components and concepts.

Overview Copy Chapter

MCP follows a client-server architecture where:

• Hosts are LLM applications (like Claude Desktop or IDEs) that initiate connections
• Clients maintain 1:1 connections with servers, inside the host application
• Servers provide context, tools, and prompts to clients

flowchart LR
    subgraph "Host"
        client1[MCP Client]
        client2[MCP Client]
    end
    subgraph "Server Process"
        server1[MCP Server]
    end
    subgraph "Server Process"
        server2[MCP Server]
    end

    client1 <-->|Transport Layer| server1
    client2 <-->|Transport Layer| server2

Core components Copy Chapter

Protocol layer Copy Section

The protocol layer handles message framing, request/response linking, and high-level communication patterns.

// Handle incoming notifications
    setNotificationHandler<T>(schema: T, handler: (notification: T) => Promise<void>): void

    // Send requests and await responses
    request<T>(request: Request, schema: T, options?: RequestOptions): Promise<T>

    // Send one-way notifications
    notification(notification: Notification): Promise<void>
}
```

async def send_notification(
        self,
        notification: NotificationT
    ) -> None:
        """Send one-way notification that doesn't expect response."""
        # Notification handling implementation

    async def _received_request(
        self,
        responder: RequestResponder[ReceiveRequestT, ResultT]
    ) -> None:
        """Handle incoming request from other side."""
        # Request handling implementation

    async def _received_notification(
        self,
        notification: ReceiveNotificationT
    ) -> None:
        """Handle incoming notification from other side."""
        # Notification handling implementation
```

Key classes include:

• Protocol
• Client
• Server

Transport layer Copy Section

The transport layer handles the actual communication between clients and servers. MCP supports multiple transport mechanisms:

1. Stdio transport

   • Uses standard input/output for communication
   • Ideal for local processes

2. HTTP with SSE transport

   • Uses Server-Sent Events for server-to-client messages
   • HTTP POST for client-to-server messages

All transports use JSON-RPC 2.0 to exchange messages. See the specification for detailed information about the Model Context Protocol message format.

Message types Copy Section

MCP has these main types of messages:

1. Requests expect a response from the other side:

   typescript Copy

   interface Request {
     method: string;
     params?: { ... };
   }

2. Results are successful responses to requests:

   typescript Copy

   interface Result {
     [key: string]: unknown;
   }

3. Errors indicate that a request failed:

   typescript Copy

   interface Error {
     code: number;
     message: string;
     data?: unknown;
   }

4. Notifications are one-way messages that don't expect a response:

   typescript Copy

   interface Notification {
     method: string;
     params?: { ... };
   }

Connection lifecycle Copy Chapter

1. Initialization Copy Section

sequenceDiagram
    participant Client
    participant Server

    Client->>Server: initialize request
    Server->>Client: initialize response
    Client->>Server: initialized notification

    Note over Client,Server: Connection ready for use

1. Client sends initialize request with protocol version and capabilities
2. Server responds with its protocol version and capabilities
3. Client sends initialized notification as acknowledgment
4. Normal message exchange begins

2. Message exchange Copy Section

After initialization, the following patterns are supported:

• Request-Response: Client or server sends requests, the other responds
• Notifications: Either party sends one-way messages

3. Termination Copy Section

Either party can terminate the connection:

• Clean shutdown via close()
• Transport disconnection
• Error conditions

Error handling Copy Chapter

MCP defines these standard error codes:

enum ErrorCode {
  // Standard JSON-RPC error codes
  ParseError = -32700,
  InvalidRequest = -32600,
  MethodNotFound = -32601,
  InvalidParams = -32602,
  InternalError = -32603
}

SDKs and applications can define their own error codes above -32000.

Errors are propagated through:

• Error responses to requests
• Error events on transports
• Protocol-level error handlers

Implementation example Copy Chapter

Here's a basic example of implementing an MCP server:

const server = new Server({
  name: "example-server",
  version: "1.0.0"
}, {
  capabilities: {
    resources: {}
  }
});

// Handle requests
server.setRequestHandler(ListResourcesRequestSchema, async () => {
  return {
    resources: [
      {
        uri: "example://resource",
        name: "Example Resource"
      }
    ]
  };
});

// Connect transport
const transport = new StdioServerTransport();
await server.connect(transport);
```

app = Server("example-server")

@app.list_resources()
async def list_resources() -> list[types.Resource]:
    return [
        types.Resource(
            uri="example://resource",
            name="Example Resource"
        )
    ]

async def main():
    async with stdio_server() as streams:
        await app.run(
            streams[0],
            streams[1],
            app.create_initialization_options()
        )

if __name__ == "__main__":
    asyncio.run(main())
```

Best practices Copy Chapter

Transport selection Copy Section

1. Local communication

   • Use stdio transport for local processes
   • Efficient for same-machine communication
   • Simple process management

2. Remote communication

   • Use SSE for scenarios requiring HTTP compatibility
   • Consider security implications including authentication and authorization

Message handling Copy Section

1. Request processing

   • Validate inputs thoroughly
   • Use type-safe schemas
   • Handle errors gracefully
   • Implement timeouts

2. Progress reporting

   • Use progress tokens for long operations
   • Report progress incrementally
   • Include total progress when known

3. Error management

   • Use appropriate error codes
   • Include helpful error messages
   • Clean up resources on errors

Security considerations Copy Chapter

1. Transport security

   • Use TLS for remote connections
   • Validate connection origins
   • Implement authentication when needed

2. Message validation

   • Validate all incoming messages
   • Sanitize inputs
   • Check message size limits
   • Verify JSON-RPC format

3. Resource protection

   • Implement access controls
   • Validate resource paths
   • Monitor resource usage
   • Rate limit requests

4. Error handling

   • Don't leak sensitive information
   • Log security-relevant errors
   • Implement proper cleanup
   • Handle DoS scenarios

Debugging and monitoring Copy Chapter

1. Logging

   • Log protocol events
   • Track message flow
   • Monitor performance
   • Record errors

2. Diagnostics

   • Implement health checks
   • Monitor connection state
   • Track resource usage
   • Profile performance

3. Testing

   • Test different transports
   • Verify error handling
   • Check edge cases
   • Load test servers

File: docs/concepts/prompts.mdx Copy Chapter

title: "Prompts" Copy Chapter

Prompts enable servers to define reusable prompt templates and workflows that clients can easily surface to users and LLMs. They provide a powerful way to standardize and share common LLM interactions.

Overview Copy Chapter

Prompts in MCP are predefined templates that can:

• Accept dynamic arguments
• Include context from resources
• Chain multiple interactions
• Guide specific workflows
• Surface as UI elements (like slash commands)

Prompt structure Copy Chapter

Each prompt is defined with:

{
  name: string;              // Unique identifier for the prompt
  description?: string;      // Human-readable description
  arguments?: [              // Optional list of arguments
    {
      name: string;          // Argument identifier
      description?: string;  // Argument description
      required?: boolean;    // Whether argument is required
    }
  ]
}

Discovering prompts Copy Chapter

Clients can discover available prompts through the prompts/list endpoint:

// Request
{
  method: "prompts/list"
}

// Response
{
  prompts: [
    {
      name: "analyze-code",
      arguments: [
        {
          name: "language",
          required: true
        }
      ]
    }
  ]
}

Using prompts Copy Chapter

To use a prompt, clients make a prompts/get request:

// Request
{
  method: "prompts/get",
  params: {
    name: "analyze-code",
    arguments: {
      language: "python"
    }
  }
}

// Response
{
  messages: [
    {
      role: "user",
      content: {
        type: "text",
        text: "Please analyze the following Python code for potential improvements:\n\n```python\ndef calculate_sum(numbers):\n    total = 0\n    for num in numbers:\n        total = total + num\n    return total\n\nresult = calculate_sum([1, 2, 3, 4, 5])\nprint(result)\n```"
      }
    }
  ]
}

Dynamic prompts Copy Chapter

Prompts can be dynamic and include:

Embedded resource context Copy Section

{
  "name": "analyze-project",
  "description": "Analyze project logs and code",
  "arguments": [
    {
      "name": "timeframe",
      "description": "Time period to analyze logs",
      "required": true
    },
    {
      "name": "fileUri",
      "description": "URI of code file to review",
      "required": true
    }
  ]
}

When handling the prompts/get request:

{
  "messages": [
    {
      "role": "user",
      "content": {
        "type": "text",
        "text": "Analyze these system logs and the code file for any issues:"
      }
    },
    {
      "role": "user",
      "content": {
        "type": "resource",
        "resource": {
          "uri": "logs://recent?timeframe=1h",
          "text": "[2024-03-14 15:32:11] ERROR: Connection timeout in network.py:127\n[2024-03-14 15:32:15] WARN: Retrying connection (attempt 2/3)\n[2024-03-14 15:32:20] ERROR: Max retries exceeded",
          "mimeType": "text/plain"
        }
      }
    },
    {
      "role": "user",
      "content": {
        "type": "resource",
        "resource": {
          "uri": "file:///path/to/code.py",
          "text": "def connect_to_service(timeout=30):\n    retries = 3\n    for attempt in range(retries):\n        try:\n            return establish_connection(timeout)\n        except TimeoutError:\n            if attempt == retries - 1:\n                raise\n            time.sleep(5)\n\ndef establish_connection(timeout):\n    # Connection implementation\n    pass",
          "mimeType": "text/x-python"
        }
      }
    }
  ]
}

Multi-step workflows Copy Section

const debugWorkflow = {
  name: "debug-error",
  async getMessages(error: string) {
    return [
      {
        role: "user",
        content: {
          type: "text",
          text: `Here's an error I'm seeing: ${error}`
        }
      },
      {
        role: "assistant",
        content: {
          type: "text",
          text: "I'll help analyze this error. What have you tried so far?"
        }
      },
      {
        role: "user",
        content: {
          type: "text",
          text: "I've tried restarting the service, but the error persists."
        }
      }
    ];
  }
};

Example implementation Copy Chapter

Here's a complete example of implementing prompts in an MCP server:

Best practices Copy Chapter

When implementing prompts:

1. Use clear, descriptive prompt names
2. Provide detailed descriptions for prompts and arguments
3. Validate all required arguments
4. Handle missing arguments gracefully
5. Consider versioning for prompt templates
6. Cache dynamic content when appropriate
7. Implement error handling
8. Document expected argument formats
9. Consider prompt composability
10. Test prompts with various inputs

UI integration Copy Chapter

Prompts can be surfaced in client UIs as:

• Slash commands
• Quick actions
• Context menu items
• Command palette entries
• Guided workflows
• Interactive forms

Updates and changes Copy Chapter

Servers can notify clients about prompt changes:

1. Server capability: prompts.listChanged
2. Notification: notifications/prompts/list_changed
3. Client re-fetches prompt list

Security considerations Copy Chapter

When implementing prompts:

• Validate all arguments
• Sanitize user input
• Consider rate limiting
• Implement access controls
• Audit prompt usage
• Handle sensitive data appropriately
• Validate generated content
• Implement timeouts
• Consider prompt injection risks
• Document security requirements

File: docs/concepts/resources.mdx Copy Chapter

title: "Resources" Copy Chapter

Resources are a core primitive in the Model Context Protocol (MCP) that allow servers to expose data and content that can be read by clients and used as context for LLM interactions.

[protocol]://[host]/[path]

{
  uri: string;           // Unique identifier for the resource
  name: string;          // Human-readable name
  description?: string;  // Optional description
  mimeType?: string;     // Optional MIME type
}

{
  uriTemplate: string;   // URI template following RFC 6570
  name: string;          // Human-readable name for this type
  description?: string;  // Optional description
  mimeType?: string;     // Optional MIME type for all matching resources
}

{
  contents: [
    {
      uri: string;        // The URI of the resource
      mimeType?: string;  // Optional MIME type

      // One of:
      text?: string;      // For text resources
      blob?: string;      // For binary resources (base64 encoded)
    }
  ]
}

// List available resources
server.setRequestHandler(ListResourcesRequestSchema, async () => {
  return {
    resources: [
      {
        uri: "file:///logs/app.log",
        name: "Application Logs",
        mimeType: "text/plain"
      }
    ]
  };
});

// Read resource contents
server.setRequestHandler(ReadResourceRequestSchema, async (request) => {
  const uri = request.params.uri;

  if (uri === "file:///logs/app.log") {
    const logContents = await readLogFile();
    return {
      contents: [
        {
          uri,
          mimeType: "text/plain",
          text: logContents
        }
      ]
    };
  }

  throw new Error("Resource not found");
});
```

@app.list_resources()
async def list_resources() -> list[types.Resource]:
    return [
        types.Resource(
            uri="file:///logs/app.log",
            name="Application Logs",
            mimeType="text/plain"
        )
    ]

@app.read_resource()
async def read_resource(uri: AnyUrl) -> str:
    if str(uri) == "file:///logs/app.log":
        log_contents = await read_log_file()
        return log_contents

    raise ValueError("Resource not found")

# Start server
async with stdio_server() as streams:
    await app.run(
        streams[0],
        streams[1],
        app.create_initialization_options()
    )
```

file:///home/user/projects/myapp
https://api.example.com/v1

{
  "roots": [
    {
      "uri": "file:///home/user/projects/frontend",
      "name": "Frontend Repository"
    },
    {
      "uri": "https://api.example.com/v1",
      "name": "API Endpoint"
    }
  ]
}

{
  messages: [
    {
      role: "user" | "assistant",
      content: {
        type: "text" | "image",

        // For text:
        text?: string,

        // For images:
        data?: string,             // base64 encoded
        mimeType?: string
      }
    }
  ],
  modelPreferences?: {
    hints?: [{
      name?: string                // Suggested model name/family
    }],
    costPriority?: number,         // 0-1, importance of minimizing cost
    speedPriority?: number,        // 0-1, importance of low latency
    intelligencePriority?: number  // 0-1, importance of capabilities
  },
  systemPrompt?: string,
  includeContext?: "none" | "thisServer" | "allServers",
  temperature?: number,
  maxTokens: number,
  stopSequences?: string[],
  metadata?: Record<string, unknown>
}

{
  model: string,  // Name of the model used
  stopReason?: "endTurn" | "stopSequence" | "maxTokens" | string,
  role: "user" | "assistant",
  content: {
    type: "text" | "image",
    text?: string,
    data?: string,
    mimeType?: string
  }
}

{
  "method": "sampling/createMessage",
  "params": {
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "What files are in the current directory?"
        }
      }
    ],
    "systemPrompt": "You are a helpful file system assistant.",
    "includeContext": "thisServer",
    "maxTokens": 100
  }
}

{
  name: string;          // Unique identifier for the tool
  description?: string;  // Human-readable description
  inputSchema: {         // JSON Schema for the tool's parameters
    type: "object",
    properties: { ... }  // Tool-specific parameters
  }
}

// Define available tools
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [{
      name: "calculate_sum",
      inputSchema: {
        type: "object",
        properties: {
          a: { type: "number" },
          b: { type: "number" }
        },
        required: ["a", "b"]
      }
    }]
  };
});

// Handle tool execution
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "calculate_sum") {
    const { a, b } = request.params.arguments;
    return {
      content: [
        {
          type: "text",
          text: String(a + b)
        }
      ]
    };
  }
  throw new Error("Tool not found");
});
```

@app.list_tools()
async def list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="calculate_sum",
            description="Add two numbers together",
            inputSchema={
                "type": "object",
                "properties": {
                    "a": {"type": "number"},
                    "b": {"type": "number"}
                },
                "required": ["a", "b"]
            }
        )
    ]

@app.call_tool()
async def call_tool(
    name: str,
    arguments: dict
) -> list[types.TextContent | types.ImageContent | types.EmbeddedResource]:
    if name == "calculate_sum":
        a = arguments["a"]
        b = arguments["b"]
        result = a + b
        return [types.TextContent(type="text", text=str(result))]
    raise ValueError(f"Tool not found: {name}")
```

{
  name: "execute_command",
  inputSchema: {
    type: "object",
    properties: {
      command: { type: "string" },
      args: { type: "array", items: { type: "string" } }
    }
  }
}

{
  name: "github_create_issue",
  inputSchema: {
    type: "object",
    properties: {
      title: { type: "string" },
      body: { type: "string" },
      labels: { type: "array", items: { type: "string" } }
    }
  }
}

{
  name: "analyze_csv",
  inputSchema: {
    type: "object",
    properties: {
      filepath: { type: "string" },
      operations: {
        type: "array",
        items: {
          enum: ["sum", "average", "count"]
        }
      }
    }
  }
}

{
  jsonrpc: "2.0",
  id: number | string,
  method: string,
  params?: object
}

{
  jsonrpc: "2.0",
  id: number | string,
  result?: object,
  error?: {
    code: number,
    message: string,
    data?: unknown
  }
}

{
  jsonrpc: "2.0",
  method: string,
  params?: object
}

const transport = new StdioServerTransport();
await server.connect(transport);
```

const transport = new StdioClientTransport({
  command: "./server",
  args: ["--option", "value"]
});
await client.connect(transport);
```

async with stdio_server() as streams:
    await app.run(
        streams[0],
        streams[1],
        app.create_initialization_options()
    )
```

async with stdio_client(params) as streams:
    async with ClientSession(streams[0], streams[1]) as session:
        await session.initialize()
```

const app = express();

const server = new Server({
  name: "example-server",
  version: "1.0.0"
}, {
  capabilities: {}
});

let transport: SSEServerTransport | null = null;

app.get("/sse", (req, res) => {
  transport = new SSEServerTransport("/messages", res);
  server.connect(transport);
});

app.post("/messages", (req, res) => {
  if (transport) {
    transport.handlePostMessage(req, res);
  }
});

app.listen(3000);
```

const transport = new SSEClientTransport(
  new URL("http://localhost:3000/sse")
);
await client.connect(transport);
```

app = Server("example-server")
sse = SseServerTransport("/messages")

async def handle_sse(scope, receive, send):
    async with sse.connect_sse(scope, receive, send) as streams:
        await app.run(streams[0], streams[1], app.create_initialization_options())

async def handle_messages(scope, receive, send):
    await sse.handle_post_message(scope, receive, send)

starlette_app = Starlette(
    routes=[
        Route("/sse", endpoint=handle_sse),
        Route("/messages", endpoint=handle_messages, methods=["POST"]),
    ]
)
```

// Send a JSON-RPC message
  send(message: JSONRPCMessage): Promise<void>;

  // Close the connection
  close(): Promise<void>;

  // Callbacks
  onclose?: () => void;
  onerror?: (error: Error) => void;
  onmessage?: (message: JSONRPCMessage) => void;
}
```

Args:
        read_stream: Stream to read incoming messages from
        write_stream: Stream to write outgoing messages to
    """
    async with anyio.create_task_group() as tg:
        try:
            # Start processing messages
            tg.start_soon(lambda: process_messages(read_stream))

            # Send messages
            async with write_stream:
                yield write_stream

        except Exception as exc:
            # Handle errors
            raise exc
        finally:
            # Clean up
            tg.cancel_scope.cancel()
            await write_stream.aclose()
            await read_stream.aclose()
```

async send(message: JSONRPCMessage) {
    try {
      // Sending logic
    } catch (error) {
      this.onerror?.(new Error(`Failed to send message: ${error}`));
      throw error;
    }
  }
}
```

async def message_handler():
            try:
                async with read_stream_writer:
                    # Message handling logic
                    pass
            except Exception as exc:
                logger.error(f"Failed to handle message: {exc}")
                raise exc

        async with anyio.create_task_group() as tg:
            tg.start_soon(message_handler)
            try:
                # Yield streams for communication
                yield read_stream, write_stream
            except Exception as exc:
                logger.error(f"Transport error: {exc}")
                raise exc
            finally:
                tg.cancel_scope.cancel()
                await write_stream.aclose()
                await read_stream.aclose()
    except Exception as exc:
        logger.error(f"Failed to initialize transport: {exc}")
        raise exc
```