The Model Context Protocol (MCP) is an open standard that defines how AI applications connect to external tools and data sources. Anthropic introduced it in November 2024, and it has since been adopted across AI assistants, coding tools, and agent frameworks.
The problem MCP solves
A language model on its own can only produce text. To be useful in real work it needs to read files, query databases, search, and call APIs. Before MCP, every AI application defined its own way to plug those in, so a tool built for one assistant had to be rebuilt for the next.
MCP replaces that with one protocol. A tool provider writes an MCP server once, and any MCP-compatible application can use it. The common comparison is a universal connector: one standard plug instead of a different cable for every device.
How MCP works
MCP has three roles.
- Host: the AI application the person uses, such as a chat app, an IDE, or an agent.
- Client: a component inside the host that maintains the connection to one server.
- Server: a program that exposes capabilities to the host.
Host application (assistant, IDE, agent)
| one MCP client per server
v
MCP server ---> files, databases, APIs, or pure computation
Messages are JSON-RPC 2.0. When a connection opens, client and server exchange their capabilities, and the client asks the server what it offers. The host passes those tool definitions to the model. When the model decides to use a tool, the client sends the call to the server and returns the result.
The building blocks
Servers can offer three kinds of capability.
| Primitive | What it is | Who decides to use it |
|---|---|---|
| Tools | Functions the model can call, with a name, description, and input schema | The model |
| Resources | Read-only data identified by a URI, such as a file or a record | The application or the user |
| Prompts | Reusable prompt templates the server provides | The user |
Tools are the most widely used. A tool definition looks like this:
{
"name": "estimate_tokens",
"description": "Count the tokens in a prompt for a given model.",
"inputSchema": {
"type": "object",
"properties": {
"prompt": { "type": "string" },
"model": { "type": "string" }
},
"required": ["prompt"]
}
}
The description and schema are read by the model, so they are prompts in their own right. Clear tool descriptions are the largest factor in whether an agent uses a tool correctly. See prompts for AI agents.
Transports
MCP defines how messages travel.
- stdio: the host starts the server as a local process and communicates over standard input and output. Simple, and nothing is exposed on the network.
- Streamable HTTP: the server runs as a web service that clients reach over HTTP, which suits remote and shared servers and brings authentication into scope.
MCP, function calling, and APIs
These are layers, not competitors.
- An API is how software talks to a service.
- Function calling is how a model asks for a function to be run.
- MCP standardizes how functions are described, discovered, and delivered to any AI application.
An MCP server often wraps an existing API. If you only ever serve one application you control, plain function calling is enough. MCP earns its place when you want a tool to work across many clients.
Configuring a server
Hosts are configured with a list of servers to start. A local stdio server needs a command and its arguments:
{
"mcpServers": {
"promptflow": {
"command": "node",
"args": ["/absolute/path/to/packages/mcp-server/dist/bin.js"]
}
}
}
The key names vary a little between hosts, but the shape is the same.
Security considerations
Connecting a model to tools is powerful, and it widens the attack surface.
Tool results are untrusted input. A server that fetches web pages or reads tickets returns text an attacker may have written. The model may follow instructions in it. See prompt injection.
Tool descriptions are trusted by the model. A malicious server can describe a tool misleadingly to steer the model. Install servers only from sources you trust, and review what they declare.
Combined capabilities multiply risk. A session that can read private data, read untrusted content, and send data out can be turned into an exfiltration path. Avoid giving one session all three.
Least privilege applies. Prefer servers that do one thing, use read-only access where possible, and require confirmation for actions with side effects.
Local servers run with your permissions. A stdio server is a program on your machine. Treat installing one like installing any other software.
Designing a good MCP server
- Offer a small number of well-named tools with distinct purposes.
- Write descriptions that say when to use a tool and what it returns.
- Validate every argument and return errors the model can act on.
- Keep results compact, because they consume the model’s context.
- Mark tools that only read as read-only, so hosts can treat them accordingly.
- Never return secrets in results or logs.
An example: prompt tools over MCP
The PromptFlowEngine MCP server is a small illustration of these principles. It exposes the prompt engine as tools for analyzing, restructuring, optimizing, comparing, and sanitizing prompts, plus the rule and model catalogues as resources. It uses the stdio transport, makes no network calls, and has no file or shell access, so every tool is read-only: it can only process the text it is given.
With it connected, an agent can check its own work:
Use promptflow to restructure this before you start:
"fix login issue and make google login work and don't break anything"
The agent calls the restructure tool and gets back a sectioned specification with requirements, edge cases, and acceptance criteria, which it then implements. Setup is covered in the MCP client documentation.
Where MCP fits
MCP is the connection layer of an agent system. The reasoning loop that decides when to call a tool is covered in ReAct prompting, and the instructions that govern it in prompts for AI agents.