MCP is becoming the tool-integration boundary — now comes the hard part

At 03:12, an assistant is asked to find every enterprise customer whose contract renews in the next 30 days, check whether any open support case exists, and prepare a renewal brief.

The model knows what to do. The trouble starts underneath. The CRM server wants OAuth, the token-based authorization framework. The support server is behind a different gateway. The database query takes 45 seconds. A proxy kills the connection at 30 seconds. The retry runs anyway and creates a duplicate follow-up task. The host receives three differently shaped failures, collapses them into an empty result, and the model confidently tells the user that no cases exist.

That is not only a failure of model intelligence. It is also a host and orchestrator reliability failure. It is a calibration failure: the system has turned “the query failed” into “there are no cases.”

When a server returns a tool result, MCP provides an isError indication that can preserve that distinction. The host should keep typed tool errors and transport failures visible, fail closed, and prevent the model from treating an unavailable dependency as an empty answer.

The Model Context Protocol, or MCP, changed the plumbing. A host is the application a person uses, such as a chat app or IDE. Its MCP client can discover and call MCP servers, which expose tools, resources, and prompts through a shared protocol.

MCP is becoming a common tool-integration boundary. The remaining fight is over semantics, trust, and operations. Those are less photogenic than a protocol launch, but they decide whether the renewal brief is ready at 03:12.

A common boundary is emerging

A protocol matters when refusing to support it becomes more expensive than adopting it. MCP is approaching that threshold across a wide range of AI hosts and business systems.

Several major products now document MCP connectivity, but “support” hides important differences. OpenAI’s Responses API documentation describes the API acting as an MCP client for remote servers. Google’s Gemini API documentation describes MCP integration for the Gemini API. Microsoft’s Copilot Studio documentation describes connecting an agent to MCP servers.

These are not interchangeable promises. Record the exact product, API version, client or server role, and availability label shown in the current documentation. A preview client is not the same compatibility promise as a generally available one. A product that consumes an MCP server is not automatically capable of publishing one.

Anthropic’s MCP announcement is a primary source for its own early adoption claims. The public MCP Registry and GitHub’s mcp-server topic show that the surrounding ecosystem is now much larger than a handful of demos.

Those sources count different units. A registry record is not proof that a server is active. A GitHub repository is not proof of a deployment. An SDK download is a package download, not a unique developer or organization. A survey result describes its sample, not the entire industry.

If you publish adoption numbers, include:

• The snapshot date and archived source for registry counts.
• The exact query and date for repository counts.
• The package-download window and whether downloads were deduplicated.
• The survey sample, recruitment method, and field dates.

Without those details, the honest conclusion is not “MCP has won.” It is that independent signals suggest a large enough ecosystem for interoperability to compound.

A server author can reasonably expect several hosts to understand the same protocol. A host author can connect to a growing catalog without writing a bespoke adapter for every vendor.

That is how a protocol becomes a default option. Not when everybody agrees it is elegant. When the alternative becomes annoying.

The MCP introduction covers the protocol itself. The important architectural result is simple: tool integration moved from private plugin dialects toward a shared boundary.

What MCP standardized — and what it did not

Imagine six AI hosts and 40 business systems. With bespoke integrations, the rough connector problem is 6 × 40, or 240 host-system pairings. Each pairing needs connection code, tool schemas, authentication handling, error mapping, and tests.

With MCP, the host implements the client side once and each system exposes an MCP server once. The connector layer is closer to 6 + 40, or 46 protocol implementations. That does not erase all integration work. It removes a great deal of repeated integration work.

An MCP server describes capabilities in a form the host can inspect. A tool has a name, a description, and an argument schema, which is a machine-readable description of the values it accepts.

The host can ask what is available, select a tool, send structured arguments, and receive a structured result. The same broad interaction can work in a desktop assistant, an IDE, or an internal agent runtime.

The model is not the only consumer:

• Gateways need to route calls.
• Policy engines need to inspect them.
• Observability systems need to record them.
• Test harnesses need to replay them.

A shared protocol gives all those systems a place to attach.

But MCP does not tell you what create_invoice means. It does not decide whether a tool is safe to retry. It does not know whether a user may approve a $50 refund but not a $50,000 refund. It does not make two servers agree on what “customer” means.

This is the distinction that gets lost in the USB-C analogy. USB-C standardizes the connector and signaling rules, but plugging in a cable does not guarantee that a laptop charger, monitor, and phone support the same power or data modes.

MCP makes connection possible. It does not make every capability semantically interchangeable.

Interoperability is the shared wire. Operability is everything that keeps the wire from becoming a very efficient path to an incident.

The hard part is operational

The 2026 work is not mainly about inventing another way to call a function. It is about removing the assumptions that were harmless in a local demo and expensive in production.

Streamable HTTP needs an explicit state model

A local MCP server can keep a session, meaning connection or conversation context, in memory and rely on one process staying alive. An enterprise deployment usually cannot.

Requests pass through load balancers, proxies, containers, autoscaling groups, and sometimes several security gateways. The next request may land on a different worker. The original worker may have been restarted. The proxy may buffer a stream or enforce a shorter timeout than the application expects.

