Remote MCPs: What we learned from shipping — John Welsh, Anthropic

What happens when connecting a model to tools becomes easy, but sharing those integrations across services remains hard? John Welsh approaches that problem from twenty years of building large-scale systems and, at Anthropic, recent work on tool calling and MCP integrations. He places the turning point around the middle to end of the preceding year: models became good enough at calling tools to connect Google Drive, consult Maps, and send someone a text message in one workflow.

Teams moved quickly. Custom endpoints such as /calltool and /getcontext appeared for individual use cases, then acquired authentication requirements. The organization accumulated duplicated functionality behind incompatible interfaces. In Welsh’s illustrative example, an integration works well in service A, but using it in service B requires a three-week interface rewrite. The exciting part—giving models useful tools—has produced an ordinary distributed-systems problem: everyone has built slightly different plumbing.

At Anthropic, those homegrown interfaces began converging on the same operations: get tools, get resources, ask for additional details. They increasingly resembled Model Context Protocol (MCP), even when they did not implement its full feature set. That convergence suggests adopting the shared contract before independently rebuilding more of it.

Welsh separates MCP into two concerns:

He locates most of the engineering value in the message semantics and server interactions. The March 2025 transport specification provides the historical context for this distinction. Its accompanying authorization specification described OAuth 2.1, then an IETF draft, as an optional authorization framework for HTTP transports—not a requirement that every MCP transport use OAuth.

Standardize how context is exchanged without requiring every internal connection to travel the same way. Welsh’s proposal to use MCP for everything is scoped to presenting context to models, not all application communication. A provider might run in the same process, in another data center, or behind enterprise networking. The consuming code should still connect to MCP and receive the same tools and methods.

Making Google Drive talk to an application is necessary work, but usually not a competitive differentiator. A single integration approach gives engineers less to learn and lets improvements made for one integration benefit the next. The goal is to spend less effort moving context between systems and more effort on the product consuming it.

MCP adds an ecosystem argument to that internal consistency argument: if customers and external services already require MCP support, maintaining a second internal contract means doing the work twice. Welsh cites participation by all major AI labs as a reason to expect new model capabilities to find their way into the protocol. That is his rationale for betting on its evolution; the immediate benefit is having protocol features available when the organization encounters the problems they address.

Consider Welsh’s hypothetical company with four products and four billing models. Each product may also have its own token limits and usage tracking. A shared slides integration needs model generation, but embedding every product’s accounting rules inside that integration would couple it to all four products.

Sampling reverses who requests model execution. The integration sends a sampling request over the MCP stream, and the client at the other end fulfills it. This lets the slides integration request generation while the consuming product supplies the execution and accounting context. The sampling specification defines sampling/createMessage, requires the client to declare sampling support, and leaves model selection and permissions with the client, with recommended approval controls. Billing and usage accounting remain application responsibilities; MCP supplies the request boundary through which that work can be delegated.

Two pressures converged at Anthropic. External remote MCP services, including the historical mcp.asana.com example, required network connectivity and authentication. Internally, engineers were creating PR review bots, Slack management tools, and other experimental LLM services. Giving every service user credentials and unrestricted outbound connectivity would spread sensitive responsibilities across the organization and make auditing harder.

The response was an MCP gateway: shared infrastructure with one entry point and a connection helper that returns an MCP SDK client session. Welsh calls this a pit of success. If the supported approach is also the easiest approach, engineers naturally use it.

The gateway combines four responsibilities:

• Connection entry point: One client call opens an MCP session.
• URL-based routing: Internal and external servers use the same connection path from the application’s perspective.
• Credential management: Applications do not each implement OAuth.
• Shared operations: Rate limiting and observability have a central home.

These capabilities make the gateway useful to application engineers while concentrating the work the organization needs to control.

The architecture diagram adds a gateway between the callers and their integrations. Welsh jokes that “one more box will solve all our problems.” The concrete value of that box is the shared responsibility it removes from each caller.

