tools Documentation

Server authors should be prepared to handle any of these interaction patterns when implementing resource support. In order to expose data to models automatically, server authors should use a model-controlled primitive such as Tools.

Overview Copy Chapter

Resources represent any kind of data that an MCP server wants to make available to clients. This can include:

• File contents
• Database records
• API responses
• Live system data
• Screenshots and images
• Log files
• And more

Each resource is identified by a unique URI and can contain either text or binary data.

Resource URIs Copy Chapter

Resources are identified using URIs that follow this format:

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

For example:

• file:///home/user/documents/report.pdf
• postgres://database/customers/schema
• screen://localhost/display1

The protocol and path structure is defined by the MCP server implementation. Servers can define their own custom URI schemes.

Resource types Copy Chapter

Resources can contain two types of content:

Text resources Copy Section

Text resources contain UTF-8 encoded text data. These are suitable for:

• Source code
• Configuration files
• Log files
• JSON/XML data
• Plain text

Binary resources Copy Section

Binary resources contain raw binary data encoded in base64. These are suitable for:

• Images
• PDFs
• Audio files
• Video files
• Other non-text formats

Resource discovery Copy Chapter

Clients can discover available resources through two main methods:

Direct resources Copy Section

Servers expose a list of concrete resources via the resources/list endpoint. Each resource includes:

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

Resource templates Copy Section

For dynamic resources, servers can expose URI templates that clients can use to construct valid resource URIs:

{
  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
}

Reading resources Copy Chapter

To read a resource, clients make a resources/read request with the resource URI.

The server responds with a list of resource contents:

{
  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)
    }
  ]
}

Resource updates Copy Chapter

MCP supports real-time updates for resources through two mechanisms:

List changes Copy Section

Servers can notify clients when their list of available resources changes via the notifications/resources/list_changed notification.

Content changes Copy Section

Clients can subscribe to updates for specific resources:

1. Client sends resources/subscribe with resource URI
2. Server sends notifications/resources/updated when the resource changes
3. Client can fetch latest content with resources/read
4. Client can unsubscribe with resources/unsubscribe

Example implementation Copy Chapter

Here's a simple example of implementing resource support in an MCP server:

// 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()
    )
