Tools

Tools in MCP are designed to be model-controlled, meaning that the language model can discover and invoke tools automatically based on its contextual understanding and the user’s prompts.

However, implementations are free to expose tools through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model.

Capabilities link

Servers that support tools MUST declare the tools capability:

  {
  "capabilities": {
    "tools": {
      "listChanged": true
    }
  }
}
  

listChanged indicates whether the server will emit notifications when the list of available tools changes.

Protocol Messages link

Listing Tools link

To discover available tools, clients send a tools/list request. This operation supports pagination.

Request:

  {
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "cursor": "optional-cursor-value"
  }
}
  

Response:

  {
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "title": "Weather Information Provider",
        "description": "Get current weather information for a location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name or zip code"
            }
          },
          "required": ["location"]
        }
      }
    ],
    "nextCursor": "next-page-cursor"
  }
}
  

Calling Tools link

To invoke a tool, clients send a tools/call request:

Request:

  {
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "New York"
    }
  }
}
  

Response:

  {
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Current weather in New York:\nTemperature: 72°F\nConditions: Partly cloudy"
      }
    ],
    "isError": false
  }
}
  

List Changed Notification link

When the list of available tools changes, servers that declared the listChanged capability SHOULD send a notification:

  {
  "jsonrpc": "2.0",
  "method": "notifications/tools/list_changed"
}
  

Message Flow link

sequenceDiagram
    participant LLM
    participant Client
    participant Server

    Note over Client,Server: Discovery
    Client->>Server: tools/list
    Server-->>Client: List of tools

    Note over Client,LLM: Tool Selection
    LLM->>Client: Select tool to use

    Note over Client,Server: Invocation
    Client->>Server: tools/call
    Server-->>Client: Tool result
    Client->>LLM: Process result

    Note over Client,Server: Updates
    Server--)Client: tools/list_changed
    Client->>Server: tools/list
    Server-->>Client: Updated tools

Data Types link

Tool link

A tool definition includes:

• name: Unique identifier for the tool
• title: Optional human-readable name of the tool for display purposes.
• description: Human-readable description of functionality
• inputSchema: JSON Schema defining expected parameters
• outputSchema: Optional JSON Schema defining expected output structure
• annotations: optional properties describing tool behavior

Tool Result link

Tool results may contain structured or unstructured content.

Unstructured content is returned in the content field of a result, and can contain multiple content items of different types:

Text Content link

  {
  "type": "text",
  "text": "Tool result text"
}
  

Image Content link

  {
  "type": "image",
  "data": "base64-encoded-data",
  "mimeType": "image/png"
  "annotations": {
    "audience": ["user"],
    "priority": 0.9
  }

}
  

This example demonstrates the use of an optional Annotation.

Audio Content link

  {
  "type": "audio",
  "data": "base64-encoded-audio-data",
  "mimeType": "audio/wav"
}
  

Resource Links link

A tool MAY return links to Resources, to provide additional context or data. In this case, the tool will return a URI that can be subscribed to or fetched by the client:

  {
  "type": "resource_link",
  "uri": "file:///project/src/main.rs",
  "name": "main.rs",
  "description": "Primary application entry point",
  "mimeType": "text/x-rust",
  "annotations": {
    "audience": ["assistant"],
    "priority": 0.9
  }
}
  

Resource links support the same Resource annotations as regular resources to help clients understand how to use them.

Embedded Resources link

Resources MAY be embedded to provide additional context or data using a suitable URI scheme. Servers that use embedded resources SHOULD implement the resources capability:

  {
  "type": "resource",
  "resource": {
    "uri": "file:///project/src/main.rs",
    "title": "Project Rust Main File",
    "mimeType": "text/x-rust",
    "text": "fn main() {\n    println!(\"Hello world!\");\n}",
    "annotations": {
      "audience": ["user", "assistant"],
      "priority": 0.7,
      "lastModified": "2025-05-03T14:30:00Z"
    }
  }
}
  

Embedded resources support the same Resource annotations as regular resources to help clients understand how to use them.

Structured Content link

Structured content is returned as a JSON object in the structuredContent field of a result.

For backwards compatibility, a tool that returns structured content SHOULD also return the serialized JSON in a TextContent block.

Output Schema link

Tools may also provide an output schema for validation of structured results. If an output schema is provided:

• Servers MUST provide structured results that conform to this schema.
• Clients SHOULD validate structured results against this schema.

Example tool with output schema:

  {
  "name": "get_weather_data",
  "title": "Weather Data Retriever",
  "description": "Get current weather data for a location",
  "inputSchema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City name or zip code"
      }
    },
    "required": ["location"]
  },
  "outputSchema": {
    "type": "object",
    "properties": {
      "temperature": {
        "type": "number",
        "description": "Temperature in celsius"
      },
      "conditions": {
        "type": "string",
        "description": "Weather conditions description"
      },
      "humidity": {
        "type": "number",
        "description": "Humidity percentage"
      }
    },
    "required": ["temperature", "conditions", "humidity"]
  }
}
  

Example valid response for this tool:

  {
  "jsonrpc": "2.0",
  "id": 5,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "{\"temperature\": 22.5, \"conditions\": \"Partly cloudy\", \"humidity\": 65}"
      }
    ],
    "structuredContent": {
      "temperature": 22.5,
      "conditions": "Partly cloudy",
      "humidity": 65
    }
  }
}
  

Providing an output schema helps clients and LLMs understand and properly handle structured tool outputs by:

• Enabling strict schema validation of responses
• Providing type information for better integration with programming languages
• Guiding clients and LLMs to properly parse and utilize the returned data
• Supporting better documentation and developer experience

Error Handling link

Tools use two error reporting mechanisms:

1. Protocol Errors: Standard JSON-RPC errors for issues like:

   • Unknown tools
   • Invalid arguments
   • Server errors

2. Tool Execution Errors: Reported in tool results with isError: true:

   • API failures
   • Invalid input data
   • Business logic errors

Example protocol error:

  {
  "jsonrpc": "2.0",
  "id": 3,
  "error": {
    "code": -32602,
    "message": "Unknown tool: invalid_tool_name"
  }
}
  

Example tool execution error:

  {
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Failed to fetch weather data: API rate limit exceeded"
      }
    ],
    "isError": true
  }
}
  

Security Considerations link

1. Servers MUST:

   • Validate all tool inputs
   • Implement proper access controls
   • Rate limit tool invocations
   • Sanitize tool outputs

2. Clients SHOULD:

   • Prompt for user confirmation on sensitive operations
   • Show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration
   • Validate tool results before passing to LLM
   • Implement timeouts for tool calls
   • Log tool usage for audit purposes