Anthropic standardized internal model-context integrations on MCP to avoid rebuilding similar endpoints across services.
2
The MCP gateway gives engineers one connection method while handling routing, authentication, credentials, rate limiting, and observability.
3
MCP messages can travel over different internal transports, including WebSockets, gRPC, Unix sockets, and even email over IMAP.
Summary
John Welsh describes why Anthropic adopted MCP across internal and external integrations. As AI services began adding tool calls, teams created many custom endpoints with different authentication, billing, token limits, and usage tracking. Those interfaces became hard to reuse. Welsh argues that MCP provides a common message format for model context, while the transport carrying those messages can vary by environment. Anthropic built an MCP gateway as shared infrastructure. Engineers call it with a URL and identity details, receive an MCP SDK client session, and let the gateway handle external routing, stored credentials, authentication flows, rate limits, and observability. Internally, Anthropic uses WebSockets, though Welsh says other stream-based transports can work. The gateway also creates a central place to inspect and control model context, which can support policy checks, prompt-injection defenses, server blocking, classification, and auditing. His practical advice is to standardize on something and make the approved path the easiest path to use.
Tool integrations became difficult to reuse across an organization
As models improved at calling tools, teams quickly connected them to services such as Google Drive, maps, and messaging systems. Teams also created custom endpoints for actions such as calling a tool or retrieving context. The result was integration chaos. Authentication and other behavior were duplicated, interfaces differed between services, and an integration built for one service could take weeks to rewrite for another. Welsh says these endpoints gradually began to resemble MCP, with operations such as getting tools, getting resources, and eliciting more details.
Welsh separates MCP into two parts. The JSON-RPC specification defines how clients and context providers exchange messages. The transport standards cover concerns such as streamable HTTP, OAuth 2.1, and session management. He considers the message specification the more valuable part for engineers building integrations. The destination of the stream can vary. It may stay in the same process, cross a data center, or pass through enterprise networking, while the application still uses an MCP connection and its tools and methods.
Anthropic standardized internal context plumbing on MCP
Welsh argues that boring standardization is useful for work that is not a product differentiator. A common approach gives engineers one thing to learn and lets each new integration improve the shared setup. He also says MCP already has ecosystem demand because many AI organizations are implementing it. Its existing primitives can address problems a company may not have encountered yet. He gives sampling as an example: an integration can send a sampling request over the stream and let the other end fulfill it despite different product billing models, token limits, or usage tracking.
The MCP gateway makes the approved integration path easy
Anthropic needed to connect to external remote MCP services while also supporting a growing number of internal agents. Those services created concerns around network access, user credentials, and auditing. The response was an MCP gateway, shared infrastructure that provides one entry point. Engineers use a simple connect-to-MCP call, while URL-based routing sends the request to an internal or external server. The gateway also handles credential management, rate limiting, and observability. Welsh describes this as building a pit of success, where the preferred approach is the easiest one to use.
A shared SDK connection lets protocol updates reach every integration
Anthropic's client libraries pass a URL and identity information to the gateway, with a signed token used in the real implementation. The call returns an MCP SDK object. When new MCP features arrive, internal packages can be updated and those features become available across integrations without each service implementing the protocol again. The same application code can connect to internal and external integrations.
Internal transports can vary as long as they expose streams
Anthropic chose WebSockets for its internal transport and sends JSON-RPC messages over the connection. The read and write streams are then connected to an MCP SDK client session. Welsh says the same pattern can work with gRPC when multiplexing is useful, Unix sockets for local communication, or other mechanisms. He illustrates the point with an intentionally playful email transport over IMAP. The transport is an internal implementation choice, while the MCP client receives read and write streams.
Centralizing authentication keeps credentials out of individual services
The gateway handles OAuth and exposes functions for getting an authorization URL and completing the OAuth flow. This matters when different Anthropic endpoints need different redirect destinations. Credentials stored at the gateway are portable, so a batch job can use a user's internal ID without asking that user to authenticate again. Internal services also avoid managing the external tokens. The application connects to the gateway with an OAuth token, and the gateway creates an authenticated SDK client for the downstream MCP server.
The gateway creates a control point for model context
A central MCP stream gives an organization one place to inspect context moving into models. Welsh points to risks such as prompt injection and a model having access to a Google Drive where it could delete content. Teams could use the gateway to enforce policy, block malicious servers, classify content, and audit requests. Since MCP messages have a standard format, processors can inspect tool execution messages, tool definitions, and resource operations without building a separate integration for every service.
The practical rule is to standardize and make the safe path simple
Welsh reduces MCP to JSON streams and says routing those streams through infrastructure is a small implementation detail. His advice is to standardize on something, even if a team does not choose MCP, because a common interface avoids future rework. He also recommends building a pit of success and putting shared problems at the right layer. Handling external connectivity once at a central gateway leaves individual teams to work on their own product features.
"The pit of success, which is the idea that, if you make the right thing to do, the easiest thing to do, then everyone in your org kind of falls into it."07:47
Who should watch
You have several AI services that each use different tool or context endpoints and are paying the cost of repeated integration work.
Your organization needs a shared way to handle credentials, external network access, rate limits, or auditing for model-backed services.
You are implementing an MCP client and want to separate the protocol messages from the transport used inside your network.