```

Best practices Copy Chapter

When implementing resource support:

1. Use clear, descriptive resource names and URIs
2. Include helpful descriptions to guide LLM understanding
3. Set appropriate MIME types when known
4. Implement resource templates for dynamic content
5. Use subscriptions for frequently changing resources
6. Handle errors gracefully with clear error messages
7. Consider pagination for large resource lists
8. Cache resource contents when appropriate
9. Validate URIs before processing
10. Document your custom URI schemes

Security considerations Copy Chapter

When exposing resources:

• Validate all resource URIs
• Implement appropriate access controls
• Sanitize file paths to prevent directory traversal
• Be cautious with binary data handling
• Consider rate limiting for resource reads
• Audit resource access
• Encrypt sensitive data in transit
• Validate MIME types
• Implement timeouts for long-running reads
• Handle resource cleanup appropriately

File: docs/concepts/roots.mdx Copy Chapter

title: "Roots" Copy Chapter

Roots are a concept in MCP that define the boundaries where servers can operate. They provide a way for clients to inform servers about relevant resources and their locations.

What are Roots? Copy Chapter

A root is a URI that a client suggests a server should focus on. When a client connects to a server, it declares which roots the server should work with. While primarily used for filesystem paths, roots can be any valid URI including HTTP URLs.

For example, roots could be:

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

Why Use Roots? Copy Chapter

Roots serve several important purposes:

1. Guidance: They inform servers about relevant resources and locations
2. Clarity: Roots make it clear which resources are part of your workspace
3. Organization: Multiple roots let you work with different resources simultaneously

How Roots Work Copy Chapter

When a client supports roots, it:

1. Declares the roots capability during connection
2. Provides a list of suggested roots to the server
3. Notifies the server when roots change (if supported)

While roots are informational and not strictly enforcing, servers should:

1. Respect the provided roots
2. Use root URIs to locate and access resources
3. Prioritize operations within root boundaries

Common Use Cases Copy Chapter

Roots are commonly used to define:

• Project directories
• Repository locations
• API endpoints
• Configuration locations
• Resource boundaries

Best Practices Copy Chapter

When working with roots:

1. Only suggest necessary resources
2. Use clear, descriptive names for roots
3. Monitor root accessibility
4. Handle root changes gracefully

Example Copy Chapter

Here's how a typical MCP client might expose roots:

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

This configuration suggests the server focus on both a local repository and an API endpoint while keeping them logically separated.

File: docs/concepts/sampling.mdx Copy Chapter

title: "Sampling" Copy Chapter

Sampling is a powerful MCP feature that allows servers to request LLM completions through the client, enabling sophisticated agentic behaviors while maintaining security and privacy.

This feature of MCP is not yet supported in the Claude Desktop client.

How sampling works Copy Chapter

The sampling flow follows these steps:

1. Server sends a sampling/createMessage request to the client
2. Client reviews the request and can modify it
3. Client samples from an LLM
4. Client reviews the completion
5. Client returns the result to the server

This human-in-the-loop design ensures users maintain control over what the LLM sees and generates.

Message format Copy Chapter

Sampling requests use a standardized message format:

{
  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>
}

Request parameters Copy Chapter

Messages Copy Section

The messages array contains the conversation history to send to the LLM. Each message has:

• role: Either "user" or "assistant"
• content: The message content, which can be:
  • Text content with a text field
  • Image content with data (base64) and mimeType fields

Model preferences Copy Section

The modelPreferences object allows servers to specify their model selection preferences:

• hints: Array of model name suggestions that clients can use to select an appropriate model:

  • name: String that can match full or partial model names (e.g. "claude-3", "sonnet")
  • Clients may map hints to equivalent models from different providers
  • Multiple hints are evaluated in preference order

• Priority values (0-1 normalized):

  • costPriority: Importance of minimizing costs
  • speedPriority: Importance of low latency response
  • intelligencePriority: Importance of advanced model capabilities

Clients make the final model selection based on these preferences and their available models.

System prompt Copy Section

An optional systemPrompt field allows servers to request a specific system prompt. The client may modify or ignore this.

Context inclusion Copy Section

The includeContext parameter specifies what MCP context to include:

• "none": No additional context
• "thisServer": Include context from the requesting server
• "allServers": Include context from all connected MCP servers

The client controls what context is actually included.

Sampling parameters Copy Section

Fine-tune the LLM sampling with:

• temperature: Controls randomness (0.0 to 1.0)
• maxTokens: Maximum tokens to generate
• stopSequences: Array of sequences that stop generation
• metadata: Additional provider-specific parameters

Response format Copy Chapter

The client returns a completion result:

{
  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
  }
}

Example request Copy Chapter

Here's an example of requesting sampling from a client:

{
  "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
  }
}

Best practices Copy Chapter

When implementing sampling:

1. Always provide clear, well-structured prompts
2. Handle both text and image content appropriately
3. Set reasonable token limits
4. Include relevant context through includeContext
5. Validate responses before using them
6. Handle errors gracefully
7. Consider rate limiting sampling requests
8. Document expected sampling behavior
9. Test with various model parameters
10. Monitor sampling costs

Human in the loop controls Copy Chapter

Sampling is designed with human oversight in mind:

For prompts Copy Section

• Clients should show users the proposed prompt
• Users should be able to modify or reject prompts
• System prompts can be filtered or modified
• Context inclusion is controlled by the client

For completions Copy Section

• Clients should show users the completion
• Users should be able to modify or reject completions
• Clients can filter or modify completions
• Users control which model is used

Security considerations Copy Chapter

When implementing sampling:

• Validate all message content
• Sanitize sensitive information
• Implement appropriate rate limits
• Monitor sampling usage
• Encrypt data in transit
• Handle user data privacy
• Audit sampling requests
• Control cost exposure
• Implement timeouts
• Handle model errors gracefully

Common patterns Copy Chapter

Agentic workflows Copy Section

Sampling enables agentic patterns like:

• Reading and analyzing resources
• Making decisions based on context
• Generating structured data
• Handling multi-step tasks
• Providing interactive assistance

Context management Copy Section

Best practices for context:

• Request minimal necessary context
• Structure context clearly
• Handle context size limits
• Update context as needed
• Clean up stale context

Error handling Copy Section

Robust error handling should:

• Catch sampling failures
• Handle timeout errors
• Manage rate limits
• Validate responses
• Provide fallback behaviors
• Log errors appropriately

Limitations Copy Chapter

Be aware of these limitations:

• Sampling depends on client capabilities
• Users control sampling behavior
• Context size has limits
• Rate limits may apply
• Costs should be considered
• Model availability varies
• Response times vary
• Not all content types supported

File: docs/concepts/tools.mdx Copy Chapter

title: "Tools" Copy Chapter

Tools are a powerful primitive in the Model Context Protocol (MCP) that enable servers to expose executable functionality to clients. Through tools, LLMs can interact with external systems, perform computations, and take actions in the real world.

Overview Copy Chapter

Tools in MCP allow servers to expose executable functions that can be invoked by clients and used by LLMs to perform actions. Key aspects of tools include:

• Discovery: Clients can list available tools through the tools/list endpoint
• Invocation: Tools are called using the tools/call endpoint, where servers perform the requested operation and return results
• Flexibility: Tools can range from simple calculations to complex API interactions

Like resources, tools are identified by unique names and can include descriptions to guide their usage. However, unlike resources, tools represent dynamic operations that can modify state or interact with external systems.

Tool definition structure Copy Chapter

Each tool is defined with the following structure:

{
  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
  }
}

Implementing tools Copy Chapter

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

// 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}")
```

Example tool patterns Copy Chapter

Here are some examples of types of tools that a server could provide:

System operations Copy Section

Tools that interact with the local system:

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

API integrations Copy Section

Tools that wrap external APIs:

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

Data processing Copy Section

Tools that transform or analyze data:

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

Best practices Copy Chapter

When implementing tools:

