Model Context Protocol: what it actually standardises (and what you'll still have to build yourself)

The USB-C analogy is correct, but it answers the wrong question

The 'USB-C for AI' framing for the Model Context Protocol is technically accurate: MCP is an open standard for connecting AI agents to external tools, designed so that a single integration works across any client that speaks the protocol. That is a genuine parallel to how USB-C standardised physical device connectivity.

But USB-C succeeded because the incentive structure was symmetric. Charger manufacturers and device manufacturers faced the same problem, a proliferation of proprietary connectors that hurt consumers and themselves equally. MCP's situation is asymmetric. LLM providers adopted the spec quickly because it makes their models more capable without requiring them to own the integration layer. Tool providers (APIs, databases, internal services) face a different calculation: the protocol adds overhead, and the benefit depends on whether the tools they expose will be called by enough MCP clients to justify the work.

The question 'should I use MCP?' has two different answers depending on which side of the connection you're building. Most articles assume you're asking from the tool-provider side. Many of the teams asking the question are actually on the client side, building AI agents that need to call external tools. The answers diverge significantly, and conflating them leads to teams either over-investing in MCP server infrastructure they don't need or skipping MCP client adoption where it would save them meaningful work.

What the Model Context Protocol does at the protocol level

MCP is JSON-RPC 2.0. An MCP client connects to a server and they exchange structured messages over one of two transports. The stdio transport has the client spawn a server subprocess and communicate over stdin/stdout. This is the transport for local integrations: CLI tools, IDE extensions, and developer assistants running on a single machine. Cursor, Claude Code, VS Code with Copilot, and most desktop AI tools default to stdio. The Streamable HTTP transport has the client send HTTP POST requests to the server, with optional server-sent events for streaming. This covers remote services and hosted integrations where multiple clients need to reach the same server. The earlier HTTP+SSE transport from the 2024 spec was deprecated in early 2025; tutorials that only mention HTTP+SSE are out of date.

Once connected, the server declares three types of capabilities. Tools are callable functions: each has a name, a natural-language description the model uses when deciding whether to call it, and a JSON Schema describing its inputs. Resources are read-only data sources the model can list and subscribe to. Prompts are template messages the server can provide for injection into a conversation. In practice, most MCP servers today are tool servers; Resources and Prompts see limited production use.

The protocol includes a capability-negotiation handshake at session start. Client and server exchange supported features; the client learns what the server can do before any LLM call happens. This is what enables dynamic tool discovery: a client can ask any MCP server what it offers, and the tools appear in the model's context without hard-coding per-tool logic on the client side.

Who actually benefits: the tool consumer case

If you're building an AI client (any system that orchestrates LLM calls and uses external tools to do work), MCP gives you a concrete advantage: you define your tool client once, and any MCP server you connect to works through the same interface.

Without MCP, calling a Jira API from your agent means writing the tool definition in your LLM provider's format. When you add a second provider for cost reasons, you rewrite the integration. When you want the same tool available in both your CI/CD pipeline and your developer assistant, you maintain two copies. When a new framework your team adopts ships a different tool format, you do it again.

With MCP, the tool definition lives on the server. Any MCP-capable client discovers and calls it through the standard interface. Access control, authentication, and capability scoping are handled server-side, before the client sees a tool definition. The client gets back exactly what the server decides to expose, scoped to that client's identity and permissions. One update to the server reaches all consumers.

The practical workflow: start a local MCP server process or point to a hosted one, configure your MCP client to discover it at startup, and from that point the tools appear alongside any other tools in your agent's capability set. No per-model integration code. No format translation layer. The model's tool-calling logic does not know or care whether a tool definition came from MCP or was written inline.

The official MCP server registry lists over 3,000 servers as of mid-2026, covering GitHub, Linear, Jira, Postgres, Slack, Notion, Google Workspace, and most major REST APIs via OpenAPI-to-MCP transpilers. For a team building an agent, this means most integrations already exist and do not require building anything.

Who benefits: the tool provider case, and when the maths works

If you're building a service that you want AI agents to call (an internal API, a SaaS product, a database wrapper), the calculation is different and depends on who your target clients actually are.

For developer-tooling integrations, the answer in mid-2026 is clear: build the MCP server. The ecosystem that matters most for this use case, Cursor, VS Code via Copilot, Claude Code, and the major open-source AI coding agents, all speak MCP natively over stdio. Build the server once and your service appears in all of them. This is the USB-C scenario playing out: one standard, many clients, compounding returns as the client base grows.

For enterprise workflow integrations, the picture is less settled. Most enterprise AI agents still use proprietary plugin systems or direct API integration. MCP adoption in this space is real but uneven. Building an MCP server now is a reasonable investment; expecting it to replace existing integrations entirely is premature. Track the spec, evaluate when a concrete client-side demand appears, and do not invest in an MCP server based on the assumption that enterprise clients are already MCP-native.

The clearest case for not building an MCP server: you have a single AI client, you control both sides of the connection, and your tool surface is stable. In that scenario, native tool use in your LLM provider's API is simpler, faster to debug, and has fewer moving parts. MCP adds a subprocess or network hop, a session handshake, and a tool-list round trip. If you do not get the multi-client benefit, you've paid the cost without collecting the value.

The security assumption buried in the spec

The attack vector is indirect prompt injection through tool outputs. Your agent calls a document-search tool. The search tool returns a page. That page contains crafted instructions: ignore previous context, take a different action, exfiltrate data. The MCP client injects the tool result into the model's context without modification. The model may act on the instructions.

This is not a flaw in MCP specifically. Any system that injects external data into an LLM's context faces the same risk. But MCP amplifies the exposure by making it easy to connect agents to many data sources quickly. More sources means more injection opportunities. The 2025-11-25 spec added tool name standardisation and guidance on capability scoping specifically to make explicit allowlists easier to maintain, and these are the mitigations worth implementing first.

The practical response: treat all tool outputs as untrusted input. Sanitise before context injection, or use a gateway layer that does it for you. Log all tool calls, inputs, and outputs in production. Start with an explicit allowlist of the tools your agent actually needs rather than exposing the full surface of every server you connect to.

What MCP deliberately leaves out

Section 1.1 of the current specification is direct: MCP is not an agent framework. It does not define how clients choose which server or tool to invoke for a given task, how multi-step reasoning should proceed, or how errors should propagate up to the user.

Tool selection is entirely the application layer's problem. Deciding which of 30 available tools to call for a given request, with the right parameters, at the right point in a multi-step workflow, is not something MCP helps with. A model given 30 tools will frequently call the wrong one, call the right one with wrong parameters, or loop without knowing when to stop. Conversation management, prompt construction, and retry logic are all out of scope as well.

This is the right architectural call. A protocol that tried to own the reasoning layer would be unusable. But it means teams that adopt MCP expecting their agents to work better out of the box will be disappointed. The integration surface becomes cleaner. The quality of the agent's decisions stays exactly where it was.

A working decision framework

The teams getting the most from MCP in 2026 share one characteristic: they knew which side of the connection they were building before they started. Tool consumers building multi-client agents get immediate value from the single-integration model. Tool providers targeting the developer-tooling ecosystem get increasing returns as the client base grows. Everyone else should track the spec, build against their LLM provider's native interface for now, and revisit the decision when a concrete multi-client use case appears.