Where MCP goes next

Integration Was Always The Hard Part

The interesting problem with putting a language model to work was never the model. It was everything around it: getting it access to the right data, letting it take an action, and doing that without hand-writing a bespoke adapter for every combination of model and system.

For a while, everyone wrote that glue themselves. Each tool had its own shape, each provider its own calling convention, and none of it moved between projects. The work was real but dull.

What A Standard Actually Buys You

A tool protocol solves a boring problem well, which is usually where the value is. Describe a capability once, and any client that speaks the protocol can use it. Swap the model without rewriting the integration layer. Reuse a connector across projects instead of rebuilding it.

The pattern is familiar. Before a common protocol, every editor shipped its own language support and none of it was portable. After one, a single implementation served every editor. The protocol did not make anything newly possible, it made the existing thing worth doing once.

What A Protocol Does Not Solve

This is where the actual work begins. A standard for describing tools says almost nothing about the questions that decide whether you can ship:

• Whose data is this. A tool that reads records has to be scoped to one account, and that scoping belongs in the query, not in the description of the tool.
• Read is not automatically safe. A read tool with a broad enough reach is a data export with extra steps.
• What actually happened. If a model can take actions, you need a record of which ones it took, with what arguments, on whose behalf.
• What you will not expose. The most important design decision is usually the tool you decide not to offer.

Prompt Injection Does Not Care About Your Schema

Once a model can both read untrusted content and call tools, anything it reads becomes a potential instruction. A document, a support ticket, a web page. The model has no reliable way to distinguish data it was given from a command hidden inside that data.

Treat every tool result as untrusted input rather than as truth. Keep the tools that can act narrow and specific, prefer confirmation for anything with consequences, and assume that a capability you expose will eventually be invoked by something other than the user you had in mind.

Where This Is Heading

Two things look likely. The first is that connectors become infrastructure: something you adopt rather than build, in the same way nobody writes their own OAuth implementation any more. The interesting work moves from writing the adapter to deciding what should be reachable through it.

The second is that permissions get harder before they get easier. Existing authorisation models assume a person clicking a button. They do not cleanly express an agent acting on a person's behalf, with a subset of their rights, for a bounded task, with an audit trail attached. That gap is where a lot of the next few years of work will go.

What To Do Now

For a real product, start with one narrow, genuinely useful capability rather than exposing a broad surface and hoping. Scope every tool to a tenant from the first line. Log every call. Keep a person in front of anything destructive or customer-visible.

Adopting a standard is straightforward and worth doing. The judgement is in what you connect to it, and that part does not get easier because the plumbing did.