The simplified client call accepts a server URL, organization ID, and account ID. Welsh explains that the real implementation authenticates with a signed token because the gateway accesses stored credentials. Crucially, it returns an MCP SDK object directly. Applications can use the protocol’s interface rather than learning a gateway-specific replacement.

That choice also reduces the amount of wrapper code that must change as MCP evolves. Welsh describes adopting new features by updating internal MCP packages. The boundary still follows MCP’s lifecycle requirements: compatible protocol versions and negotiated capabilities determine what peers can actually use. A package update does not create support on the other end of a connection.

The same application code connects to internal and external integrations. External connections use the standardized transport; inside Anthropic’s network, the team chose WebSockets. The adapter opens a WebSocket and carries JSON-RPC messages in both directions. Internal transport selection follows the organization’s infrastructure needs while preserving the message contract.

The adapter’s output is a read stream and a write stream. Pass those into the MCP SDK client session, and the session handles the protocol above that boundary. In Python, the essential session wiring looks like this:

from mcp import ClientSession

async def discover_tools(read_stream, write_stream):
    async with ClientSession(read_stream, write_stream) as session:
        await session.initialize()
        return await session.list_tools()

The transport adapter supplies SDK-compatible streams; application code works with the initialized session. Welsh also suggests gRPC when multiplexing would avoid opening a separate WebSocket for each connection.

Once that boundary is clear, the transport alternatives are easy to compare:

Each adapter ultimately supplies the same read/write stream pair. These are custom transports, not additional standard MCP transports; they must still preserve MCP’s message and lifecycle requirements.

The email demonstration pushes the separation to an intentionally absurd conclusion. Messages begin with “Dear server, I hope this finds you well” and contain an “MCP request start” marker. After exchanging the messages by email, the implementation still feeds streams into a client session. IMAP is the joke; the stable SDK boundary is the mechanism.

With transport hidden behind the session interface, the gateway also owns external OAuth complexity. It exposes helpers to obtain an authorization URL and complete the OAuth flow. Those operations accommodate different redirect destinations: Anthropic’s API and claude.ai may need users returned to different places, even though the gateway manages the credentials for both.

Central ownership makes credentials portable across consuming services. A batch job can connect using the same internal user identity without asking the user to authenticate again. The job does not need its own copy of the OAuth implementation, and internal servers do not need to manage the external tokens. Credential reuse happens through the gateway.

Welsh traces the authenticated connection through that boundary:

1. Authenticate the internal connection. The service opens a WebSocket to the gateway with an authentication token in the headers.
2. Retrieve external credentials. The gateway looks up the user’s stored credentials.
3. Open the external connection. The gateway creates an authenticated SDK client, supplying the external bearer token in the authorization header.
4. Bridge the streams. The external client’s read and write streams connect to the internal transport.

The internal authentication token establishes who is calling the gateway; the retrieved external credential authenticates the gateway’s connection to the integration.

The gateway creates another useful property: a central view of the context models request and the context returned to them. Welsh raises prompt injection and the possibility of a model with Google Drive access deleting its contents as reasons to care about that visibility. The deletion example is a risk scenario, not an incident he reports observing.

That shared path offers a place to ban malicious servers, classify request content, and audit activity. Because messages have standardized shapes, inspection can target specific protocol operations: tool execution, tool definitions, or resource management. The gateway provides an enforcement point; the policies and processors still have to be built. Centralizing traffic makes those controls easier to apply consistently, but does not itself resolve prompt injection.

For a new service, adopting the shared path becomes a package import. Anthropic maintains client packages for multiple internal languages, so the architecture does not depend on every team choosing the same language. Engineers gain a familiar integration interface; operators gain a single point of ingress and egress with standardized messages. Returning SDK sessions also lets protocol evolution flow through the shared packages instead of requiring a new proprietary interface for each feature.

Welsh’s closing description of MCP as JSON streams emphasizes how little application-specific plumbing should sit between the transport and the client SDK. His broader recommendation is to standardize on something, even if the organization chooses a protocol other than MCP. Then make that standard the easiest path to use. Centralizing authentication and external connectivity at the appropriate layer removes repeated work from every service and leaves teams more time for the behavior that makes their products valuable.