MCP connector
Claude’s Model Context Protocol (MCP) connector feature enables you to connect to remote MCP servers directly from the Messages API without a separate MCP client.
Current version: This feature requires the beta header:
"anthropic-beta": "mcp-client-2025-11-20"The previous version (mcp-client-2025-04-04) is deprecated. See the deprecated version documentation below.Key features
- Direct API integration: Connect to MCP servers without implementing an MCP client
- Tool calling support: Access MCP tools through the Messages API
- Flexible tool configuration: Enable all tools, allowlist specific tools, or denylist unwanted tools
- Per-tool configuration: Configure individual tools with custom settings
- OAuth authentication: Support for OAuth Bearer tokens for authenticated servers
- Multiple servers: Connect to multiple MCP servers in a single request
Limitations
- Of the feature set of the MCP specification, only tool calls are currently supported.
- The server must be publicly exposed through HTTP (supports both Streamable HTTP and SSE transports). Local STDIO servers cannot be connected directly.
- The MCP connector is currently not supported on Amazon Bedrock and Google Vertex.
Using the MCP connector in the Messages API
The MCP connector uses two components:- MCP Server Definition (
mcp_serversarray): Defines server connection details (URL, authentication) - MCP Toolset (
toolsarray): Configures which tools to enable and how to configure them
Basic example
This example enables all tools from an MCP server with default configuration:MCP server configuration
Each MCP server in themcp_servers array defines the connection details:
Field descriptions
MCP toolset configuration
The MCPToolset lives in thetools array and configures which tools from the MCP server are enabled and how they should be configured.
Basic structure
Field descriptions
Tool configuration options
Each tool (whether configured indefault_config or in configs) supports the following fields:
Configuration merging
Configuration values merge with this precedence (highest to lowest):- Tool-specific settings in
configs - Set-level
default_config - System defaults
search_events:enabled: false(from configs),defer_loading: true(from default_config)- All other tools:
enabled: true(system default),defer_loading: true(from default_config)
Common configuration patterns
Enable all tools with default configuration
The simplest pattern - enable all tools from a server:Allowlist - Enable only specific tools
Setenabled: false as the default, then explicitly enable specific tools:
Denylist - Disable specific tools
Enable all tools by default, then explicitly disable unwanted tools:Mixed - Allowlist with per-tool configuration
Combine allowlisting with custom configuration for each tool:search_eventsis enabled withdefer_loading: falselist_eventsis enabled withdefer_loading: true(inherited from default_config)- All other tools are disabled
Validation rules
The API enforces these validation rules:- Server must exist: The
mcp_server_namein an MCPToolset must match a server defined in themcp_serversarray - Server must be used: Every MCP server defined in
mcp_serversmust be referenced by exactly one MCPToolset - Unique toolset per server: Each MCP server can only be referenced by one MCPToolset
- Unknown tool names: If a tool name in
configsdoesn’t exist on the MCP server, a backend warning is logged but no error is returned (MCP servers may have dynamic tool availability)
Response content types
When Claude uses MCP tools, the response will include two new content block types:MCP Tool Use Block
MCP Tool Result Block
Multiple MCP servers
You can connect to multiple MCP servers by including multiple server definitions inmcp_servers and a corresponding MCPToolset for each in the tools array:
Authentication
For MCP servers that require OAuth authentication, you’ll need to obtain an access token. The MCP connector beta supports passing anauthorization_token parameter in the MCP server definition.
API consumers are expected to handle the OAuth flow and obtain the access token prior to making the API call, as well as refreshing the token as needed.
Obtaining an access token for testing
The MCP inspector can guide you through the process of obtaining an access token for testing purposes.-
Run the inspector with the following command. You need Node.js installed on your machine.
- In the sidebar on the left, for “Transport type”, select either “SSE” or “Streamable HTTP”.
- Enter the URL of the MCP server.
- In the right area, click on the “Open Auth Settings” button after “Need to configure authentication?”.
- Click “Quick OAuth Flow” and authorize on the OAuth screen.
- Follow the steps in the “OAuth Flow Progress” section of the inspector and click “Continue” until you reach “Authentication complete”.
-
Copy the
access_tokenvalue. -
Paste it into the
authorization_tokenfield in your MCP server configuration.
Using the access token
Once you’ve obtained an access token using either OAuth flow above, you can use it in your MCP server configuration:Migration guide
If you’re using the deprecatedmcp-client-2025-04-04 beta header, follow this guide to migrate to the new version.
Key changes
- New beta header: Change from
mcp-client-2025-04-04tomcp-client-2025-11-20 - Tool configuration moved: Tool configuration now lives in the
toolsarray as MCPToolset objects, not in the MCP server definition - More flexible configuration: New pattern supports allowlisting, denylisting, and per-tool configuration
Migration steps
Before (deprecated):Common migration patterns
Deprecated version: mcp-client-2025-04-04
This version is deprecated. Please migrate to
mcp-client-2025-11-20 using the migration guide above.