MCP — Frequently Asked Questions
Practical answers on the Model Context Protocol — what problem it solves, whether it is worth adopting, the security questions that matter, and how it compares to writing tool integrations directly.
What it is#
What problem does MCP actually solve?#
Before it, every AI application implemented its own way of exposing tools and data to a model. Connecting an assistant to your ticketing system meant writing that integration for that application, again, in its particular style.
The Model Context Protocol standardises the interface: a server exposes tools, resources and prompts; any compatible client can use them. Write the integration once, use it from anything that speaks the protocol.
Is it a standard or one vendor's format?#
It was introduced by Anthropic and published openly, and adoption has spread across multiple clients and tool vendors. Treat it as you would any young standard: genuinely useful, still moving, and worth pinning versions against.
Do we need it?#
If you are building one application with three integrations, probably not — direct tool definitions are simpler and you avoid a moving dependency.
It earns its place when the same integrations are needed from several applications, when you want to use third-party connectors rather than writing your own, or when you want a clean boundary between "the assistant" and "what it can reach".
Building and using#
What is the difference between tools, resources and prompts?#
Tools are actions the model can invoke. Resources are data it can read. Prompts are reusable templates the server offers.
In practice most servers are mostly tools. The distinction matters for permissions: reading is generally cheap and safe, invoking is where consequences live.
Should we build our own server or use existing ones?#
Use an existing one where it fits and you trust the publisher. Build your own for anything internal, because nobody else can expose your systems.
Building one is not difficult — the protocol is small. The difficulty is deciding what to expose and how narrowly, which is a design question rather than an implementation one.
How narrow should a tool be?#
As narrow as the job allows. "Run any SQL query" and "look up an order by id" are both possible; one of them is a database console handed to a probabilistic system.
Narrow tools are easier to permission, easier to log meaningfully, easier to test, and produce far better model behaviour because the choice is unambiguous.
Security#
What is the main risk?#
That you have connected a decision-making system to real capability. The protocol does not change the fundamentals covered in AI agents: sort tools by reversibility, require confirmation for consequential actions, and never let content the model reads directly trigger something irreversible.
MCP makes connecting things easy, which makes connecting too much easy.
Are third-party servers safe to install?#
Treat one exactly as you would any dependency with production access — which is to say, with more care than most dependencies get. Read what it does, pin the version, scope its credentials narrowly, and understand who can change its behaviour.
An auto-updating third-party server with broad credentials is a supply chain risk with a friendly interface.
Can a server influence the model beyond what it returns?#
Yes, and this is the part people miss. Tool descriptions are injected into the model's context, so a server can shape behaviour through description text alone — "always call this before answering", or anything else phrased as guidance.
Read tool descriptions as untrusted input. They are prompt content authored by whoever wrote the server.
What credentials should a server have?#
Its own, scoped to exactly what its tools need, revocable in one action, and logged. Never a human's credentials and never a shared account — when something goes wrong you want to answer "what did this server touch" without cross-referencing three systems.
Should tool responses be trusted?#
No. A response can contain content from a web page, a ticket, or a document written by someone else. It is data, not instruction, and it should be handled with the same care as any retrieved content.
Operating#
How do we know what it did?#
Log every call with arguments and result, and keep the logs long enough to investigate. The standard to hold yourself to is whether you could reconstruct, from logs alone, why a particular tool was called three days ago.
What happens when a server is unavailable?#
Decide this deliberately. The client should degrade sensibly — report that a capability is unavailable rather than hanging, retrying indefinitely, or silently answering without the data it should have used.
The last one is the dangerous case: an answer produced without the tool that was supposed to inform it, presented with the same confidence.
How many servers is too many?#
When you can no longer answer "what can this assistant do?" without opening a config file. Every connected server widens capability and surface area at once.
Periodically review what is connected and disable what is not being used — the review is cheap and nobody ever does it unprompted.
Is it worth adopting now?#
For internal tooling, yes — the cost is low and the boundary it creates is genuinely useful. For anything customer-facing and consequential, adopt it with the same review you would give any component with production access, and pin your versions.