The Model Context Protocol, Explained for Builders
Every team that builds more than one agent writes the same adapter twice: connect to a system, describe what it can do, expose those capabilities to a model in whatever shape today\u2019s client expects. The Model Context Protocol exists to stop that duplication by standardising the interface between an agent client and a tool server.
That is genuinely useful, and it is also narrower than the enthusiasm suggests. MCP describes how capabilities are advertised and invoked. It does not decide who is allowed to invoke them, and confusing those two is where the security incidents come from.
What the protocol standardises#
- Discovery: a server tells a client which tools and resources it offers, with schemas.
- Invocation: the client calls a tool with typed arguments and receives a structured result.
- Resources: read-only content the client can pull into context on request.
- Transport: a common wire format so a client and a server written by different people interoperate.
What it deliberately does not do#
MCP does not authenticate your users, does not decide which records a given user may read, and does not decide whether an action needs human approval. Those remain your responsibility, and they must live on the server side of the boundary — a client asking nicely for permission is not a permission system. The most common architectural error is to expose a broad tool such as `run_query` over MCP and rely on the agent’s prompt to keep it in bounds.
Treat every MCP tool as if a confused or manipulated caller will invoke it with the worst plausible arguments, because sooner or later one will.
Where it pays off today#
| Situation | Value of MCP |
|---|---|
| One internal system, several agent clients | High — write the server once |
| Desktop assistants reading local context | High — the ecosystem is built around this |
| A single agent with three bespoke tools | Low — direct function calls are simpler |
| Third-party tools you do not control | Medium — convenient, but audit the server |
A safe way to adopt it#
- Wrap narrow capabilities, not general power: `get_order(id)` rather than `sql(query)`.
- Enforce authorisation inside the server, per call, using the identity of the end user rather than a service account with everything.
- Return honest, short errors — `not found`, `not permitted` — so the agent can respond sensibly instead of retrying.
- Log every invocation with arguments and caller identity; this is your audit trail when someone asks what happened.
- Pin the servers you depend on to versions you have reviewed, exactly as you would any dependency.
The supply-chain question#
A third-party MCP server is code that describes tools to your agent and receives whatever arguments your agent decides to send. Tool descriptions are part of the model’s context, which means a malicious or careless description can influence behaviour. Review servers before adopting them, prefer ones you can read, and keep untrusted servers away from any client that also has access to sensitive systems. This is ordinary dependency hygiene applied to a new kind of dependency.
Frequently asked questions
Do I need MCP to build an agent?
No. Direct function calls are simpler for a single agent with a handful of bespoke tools. MCP starts paying when the same capability must be reachable from several clients, or when you want to consume tools built by other teams.
Is MCP secure by default?
It is a transport and discovery standard, not a security model. Authentication, per-user authorisation and approval gates are yours to implement on the server side, and they must not be delegated to the agent’s prompt.
Can MCP servers be a prompt injection vector?
Yes — both through tool descriptions that enter the model context and through returned content. Treat server output as untrusted input, keep tool scopes narrow, and do not point an agent with production write access at servers you have not reviewed.
model context protocolmcp explainedagent tool standardmcp securitytool discovery
