What is Model Context Protocol, and what problem does it solve?
MCP standardises how an AI application connects to tools and data, so each integration is written once rather than per product. What it covers, what it does not, and the trust question.
Rebecca Pearson11 min read
On this page
Model Context Protocol is an open standard for connecting AI applications to external tools and data. Rather than every AI product implementing its own integration with every system, a system exposes an MCP server once and any MCP-capable client can use it.
The problem it addresses is combinatorial. Without a standard, connecting five AI applications to twenty systems is a hundred integrations, each written and maintained separately. With one, it is twenty-five.
What we'll cover
The problem it solves
Every AI application needs the same integrations — files, databases, ticketing systems, repositories, internal services.
Each has implemented them separately, in its own format, with its own authentication and its own idea of what a tool description looks like.
The system being integrated gains nothing from that repetition. A ticketing tool does not want to build and maintain five separate AI integrations.
A standard makes integration reusable. Expose the capability once, in an agreed shape, and any compatible client can use it.
The analogy people reach for is a common connector for AI applications, which is roughly right: the value is in the standardisation rather than in any capability that was previously impossible.
Servers, clients, and hosts
Three roles, and getting the vocabulary straight makes everything else clearer.
A server exposes capabilities — access to a system, a dataset, a set of operations.
A client connects to a server, one per connection, handling the protocol.
A host is the application the user interacts with, which runs clients and decides what to do with what they provide.
The host holds the model and makes the decisions. The protocol does not specify how a model chooses to use a tool; that is entirely the host's business.
Servers are usually small. A server wrapping one system is a modest piece of software, which is the point — the barrier to exposing something is deliberately low.
What a server exposes
Three kinds of thing, and the distinction is genuinely useful.
Tools are operations the model can invoke — search, create, update, run a query. These have side effects and are the part requiring care.
Resources are data the host can read — files, records, documents — which are provided as context rather than called as actions.
Prompts are reusable templates a server offers, letting a system supply the right way of asking about itself.
Descriptions matter enormously. A model decides whether and how to use a tool from its description, so a vague one produces misuse and a precise one produces correct use. This is the highest-leverage thing in a server.
Schemas constrain inputs, which is what turns a model's intent into a well-formed call rather than a hopeful string.
Where it runs
Locally, as a process on the same machine as the host, communicating over standard input and output. Simple, and it gives the server the machine's access.
Remotely, over HTTP, which suits shared servers and organisational deployments.
Local servers inherit local access. A server running as you can reach what you can reach, which is convenient and is the core of the trust question below.
Remote servers need authentication and authorisation, like any service, and the protocol accommodates this rather than solving it for you.
The deployment choice is mostly about who the server is for — one person's machine, or a team.
What it does not solve
Worth being clear, because a standard attracts expectations.
It does not make the model better at using tools. A poorly described tool is used poorly regardless of the transport.
It does not handle authorisation for you. What a given user may do through a server is the server's responsibility.
It does not prevent prompt injection. Content returned by a tool can contain instructions, and the protocol has no opinion about that.
It does not make integrations correct. A server wrapping an API badly is a bad integration in a standard format.
It does not replace ordinary automation. Deterministic, scheduled work does not need a model in the loop, and putting one there adds cost and variance for nothing.
The trust question
The part that deserves the most attention and gets the least.
A server can do whatever its permissions allow. Installing one is granting software access to systems, in the same way installing any tool is.
Tool results enter the model's context, which means content from a system you do not control can contain text intended to influence what the model does next. Treat returned content as data rather than as instruction.
A model deciding to call a tool is not a person deciding. For anything consequential — sending, deleting, paying, publishing — a person should confirm.
Scope server credentials narrowly, exactly as you would for any integration. Read-only where reading is the purpose.
Know what you are running. A server from an unfamiliar source with broad local access is a supply chain decision, not a convenience.
Log what was called. When something unexpected happens, knowing which tools ran with what arguments is the difference between an explanation and a mystery.
Building a server worth using
Write the tool descriptions carefully. They are the interface the model reads, and they determine whether it uses your tool correctly. This is where most of the quality is.
Make them specific about when to use the tool, not only what it does, since a model choosing between several similar tools needs the distinction.
Constrain inputs with schemas, so a malformed call fails clearly rather than producing something surprising.
Return errors that explain, in language a model can act on — "no record with that identifier" rather than a status code.
Keep responses small. A tool returning a large document consumes context that the host needs for reasoning, and truncating thoughtfully beats returning everything.
Separate read from write tools clearly, so a host can grant them differently.
Deciding what belongs behind a model
The question worth asking before exposing anything, because the answer is frequently that no model is needed.
If the steps are always the same, write the automation. A scheduled export, a routine notification, a fixed transformation — these want determinism, not a decision each time.
If the sequence depends on what is found, a model helps. Investigating an alert, answering an open question across systems, triaging something ambiguous.
Cost and variance are real. A model in the loop costs per call and produces slightly different behaviour each time, which is a poor trade for work that was already predictable.
Latency matters too. A deterministic automation returns in milliseconds; a model deciding does not.
Auditability differs. A fixed automation did what it always does; a model's run needs its inputs and outputs logged to be explainable afterwards.
Mixing is normal. A model deciding what to do, calling deterministic automations to do it, is usually a better shape than either alone.
Where CodeWords fits
CodeWords connects to more than 3,000 integrations and builds automations from a plain-language description, which covers the deterministic side of this — the work that should run reliably on a schedule or a trigger rather than being decided each time.
- Open CodeWords and start a new automation.
- Describe what should happen to Cody, the automation builder, including the exceptions.
- Connect the systems involved once and reuse the connections.
The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
What to get right first
Tool descriptions, if you are building a server. They are what the model reads to decide whether and how to call something, and a precise description is the difference between a tool used correctly and one used in ways you did not anticipate. No amount of schema validation compensates for a vague description.
Two habits make the difference. Treat everything a tool returns as untrusted data rather than as instruction, since content from an external system can contain text aimed at the model. And require human confirmation for anything consequential, because a model deciding to send, delete, or pay is not the same as a person deciding to.
Frequently asked questions
What problem does MCP actually solve?
The combinatorial one. Without a standard, connecting several AI applications to many systems means writing each integration separately. With one, a system exposes its capabilities once and any compatible client can use them.
What is the difference between a tool and a resource?
A tool is an operation the model can invoke, with side effects. A resource is data the host can read and provide as context. The distinction matters because tools are the part that needs authorisation and confirmation.
Does MCP make a model better at using tools?
No. It standardises the connection. How well a tool is used depends on its description and schema, which is why writing those carefully is the highest-leverage part of building a server.
Is it safe to install an MCP server?
It is a supply chain decision, the same as installing any software. A local server has the access you have, so treat an unfamiliar one accordingly and scope its credentials as narrowly as the purpose allows.
What about prompt injection?
The protocol has no opinion on it. Content returned by a tool can contain text intended to influence the model, so it should be treated as data rather than instruction, and consequential actions should require a person to confirm.
Should everything be an MCP server?
No. Deterministic scheduled work does not need a model deciding each time — that adds cost and variance for nothing. MCP suits cases where the sequence genuinely depends on what is found.
How do I make a server the model uses correctly?
Specific descriptions covering when to use the tool and not only what it does, constrained input schemas, errors that explain in plain language, and small responses that do not consume the context the host needs for reasoning.
When should a model be in the loop at all?
When the sequence depends on what is found. If the steps are always the same, a deterministic automation is cheaper, faster, and explainable — putting a model in front of predictable work adds cost and variance for nothing.
What is a good shape for combining the two?
A model deciding what to do, calling deterministic automations to do it. The judgement stays where variation is useful, and the actions stay repeatable and auditable.
Where should a server run?
Locally for one person's tools, remotely over HTTP for anything shared by a team. A local server inherits your access, which is convenient and is exactly why an unfamiliar one deserves scrutiny.
What should I log?
Which tools were called, with what arguments, and what they returned. When a model does something unexpected, that record is the difference between an explanation and guesswork.