MCP: what a tool protocol buys you, and what it costs

The problem it solves

Without a standard, every combination of application and data source needs its own connector. Five applications and eight systems is forty integrations, each with its own auth handling, its own schema conventions, and its own bugs.

The Model Context Protocol is an attempt to make that five plus eight instead of forty. A server exposes capabilities; a client (an assistant, an IDE, an agent) consumes them. Anything that speaks the protocol can talk to anything else that does, and the maintainer of a system writes one server rather than one connector per consumer.

Three kinds of capability, and the distinction matters:

• Tools: actions the model may invoke. This is what most servers ship.
• Resources: content the client can read and attach to context, addressed by URI. Selected by the application or the user, not the model.
• Prompts: reusable templates a user can invoke deliberately.

The useful part of that split is the third column, which is who decides. Tools are model-driven; resources are application-driven; prompts are user-driven. Systems that blur it end up with a model deciding to read things nobody meant it to read.

What it actually is

JSON-RPC over one of two transports: stdio for a server running as a local subprocess, and streamable HTTP for a remote one. The client starts a session, calls tools/list to discover what exists, and then tools/call to invoke.

{"jsonrpc":"2.0","id":3,"method":"tools/call",
 "params":{"name":"search_tickets",
           "arguments":{"query":"refund not received","limit":5}}}

Underneath, nothing changes about the model. The tool list is fetched from a server rather than hard-coded, and the result comes back over a socket instead of a function call. Every lesson about tool design still applies exactly: good names, negative clauses in descriptions, tight schemas, identity never in the arguments.

When it is worth it

Use a protocol when the set of tools is not known at build time. An assistant that different customers connect to their own systems; an IDE where the user adds capabilities; an internal platform where six teams each expose their own service without touching your codebase. Here the indirection pays for itself.

Do not use one when you have four tools and control both ends. Four Python functions in a dictionary is less code, has fewer moving parts, no subprocess to supervise, no session to reconnect, and one less thing to be down at three in the morning. A protocol solves a coupling problem, and if you do not have a coupling problem it is pure overhead.

The honest middle case is that MCP is worth adopting early if you expect third parties to extend your product, and worth deferring if you do not.

The security surface, stated plainly

This is the part that deserves your attention, because a tool protocol moves trust boundaries.

A server you install runs on your machine with your permissions. A stdio server is a subprocess. It can read your files, your environment variables and your keys. Installing one from an unfamiliar source is exactly as consequential as running any other program from that source, and the packaging makes it feel lighter than it is.

Tool descriptions come from the server and go into your prompt. A malicious or compromised server can put instructions in a description: text that the model reads as guidance and that you never see. This is prompt injection arriving through the metadata channel rather than through user content, and it is specific to protocols that fetch definitions at runtime.

Definitions can change after you approved them. A server can serve one description on Monday and a different one on Friday. If your approval was a one-time decision, it was a decision about a thing that no longer exists. Pin versions where you can, hash the tool definitions, and re-prompt on change.

Tokens are usually broader than the task. Connecting a server to a whole workspace when the job needs one folder is the common shape, and it means a single confused tool call can reach everything.

Mitigations that are worth the effort: run servers with the narrowest credentials that work, keep an allowlist of servers rather than installing freely, log every tools/call with its arguments, require confirmation for writes, and treat tool results as untrusted text: a server returning a document containing “ignore previous instructions” is the ordinary case, not the exotic one.

The thing to take away

A protocol changes the plumbing, not the physics. The model still cannot run anything; your client does. Authorisation is still your job and still belongs to the session, not the arguments. Every tool is still a place where text from outside your system enters your model’s context.

What MCP gives you is that the tools available to your assistant become a deployment concern rather than a code change, which is a large operational win and a new place to be careful.