The Model Context Protocol (MCP) is an open standard for exposing tools and data sources to AI models through a server your organization runs. The MCP connector is the Messages API feature that consumes those servers on Anthropic's side: instead of your application receiving tool-use requests, calling the MCP server, and posting results back, the API connects to the MCP server directly during the request. It removes a whole layer of orchestration code — where it's available.
Where the connector works in July 2026
| Surface | MCP connector | Notes |
|---|---|---|
| Claude API (1P) | Beta | |
| Claude Platform on AWS | Beta | Public MCP servers only — MCP tunnels not supported |
| Microsoft Foundry | Beta | Hosted-on-Anthropic deployments only |
| Amazon Bedrock | Not supported | |
| Google Vertex AI | Not supported |
Two footnotes carry weight. On Claude Platform on AWS, only MCP servers exposed over the public internet work — MCP tunnels are not supported there, so a server reachable only inside your VPC needs to be published (behind appropriate authentication) before the connector can reach it. On Foundry, the connector is available only on Hosted on Anthropic deployments; sending a connector request to a Hosted-on-Azure deployment returns 400 Bad Request by design, because server-side agentic features are among those Azure-hosted deployments don't carry.
Why routing beats rewriting
The instinct when a platform lacks the connector is to rebuild the integration natively — hand-rolling the tool-use loop against Bedrock's API, translating each MCP tool into a client-implemented tool definition. That works, but it forks your codebase: two tool registries, two orchestration paths, two things to update when a tool changes.
The cheaper move is usually to route MCP-dependent requests to a surface that supports the connector and leave everything else where it is. This works because the Messages API request shape is shared across platforms — same messages array, same content blocks, same usage object in responses. Your MCP server, and the tool definitions it exposes, don't change at all; the MCP server is the source of truth for tools regardless of which surface calls it. What changes per surface is only the client class and the model-ID form.
For an AWS shop on Bedrock, the natural companion surface is Claude Platform on AWS: it stays inside your AWS account boundary, authenticates with SigV4 through IAM, bills through AWS Marketplace, and — being Anthropic-operated with typically same-day feature parity — carries the MCP connector beta. For a Google Cloud shop on Vertex AI, the supported surfaces are outside Google Cloud entirely (the first-party API, Claude Platform on AWS, or Foundry), so the routing decision doubles as a procurement decision.
A minimal split-routing client
The split can live in one factory function. Note the model-ID change: Bedrock prefixes IDs with anthropic., while Claude Platform on AWS uses bare first-party IDs.
from anthropic import AnthropicAWS, AnthropicBedrockMantle
def client_for(needs_mcp: bool):
if needs_mcp:
# MCP connector (beta): route to Claude Platform on AWS.
# Needs AWS_REGION + ANTHROPIC_AWS_WORKSPACE_ID env vars.
return AnthropicAWS(), "claude-sonnet-5"
# Everything else stays on Bedrock.
return AnthropicBedrockMantle(aws_region="us-east-1"), \
"anthropic.claude-sonnet-5"
client, model = client_for(needs_mcp=True)Route at the workload level, not per request, where you can: an agent flow that touches MCP anywhere in a conversation should keep the whole conversation on the supported surface, since a mid-conversation platform hop means re-sending history and losing any prompt-cache state built up on the other side.
What to watch when you split traffic
Separate quotas and billing. Claude Platform on AWS uses Anthropic-managed rate limits and a capacity pool separate from Bedrock, and bills in CCUs through AWS Marketplace rather than per-token on your AWS bill — see the dual-run cost accounting guide. Beta means beta. The connector is beta on every surface that has it, so treat it as subject to change and keep the routing seam thin enough to redirect. Confirm the current matrix before committing. Availability tables move; check the official platform documentation at design time.
Where to go next
For the connector's request mechanics, start with the MCP connector explainer and the platform split for MCP-based agents. If you're formalizing the client seam, the provider abstraction factory pattern generalizes the code above.