Streamable HTTP is MCP’s HTTP transport for request and streamed-response exchanges. It is not inherently stateless.

MCP supports stateful sessions, including a server-issued Mcp-Session-Id that a client can send on later requests, and stream-resumption behavior using event identifiers when the client and server support it.

Stateless workers are a deployment choice. A stateless worker can process a request without relying on session data in its own memory. Any healthy worker can handle the request only when session state, request ordering, locks, task state, and other operational data are absent or shared externally.

Otherwise, use session affinity, which routes a session back to the same worker, or store the required state in a shared durable system.

The practical 2026 goal is therefore not “make MCP forgetful.” It is to make Streamable HTTP deployments work cleanly with either model.

Stateless workers simplify horizontal scaling and recovery. Stateful sessions remain useful, but they need explicit storage and routing rather than wishful thinking.

If generating the renewal report takes 45 seconds, the HTTP request may return a task identifier while a worker continues the job. The transport exchange can be short-lived. The task and the business operation are not ephemeral.

The published MCP Streamable HTTP transport specification is the source of truth for transport behavior.

Do not treat an unlinked July 28, 2026 release candidate, or headers appearing only in gateway documentation, as a universal MCP contract. Names such as Mcp-Method and Mcp-Name should be treated as gateway-specific unless an exact official draft or release-candidate document defines them. A draft or experimental feature is not evidence that every client and server supports it.

If a gateway does use routing metadata, it must validate the metadata against the JSON-RPC body, which is the structured request envelope carrying the method, parameters, and request identifier.

A claimed method or tool name that disagrees with the body should be rejected. The gateway must authorize the authenticated principal against server-side policy. It must never treat a client-supplied routing header as proof of permission.

That distinction matters for long-running work. If the renewal report is still running after the original connection closes, the host needs a durable way to ask for status and retrieve the result.

A worker restart should not turn a completed report into a mystery.

Discovery solves finding, not trusting

A registry and .well-known metadata are different mechanisms.

The public MCP Registry is a separate MCP project service: a catalog that lists server metadata so a client can find candidate integrations. It is not the core MCP wire protocol, and a registry entry does not prove that the server is active, safe, or honest.

A .well-known URL is fetched from an origin the client already knows. It is metadata discovery at that origin, not a global catalog of every server on the internet.

In the MCP OAuth flow, the protected-resource metadata endpoint commonly appears at /.well-known/oauth-protected-resource, as described by RFC 9728. It tells a client how to find authorization-server information for that protected resource. It does not tell the client which unrelated servers exist.

An MCP server card, if a particular deployment or extension provides one, has yet another purpose: describing that known server’s identity and capabilities. Follow the exact extension or draft specification for its endpoint.

Do not substitute a registry API for OAuth metadata, or OAuth metadata for a global registry lookup.

The safe flow is layered:

1. Use a registry to find a candidate.
2. Resolve its declared origin.
3. Fetch the origin’s documented metadata.
4. Complete authentication.
5. Apply your own trust and policy checks.

A catalog can shorten the path to a server; it cannot shorten the path around judgment.

Discovery creates a supply-chain problem. A convincing server called customer-support-search can still request excessive scopes, send data to an unexpected endpoint, or quietly change behavior in a later release.

Enterprise discovery needs more than names and descriptions. It needs:

• An owner.
• Version and provenance information.
• Declared permissions.
• Data-handling rules.
• Deprecation status.
• A review path.

Pin versions where practical. Keep an allowlist for sensitive environments. Treat a newly discovered server as code entering your trust boundary, not as a harmless plugin.

Apps and tasks extend the boundary

MCP Apps is an optional UI extension. A tool can expose a UI resource that the host renders in a sandboxed iframe, which is a browser frame with its own document context.

The result can be a table, approval form, chart, or result viewer that a human can inspect more safely than a 900-word block of generated prose.

The host renders the interface. That is different from trusting a server to inject arbitrary application UI into the host.

The improvement comes with a browser security surface. The UI needs origin isolation, a restrictive content security policy, careful handling of messages between the iframe and host, and explicit rules for which actions require confirmation.

A sandbox can limit damage; it does not turn unreviewed HTML and JavaScript into trusted software.

Tasks address the other obvious gap. A basic tool call assumes a request and a result. That is fine for “look up invoice 1842.” It is a poor fit for “export six years of records, wait for an external job, and keep the result for two hours.”

When supported by the negotiated MCP version or extension, a task can standardize lifecycle, status polling, and result retrieval.

Exact task metadata matters. A particular version may define a time-to-live, or TTL, and a polling hint; that does not create a universal retention guarantee for every implementation.

Tasks do not, by themselves, standardize retry policy, backoff, deduplication, or exactly-once side effects. Those remain application concerns:

• Is the operation idempotent, meaning repeating it produces the same intended effect?
• How does the worker recognize a duplicate retry?
• Can a user cancel it?
• What happens when the result expires?
• Which identity is allowed to retrieve the result later?
• Is the task identifier merely a lookup handle, or is there a separate stable idempotency key?

