The MCP connector has two hard boundaries. First, it only connects to servers of type: "url" that are publicly exposed over HTTPS — a local STDIO server (a Model Context Protocol server launched as a subprocess, speaking over standard input/output) can never be reached from Anthropic's infrastructure. Second, of the MCP specification's feature set, the connector supports only tool calls: MCP prompts (reusable prompt templates a server offers) and MCP resources (files and data a server exposes) don't come through at all.
Anthropic's docs state the decision rule directly: use the mcp_servers API parameter when you have remote servers accessible by URL and only need tools; use the client-side helpers when you need local servers, MCP prompts, MCP resources, or control over the connection. This article covers the second path.
What "running your own MCP client" means
In this pattern, your application connects to the MCP server (local or remote — you control the transport), lists its tools, and exposes them to Claude as ordinary client tools on the Messages API. When Claude requests a tool call, your code forwards it to the MCP server and returns the result. The problem is purely one of translation: MCP's type system and the Claude API's type system are similar but not identical, and hand-writing the conversion is tedious and easy to get subtly wrong. That conversion layer is exactly what the helpers provide.
The four helpers
In Python they live in anthropic.lib.tools.mcp, installed with pip install anthropic[mcp]:
| Helper | Converts | Use it when |
|---|---|---|
mcpTools(tools, mcpClient) | MCP tool definitions → tools for the SDK's tool runner | You want Claude to call the server's tools through your client |
mcpMessages(messages) | MCP prompt messages → Claude messages | A server-provided MCP prompt should seed the conversation |
mcpResourceToContent | MCP resource → content block | A server resource belongs inline in a message |
mcpResourceToFile | MCP resource → file upload | A server resource should go through the Files API instead |
Note the first helper hooks into the SDK's tool runner — the base SDK machinery that executes the tool-use loop for client tools — so an MCP server's tools slot into the same loop as your hand-written ones. One error type matters: conversion raises UnsupportedMCPValueError when an MCP value has no Claude API equivalent — unsupported content types, unsupported MIME types, or non-HTTP resource links. Catch it and decide per case whether to skip the item or fail the request.
The helpers aren't Python-only. Equivalents ship in TypeScript (@anthropic-ai/sdk/helpers/beta/mcp), Java (com.anthropic.mcp.BetaMcp), Go (github.com/anthropics/anthropic-sdk-go/mcp), Ruby (Anthropic::Mcp), and PHP (Anthropic\Lib\Tools\BetaMcp) — but not yet in the C# SDK. For building the MCP-client side itself, Anthropic's docs point to the SDKs under the modelcontextprotocol GitHub organization, such as the TypeScript MCP SDK.
Why this matters more on Bedrock and Vertex
Because everything here runs client-side and surfaces as ordinary tool use — which works on all four 3P platforms — this pattern is the portable one. On Amazon Bedrock and Google Vertex AI, where the remote connector is simply unavailable, running your own MCP client is the documented way to use MCP servers with Claude on the Messages surface at all. The same code works unchanged whether the endpoint behind it is 1P, AnthropicBedrockMantle, or AnthropicVertex. (If you want an agent loop rather than raw Messages calls, the Claude Agent SDK also connects to local command-based MCP servers — see Agent SDK vs. Managed Agents.)
Where to go next
For the remote path, start with the connector request shape; for multi-server architectures, see the multi-server MCP pattern.