MCP: What the Model Context Protocol Actually Standardises

Before MCP, connecting a model to your systems meant writing the same adapter repeatedly. Your Jira integration for Claude. Your Jira integration for GPT. Again for the internal agent, which has its own tool format. Every model times every tool, each one hand-written.

That is an M × N problem, and it is exactly the shape protocols exist to flatten. MCP turns it into M + N: a tool speaks MCP once, any client can use it.

Three things a server exposes

The distinction matters more than it first appears, because it encodes who decides.

Tools — actions the model chooses to invoke. create_issue, run_query, send_message. Model-controlled, which is precisely why they are the security surface.

Resources — data the application chooses to supply. A file, a schema, a record. Application-controlled: the client decides what to attach, so the model cannot reach for arbitrary data on its own.

Prompts — templates the user chooses. A slash command, a saved workflow. User-controlled.

The mechanics

JSON-RPC 2.0 over one of two transports:

• stdio — the server is a subprocess of the client. Local tools, developer machines, no network surface at all.
• Streamable HTTP — remote servers, with Server-Sent Events for streaming. This is where authentication and network exposure become real concerns.

Discovery happens at runtime. The client asks tools/list, gets names, JSON Schema for arguments, and descriptions; it converts those into whatever tool format its model expects. Add a tool to your server and connected clients see it without redeployment — genuinely useful, and worth noticing that a tool description is text the model will read, which makes it an injection surface if your server aggregates third-party tools.

Where it fits with what you already have

MCP does not replace RAG or function calling — it sits underneath both.

• Function calling is the model emitting a structured request. Unchanged.
• MCP is how the application discovers what may be requested and executes it.
• RAG is a technique you might implement through MCP by exposing a search_documents tool. MCP has no opinion on chunking, embeddings or ranking — those remain entirely yours. See RAG vs fine-tuning for that decision.

A reasonable summary: MCP standardises the plumbing, not the retrieval quality, and not the authorisation.

The part that is still your job

This is where teams get into trouble, because a protocol that handles discovery feels like it handles more than it does.

MCP does not scope tools to the requesting user. If your run_query tool holds a database credential, then every user of that client can run every query it permits. The model was never the security boundary and neither is the protocol. The token your tool acts with must carry the requesting user’s authority, narrowed to the operation — the agent identity problem in full.

Tool descriptions and results are untrusted text. A malicious or compromised server can return content designed to redirect the model. Aggregating third-party MCP servers means importing their text into your prompt. Treat everything crossing that boundary as hostile input — see prompt injection.

Destructive tools need confirmation. MCP marks tools with hints such as readOnlyHint and destructiveHint, but these are advisory metadata from the server, not enforcement. The client decides whether to prompt. Do not rely on a server to be honest about its own danger.

Local servers run as you. A stdio server is a subprocess with your user’s permissions and full filesystem access. Installing one is equivalent to installing any other executable, with the same supply-chain questions.

When it is worth adopting

Yes if you are exposing capabilities to more than one client or model, if you want tools discoverable at runtime rather than compiled in, or if you are publishing an integration for others to consume.

Probably not yet if you have one model, one application and three tools. A direct function-calling implementation is less machinery, and the protocol’s value is proportional to how many things are on each side of the M × N.

What you have actually gained

An interface boundary, and a vocabulary.

The genuine win is that a tool is now written once against a stable contract instead of once per consumer, and that a client can find out what a server can do without being rebuilt. That is a real reduction in integration cost, and it is the whole of what a protocol can give you.

What it explicitly does not give you is safety. MCP standardises how to call a tool. Deciding whether this user may call it, with these arguments, right now remains entirely on your side of the connection — and that decision is the one that determines whether an agent is shippable.