1. Provide clear, descriptive names and descriptions
2. Use detailed JSON Schema definitions for parameters
3. Include examples in tool descriptions to demonstrate how the model should use them
4. Implement proper error handling and validation
5. Use progress reporting for long operations
6. Keep tool operations focused and atomic
7. Document expected return value structures
8. Implement proper timeouts
9. Consider rate limiting for resource-intensive operations
10. Log tool usage for debugging and monitoring

Security considerations Copy Chapter

When exposing tools:

Input validation Copy Section

• Validate all parameters against the schema
• Sanitize file paths and system commands
• Validate URLs and external identifiers
• Check parameter sizes and ranges
• Prevent command injection

Access control Copy Section

• Implement authentication where needed
• Use appropriate authorization checks
• Audit tool usage
• Rate limit requests
• Monitor for abuse

Error handling Copy Section

• Don't expose internal errors to clients
• Log security-relevant errors
• Handle timeouts appropriately
• Clean up resources after errors
• Validate return values

Tool discovery and updates Copy Chapter

MCP supports dynamic tool discovery:

1. Clients can list available tools at any time
2. Servers can notify clients when tools change using notifications/tools/list_changed
3. Tools can be added or removed during runtime
4. Tool definitions can be updated (though this should be done carefully)

Error handling Copy Chapter

Tool errors should be reported within the result object, not as MCP protocol-level errors. This allows the LLM to see and potentially handle the error. When a tool encounters an error:

1. Set isError to true in the result
2. Include error details in the content array

Here's an example of proper error handling for tools:

This approach allows the LLM to see that an error occurred and potentially take corrective action or request human intervention.

Testing tools Copy Chapter

A comprehensive testing strategy for MCP tools should cover:

• Functional testing: Verify tools execute correctly with valid inputs and handle invalid inputs appropriately
• Integration testing: Test tool interaction with external systems using both real and mocked dependencies
• Security testing: Validate authentication, authorization, input sanitization, and rate limiting
• Performance testing: Check behavior under load, timeout handling, and resource cleanup
• Error handling: Ensure tools properly report errors through the MCP protocol and clean up resources

File: docs/concepts/transports.mdx Copy Chapter

title: "Transports" Copy Chapter

Transports in the Model Context Protocol (MCP) provide the foundation for communication between clients and servers. A transport handles the underlying mechanics of how messages are sent and received.

Message Format Copy Chapter

MCP uses JSON-RPC 2.0 as its wire format. The transport layer is responsible for converting MCP protocol messages into JSON-RPC format for transmission and converting received JSON-RPC messages back into MCP protocol messages.

There are three types of JSON-RPC messages used:

Requests Copy Section

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

Responses Copy Section

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

Notifications Copy Section

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

Built-in Transport Types Copy Chapter

MCP includes two standard transport implementations:

Standard Input/Output (stdio) Copy Section

The stdio transport enables communication through standard input and output streams. This is particularly useful for local integrations and command-line tools.

Use stdio when:

• Building command-line tools
• Implementing local integrations
• Needing simple process communication
• Working with shell scripts

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()
```

Server-Sent Events (SSE) Copy Section

SSE transport enables server-to-client streaming with HTTP POST requests for client-to-server communication.

Use SSE when:

• Only server-to-client streaming is needed
• Working with restricted networks
• Implementing simple updates

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"]),
    ]
)
```

Custom Transports Copy Chapter

MCP makes it easy to implement custom transports for specific needs. Any transport implementation just needs to conform to the Transport interface:

You can implement custom transports for:

• Custom network protocols
• Specialized communication channels
• Integration with existing systems
• Performance optimization

// 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()
```

Error Handling Copy Chapter

Transport implementations should handle various error scenarios:

1. Connection errors
2. Message parsing errors
3. Protocol errors
4. Network timeouts
5. Resource cleanup

Example error handling:

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
```

Best Practices Copy Chapter

When implementing or using MCP transport:

1. Handle connection lifecycle properly
2. Implement proper error handling
3. Clean up resources on connection close
4. Use appropriate timeouts
5. Validate messages before sending
6. Log transport events for debugging
7. Implement reconnection logic when appropriate
8. Handle backpressure in message queues
9. Monitor connection health
10. Implement proper security measures

Security Considerations Copy Chapter

When implementing transport:

Authentication and Authorization Copy Section

• Implement proper authentication mechanisms
• Validate client credentials
• Use secure token handling
• Implement authorization checks

Data Security Copy Section

• Use TLS for network transport
• Encrypt sensitive data
• Validate message integrity
• Implement message size limits
• Sanitize input data

Network Security Copy Section

• Implement rate limiting
• Use appropriate timeouts
• Handle denial of service scenarios
• Monitor for unusual patterns
• Implement proper firewall rules

Debugging Transport Copy Chapter

Tips for debugging transport issues:

1. Enable debug logging
2. Monitor message flow
3. Check connection states
4. Validate message formats
5. Test error scenarios
6. Use network analysis tools
7. Implement health checks
8. Monitor resource usage
9. Test edge cases
10. Use proper error tracking