Glossary
Model Context Protocol
Also: MCP · MCP server
An open standard through which language models reach tools and data sources: one shared interface instead of one integration per vendor.
Before MCP you rewrote the connection of a tool for every model and every environment. The protocol standardizes how a model learns which tools exist, which parameters they expect and what they return. One server, many consumers.
An MCP server is not AI, it is an ordinary service: it offers tools, accepts calls, executes them and responds. The interesting part is therefore rarely the protocol but what sits behind it: access rights, logging, error behaviour, and the question of what a call can actually do in the target system.
This is exactly where demo and production part ways. In the demo the server reaches the database with an all-powerful key. In production you need the identity of the user on whose behalf the action happens, a permission model behind it, and an audit trail that later answers who triggered what.
The second production concern is the number of tools. Every tool offered costs context, because its description is sent with every call, and it raises the chance of a wrong choice. Twenty well-described tools are worse than six that cover the task.
On the security side, an MCP server is a new attack surface. Whatever sits in a document that a tool returns lands in the context of the model and can be read there as an instruction. Anyone offering writing tools needs a confirmation step for everything that cannot be undone.
How you notice it
- The tool integration was rewritten for every model.
- The server reaches all data with a single technical account.
- There is no record of which user triggered which tool.
- Writing tools run without a confirmation step.
Not to be confused with
- Function calling
- The model-side mechanism for calling a tool at all. MCP standardizes how tools are described and connected. Function calling works without MCP, but differently per vendor.
- REST API
- An interface for programs. MCP additionally describes tools so a model can choose them without prior knowledge. Often an MCP server is a thin layer in front of existing REST services.
- RAG
- Delivers knowledge into the context. MCP delivers the ability to act. Many systems need both, but they are different problems.
- Vendor plugins
- Tied to one provider. MCP is open, which is why the same server can be used by different models and tools.
When it fits
- Several models or environments should use the same tools.
- The model should act in existing systems, not just produce text.
- Access has to be traceable because it triggers business transactions.
When it does not
- For a single fixed call a direct integration is enough.
- When only knowledge is missing and nothing should be triggered: then RAG is the topic.
- Without a permission model in the target system. An MCP server inherits its weaknesses and makes them easier to reach.
How to approach it
- Cut tools by task, not by tableA tool "create customer" beats three that write individual fields. Coarse, business-level cuts reduce wrong choices and context consumption.
- Separate reading from writingReading tools are uncritical, writing ones need their own approval. Making that separation visible in the server is easier than retrofitting it later.
- Pass the identity throughThe call acts on behalf of a user, with that user's rights, not with a service account. Via OAuth and a token broker, not a shared key.
- Log every callWho, which tool, which parameters, which result. Without that trail you cannot reconstruct what happened afterwards, and that is exactly what will be asked.
- Set cost and limitsRate limit per user, ceiling on calls per transaction, timeout per tool. A model stuck in a loop otherwise calls without bound.
- Treat returns as untrusted dataWhat a tool returns can contain instructions. Keep it clearly separate from the system text and never execute it unchecked as a command.
Frequently asked
What is the difference between MCP and function calling?
Function calling is the mechanism in the model that allows it to call a tool at all. MCP standardizes the other side: how tools are described, offered and connected. Function calling works without MCP, but the integration differs per vendor and gets rewritten with every change.
How many tools should a server offer?
As few as possible, cut along business tasks. Every tool description goes into the context on every call and therefore costs money and attention. Six clearly separated tools usually deliver better results than twenty fine-grained ones.
How do you secure an MCP server?
Pass the user identity through instead of using a service account, check rights in the target system rather than in the server, require confirmation for writing calls, log every call, set rate limits, and treat tool returns as untrusted data. The last point is forgotten most often and is the entry point for prompt injection.
Do you need MCP or is a normal API enough?
If exactly one fixed tool is connected to exactly one model, a direct integration is enough. MCP pays off as soon as several tools, several models or several environments are involved, and there it saves the duplicated work that otherwise comes with every change.