A task identifier does not make starting the same write twice safe.

Tasks also do not magically turn MCP into a complete agent-to-agent protocol. An MCP server can expose a long-running agent job, but identity, negotiation, delegation, and cross-agent trust remain separate concerns.

The agent protocols overview is useful here because it separates the tool boundary from the conversation and delegation boundary.

What I would do on Monday morning

Start with one workflow

I would not start by connecting 200 servers. I would choose one workflow with a measurable consequence, such as preparing the renewal brief or opening a support ticket, and make that path boring.

First, draw the actual request path: host → MCP client → gateway → MCP server → domain API.

Record who authenticates at each hop, which credentials are forwarded, where data is logged, and what happens when each dependency is unavailable. Most teams discover that “we use OAuth” is not an architecture. It is a sentence hiding six unanswered questions.

Second, put policy at the tool boundary:

• Use short-lived credentials and narrow scopes.
• Do not forward a user’s broad bearer token, a token that grants access to whoever presents it, to every server just because the server accepts bearer tokens.
• Separate read tools from write tools.
• Require explicit approval for destructive or expensive actions.
• Apply rate limits per identity and per tool, not only per host.

Make retries safe

Third, write contract tests before expanding the catalog. Test discovery, valid arguments, malformed arguments, missing scopes, revoked credentials, oversized results, slow dependencies, and a repeated call after a simulated network timeout.

Test the error that an operator sees, not only the success path shown in the demo.

The duplicate-call test is especially valuable. An MCP call provides no exactly-once guarantee. A timeout leaves the outcome unknown: the server may have committed the write just before its response disappeared.

Blindly issuing a new call can create a duplicate ticket or payment.

Use a stable idempotency key for the intended operation, not for each attempt. For example, the renewal workflow might use support-ticket:customer-1842:renewal-2026-08-28.

At the domain boundary, persist that key and the resulting ticket identifier, and enforce uniqueness on the key. A repeat with the same key returns the stored result instead of creating another ticket.

If the downstream payment or ticket provider supports idempotency keys, pass the same key to it. When an external side effect cannot be committed atomically with your own database, use the provider’s deduplication support, an outbox, or reconciliation rather than pretending a timeout was harmless.

For Tasks, retry status and result polling rather than creating a new task. If task creation itself can be retried, give the creation request a stable application-level key and make the server deduplicate it.

A task ID helps retrieve work. It is not automatically an idempotency key.

Observe the tool call

Fourth, observe the tool call as a first-class operation. Record:

• A correlation identifier, a value that ties logs and traces to one operation.
• The server, tool, and authenticated subject.
• The policy decision, latency, and result size.
• The task identifier and failure category.

Redact arguments that contain customer data or secrets. Watch p50, the median, p95, the latency below which 95 percent of calls finish, and p99 separately.

A healthy average can coexist with a 20-second tail that causes the 3 a.m. page.

The agent observability guide goes deeper on tracing these boundaries. The important principle is that “the model answered” is not a useful production metric.

You need to know whether the model selected the wrong tool, the gateway denied the right tool, the server timed out, or the domain API returned stale data.

Control context growth

Finally, control context growth. If 40 tools each contribute an average of 250 tokens of descriptions and schemas, the host has spent 40 × 250 = 10,000 tokens before the user asks anything.

That can increase cost and make tool selection less reliable. Load tools by task, search their metadata, or let the agent write code against a controlled tool surface. Code execution with MCP covers that last pattern.

The first failure you will probably see is not a dramatic exploit. It is a workflow that works locally and produces intermittent 401 or 504 responses after you add a second worker.

The cause is usually session affinity, a token audience mismatch, a proxy timeout, or a server that assumes requests arrive in sequence. Fix that before celebrating your server count.

The strongest objection is right — up to a point

The strongest argument against MCP is that it can become another abstraction layer nobody needs. A team with one internal application, one service, and one model vendor may be better off calling its existing API directly.

MCP adds a protocol adapter, another version surface, another place to configure authentication, and potentially another network hop.

There is also a legitimate semantic objection. A common schema can make search_documents callable without making its ranking, freshness, tenancy, or deletion behavior comparable across vendors. Calling everything a tool does not make everything the same.

I would not use MCP merely to decorate a single stable service. Use the native API when there is no second host, no need for model-vendor portability, and no shared tool governance to gain.

That is not an argument against MCP at ecosystem scale. Once several hosts need the same capabilities, the shared boundary pays for itself through reusable discovery, policy, testing, and observability.

It also gives an organization a way to replace a host or model vendor without rewriting every business integration. The protocol does not eliminate domain adapters. It puts them in one deliberate place instead of scattering them across every client.

The right conclusion is narrower. MCP is becoming a common default boundary for tool connections. Arguments about schemas, permissions, task semantics, and governance are not over. Those are the useful arguments now.

MCP makes connection cheaper. Production has to make trust, state, and consequences explicit.

That work is less glamorous than announcing a new transport. It is also what decides whether the renewal brief is ready at 03:12, or whether someone is explaining duplicate tickets to the on-call engineer.