- MCP is an open standard for connecting AI applications to tools and data without a custom integration for every pair.
- A server can expose tools, resources and prompts; the client lives inside the application (the host).
- An MCP server is somebody else's code with access to your data, so trust must be assessed.
Before MCP existed, every AI application that wanted to reach a calendar, a database or a repository needed its own integration. With ten applications and twenty services that grows as a product. The Model Context Protocol is an attempt to solve this with one common standard. The documentation compares it to a USB-C port: one socket, many devices.
Three roles: host, client, server
The specification names three roles. The host is the AI application you talk to, such as a chat assistant or a code editor. The client is a component inside the host that keeps a connection to one server. The server is a service that provides context and capabilities: a local program that reads files, or a remote cloud service. Communication relies on JSON-RPC 2.0 messages, and the connection is stateful, starting with a negotiation of what each side can do.
This layout has a practical consequence: once someone writes an MCP server for their service, every application with an MCP client can use it. As a user you add the server to the application once, and from then on the model can use it. The specification admits it took inspiration from the Language Server Protocol, which standardized support for programming languages across editors to a similar effect.
Three kinds of server capabilities
A server can expose three kinds of things, and it is worth telling them apart because they differ in who decides on their use.
| Tools | Resources | Prompts | |
|---|---|---|---|
| What it is | Functions to execute | Data and context to read | Ready-made command templates |
| Who decides on use | The model, usually with user consent | The application or the user | The user |
| Example | Create a ticket | Contents of a file | Code review template |
Tools are the most visible, because they are how the model does something: creates a ticket, queries a database, sends a message. Resources are calmer, since they only supply material to read. Prompts are ready templates that the user runs on their own, for example as a menu command. Clients, in turn, can offer servers their own capabilities, such as asking the user to fill in a form.
What it looks like in practice
In Claude Code, for example, you add a remote server with a single command and then ask about something you previously had to paste from another tool: a ticket from a task system or the state of a deployment. The documentation advises connecting a server when you catch yourself copying data from one tool into the chat. That is a good criterion: if you do not have that problem, the server is unnecessary, and every added server means more tools in the model’s context and more surface for risk.
A detailed description of adding and assessing servers is in the article How to add an MCP server to Claude Code and judge whether to trust it.
- 01NeedYou copy data from a tool into the chat.
- 02ChoiceYou look for a server in the registry or a repository.
- 03AssessmentAuthor, code, permissions, data scope.
- 04ConnectionYou add the server to the client.
- 05ConsentYou approve tool use.
- 06ReviewWhat was actually called.
What MCP does not do
Several misunderstandings have grown around the standard. MCP does not make a model smarter: it gives it access to data and actions, but the quality of decisions still depends on the model and on how clearly the task is described. MCP does not replace APIs, because a server usually wraps a service’s existing API in a unified description that an AI application can read. MCP does not provide security by itself: the protocol sets out principles, but the server’s implementation and the client’s configuration decide what is actually allowed. Finally, every tool call costs time and tokens, and the descriptions of all connected tools occupy space in the context window, so the more servers you add, the harder it is for the model to pick the right tool.
When a plain script is enough
If a task has fixed steps and repeats every day, an agent with MCP servers may be overkill. A simple script or a workflow in an automation tool is then cheaper, faster and more predictable; you will find a comparison of approaches in the Automation and n8n hub. MCP shines where the task is open-ended and the model has to decide which tool to call and in what order.
Trust: a server is somebody else’s code
The most important security remark is simple. An MCP server is a program that gets access to whatever you expose to it, and its tool descriptions land in the model’s context. A bad or badly written server can leak data or push the model into unwanted actions, for example through hidden instructions in a description or in returned content. So treat servers like dependencies in a project: pick ones with a clear author and open code, grant minimal permissions, keep secrets out of the repository and read the consents the application shows before a tool runs. I develop this theme in the AI code security hub and in the glossary entry on MCP.
It also helps to decide who in the team owns the list of connected servers. Without an owner the list grows on its own, and after half a year nobody remembers what each server is for or which tokens it was given. Review it now and then and remove what is unused: fewer servers mean less risk and a cleaner model context. Tie that review to updates: servers change, and a new version may add tools nobody asked for.
Where to look for servers? The official modelcontextprotocol/servers repository contains reference examples, and the MCP registry collects servers published by the community. Being listed in a registry is not a security certificate, so you have to do the assessment yourself.
Last checked: 20 October 2026. The protocol has versions, and the documentation points to the current one; check it when building your own server.