MCP is an open client-server protocol that standardises how AI applications connect to external tools and data. Before it, every application-to-tool pairing needed bespoke integration work. With it, any compliant client can talk to any compliant server, which turns an N-times-M problem into N-plus-M.
What changed is not that models gained the ability to call tools. That existed. What changed is that the integration surface stopped being proprietary to each application.
That distinction is easy to undersell and is the entire point. The protocol’s value is not technical novelty; it is that the same server works everywhere.
At a glance
- Client-server architecture: the host application runs clients, each connected to one server
- Servers expose tools (actions), resources (data) and prompts (templates)
- Standardisation is the value; the transport layer is an implementation detail
- A server is a normal program, not a model, and can be written in any language
- The security boundary sits at the host, which decides what a model may invoke
- Discovery is dynamic, so capabilities can change without redeploying the client
What problem does it actually solve?
Combinatorial integration cost.
With five AI applications and twenty internal systems, bespoke integration means up to a hundred connectors, each maintained separately and each breaking independently. Standardising the interface means twenty servers and five clients, and any new application immediately reaches all twenty systems.
Figure 1 — The integration surface, before and after
Bespoke integrations
Every application implements its own connector for every system it needs to reach.
Cost grows with the product of applications and systems. A new application starts from zero and re-solves problems already solved elsewhere.
N x M
Shared protocol
Each system exposes one server. Each application implements one client.
Cost grows with the sum. A new application inherits every existing server on day one, and a new server is instantly available to every application.
N + M
This is a familiar shape. It is the same argument that made language server protocols worthwhile for editors: the win comes from agreeing on an interface, not from any individual implementation being clever.
What does a server expose?
Three kinds of capability, and the distinction between them matters more than it first appears.
| Primitive | What it is | Controlled by |
|---|---|---|
| Tools | Actions the model can invoke, with defined inputs and effects | The model decides when to call |
| Resources | Data the application can read and place in context | The application decides what to include |
| Prompts | Reusable templates or workflows the server offers | Typically the user selects |
The control column is the part worth internalising. Tools are model-driven, resources are application-driven, prompts are user-driven. Conflating them produces designs where the model reaches for things it should have been handed, or where the application pre-loads context the model should have chosen.
How does the architecture fit together?
Figure 2 — Who talks to whom
- LAYER 1Host applicationThe AI product the user interacts with. Owns permissions and policy.
- LAYER 2ClientOne per server connection, managed by the host, handling the protocol
- LAYER 3ServerAn ordinary program exposing tools, resources and prompts
- LAYER 4The actual systemDatabase, API, filesystem or service the server wraps
Note where the model is not: it never speaks the protocol directly. The host mediates, which is precisely what makes permission enforcement possible rather than aspirational.
A server is a normal program. It has no model inside it, needs no machine learning knowledge to write, and can be implemented in whatever language the underlying system is already written in. That is a significant part of why adoption is practical.
Where does security sit?
At the host, and this is the design decision most worth understanding before deploying anything.
Because the host owns the client connections, it is the enforcement point for which servers are reachable, which tools may be invoked, and whether a given invocation needs user approval. The model proposes; the host disposes.
Watch for this
A server can describe its own tools, and those descriptions enter the model’s context. A malicious or compromised server can therefore attempt to influence model behaviour through tool descriptions alone, without ever being called. Treat third-party servers as untrusted input, review what they declare, and prefer servers you or your organisation control for anything sensitive.
The practical implications: run untrusted servers with least privilege, require explicit approval for actions with side effects, and log every invocation with its arguments. None of that is unique to MCP, and all of it is easier because the protocol gives you one consistent place to apply it.
How is this different from function calling?
They operate at different layers, and the confusion between them is common enough to be worth stating plainly.
Function calling is a model capability: the model emits a structured request to invoke a named function. MCP is a transport and discovery standard: it defines how an application finds out which functions exist and how it communicates with whatever implements them.
You need both. Function calling without a protocol means every integration is hand-wired. A protocol without function calling has no mechanism for the model to express intent.
Where do teams go wrong?
Exposing too many tools
Every tool declaration consumes context and adds a decision the model must make correctly. A client connected to servers offering two hundred tools will choose badly. Scope connections to what the task needs.
Treating tool descriptions as documentation
Descriptions are instructions the model reads at decision time, not reference material for humans. Vague descriptions produce wrong tool selection, and the fix is usually rewriting the description rather than changing the model.
Skipping the approval design
Deciding which actions need human confirmation is product design, not a configuration afterthought. Getting it wrong in the permissive direction is the failure with real consequences.
What do experienced teams do differently?
They treat a server as a product surface with its own versioning.
Tool names, argument shapes and descriptions are an interface that clients depend on. Changing them breaks behaviour in ways that surface as odd model decisions rather than as errors, so they version deliberately and deprecate rather than mutate.
They also write tool descriptions the way they would write a good function signature comment for a new colleague: what it does, when to use it, when not to, and what it costs. That last part matters, because a model given no cost information will happily call an expensive tool for a trivial reason.
A short glossary
- Host
- The AI application the user interacts with, which manages client connections and enforces permissions.
- Client
- The protocol-speaking component inside the host, typically one per connected server.
- Server
- An ordinary program exposing tools, resources and prompts over the protocol.
- Tool
- An invocable action with defined inputs, selected by the model at decision time.
- Resource
- Readable data the application can choose to place into context.
Key takeaways
- MCP standardises the interface between AI applications and external systems, converting N-times-M integration into N-plus-M.
- Servers expose tools, resources and prompts, controlled by the model, the application and the user respectively.
- The model never speaks the protocol; the host mediates, which is what makes permissions enforceable.
- A server is an ordinary program with no model inside it, writable in any language.
- Tool descriptions enter model context, so a malicious server can attempt influence without being called.
- Function calling is a model capability; MCP is the discovery and transport standard around it.
- Above all, do not connect every available server at once — tool sprawl degrades selection accuracy.
Frequently asked questions
What is the Model Context Protocol?
An open client-server protocol standardising how AI applications connect to external tools and data sources. It defines how an application discovers available capabilities and communicates with whatever implements them, so any compliant client can work with any compliant server.
How is MCP different from function calling?
They sit at different layers. Function calling is a model capability for emitting structured invocation requests. MCP is the discovery and transport standard defining how applications find out what functions exist and how to reach them. Production systems use both together.
What are tools, resources and prompts?
Tools are actions the model chooses to invoke. Resources are data the application decides to place in context. Prompts are reusable templates the user typically selects. The distinction matters because it determines who initiates each interaction.
Do I need machine learning knowledge to write a server?
No. A server is an ordinary program with no model inside it, wrapping a database, API or filesystem. It can be written in whatever language the underlying system already uses, which is a significant part of why the protocol is practical to adopt.
Where are permissions enforced?
At the host application, which owns the client connections and therefore decides which servers are reachable, which tools may be invoked, and what requires user approval. The model proposes actions; the host decides whether they happen.
Are third-party servers safe to connect?
Treat them as untrusted. Tool descriptions from a server enter the model’s context, so a compromised server can attempt to influence behaviour without ever being invoked. Review what a server declares, run it with least privilege, and prefer controlled servers for sensitive work.
How many tools should a client have access to?
As few as the task requires. Every tool declaration consumes context and adds a selection decision the model must get right. Connecting to servers offering hundreds of tools reliably degrades choice quality, so scope connections per task rather than exposing everything.
Why do tool descriptions matter so much?
Because they are instructions read at decision time, not documentation for humans. Vague descriptions cause wrong tool selection, and the remedy is usually rewriting the description rather than changing models. Include what it does, when not to use it, and what it costs.
References
- Anthropic. Model Context Protocol documentation, covering architecture, primitives and transports.
- Model Context Protocol. Reference implementations and specification.
- Schick, T., et al. Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv:2302.04761. Background on models invoking external tools.
