Model Context Protocol (MCP) explained: servers, clients and when to use it
The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in November 2024, for connecting AI applications to tools and data sources. Instead of writing a custom integration for every tool in every application, a service is wrapped once as an MCP server, and any MCP-compatible application, like Claude, ChatGPT, Cursor, VS Code or your own agent, can connect to it as a client. It is a standard way to package and share tools, not a new capability for the model, and connecting an agent to third-party servers brings real security risks, so treat every server as code you are trusting.
What problem MCP solves
Before MCP, every AI application connected to tools in its own way. If you wanted your agent to use GitHub, Slack, a database and your file system, you wrote four custom integrations, in that application's format. Another application that wanted the same tools wrote its own four. Every provider's function calling format was a little different, and when an external API changed, every integration had to change.
That is a classic many-to-many problem: M applications times N tools means M × N integrations.
MCP turns it into M + N. Each tool is wrapped once as an MCP server, each application implements the MCP client once, and any client can use any server. It is often compared to USB-C: one standard connector instead of a different cable for every device.
Parts of MCP
- Host: the AI application the user interacts with, like Claude Desktop, an IDE or your own agent.
- Client: the component inside the host that connects to one MCP server and speaks the protocol.
- Server: a program that exposes tools, data or prompts through MCP, like a GitHub server, a Postgres server or your company's internal API wrapped as a server.
A host can connect to many servers at once, each through its own client.
What servers can offer
MCP servers expose three main kinds of things:
- Tools: functions the model can call, with names, descriptions and input schemas, exactly like function calling. "create_issue", "query_database", "send_message".
- Resources: data the application can read and put into context, like files, database records or documents, identified by URIs.
- Prompts: reusable prompt templates the server provides, which users can choose, like "summarise this pull request".
The protocol also supports features where the server asks the client for something, like asking the user for input during a task.
How it connects
Servers can run in two main ways:
- Locally, as a process the host starts on the same machine, communicating through standard input and output. Common for tools that work with local files or developer tools.
- Remotely, as a web service the client connects to over HTTP, with authentication. Common for hosted services like SaaS products.
When a host connects to a server, it asks what tools, resources and prompts the server offers, and passes the tool definitions to the model. When the model calls a tool, the client sends the call to the server, the server runs it, and the result comes back to the model, the same loop as function calling with a standard protocol in between.
A small MCP server
The official Python SDK makes a basic server short.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("orders")
@mcp.tool()
def get_order_status(order_id: str) -> dict:
"""Get the status and expected delivery date of an order. order_id looks like ORD-123456."""
return {"order_id": order_id, "status": "shipped", "expected_delivery": "2026-10-18"}
if __name__ == "__main__":
mcp.run()
The function's name, type hints and docstring become the tool definition the model sees, so the tool design advice applies here exactly. Any MCP-compatible host can now connect to this server and use the tool.
MCP and function calling
MCP doesn't replace function calling. The model still sees tool definitions and produces tool calls the way the function calling page describes. MCP standardises how those tools are packaged, discovered and connected, so they can be reused across applications.
| Function calling | MCP | |
|---|---|---|
| What it is | How a model requests a tool call | A protocol for connecting applications to tool servers |
| Where tools live | In your application's code | In separate servers |
| Reuse across applications | Rewrite per application | Write once, connect anywhere |
| Best for | A few tools specific to one app | Shared tools, many apps, third-party integrations |
When to use MCP
Use MCP when:
- You want your tools available in several AI applications, like your own agent, Claude and your team's IDE.
- You want to use existing servers for common services instead of writing integrations.
- You are building a product that other people's agents should be able to use.
You don't need it when your agent has a few tools that only it uses. Plain function calling in your code is simpler, faster to debug and has fewer moving parts.
Security
MCP makes it very easy to give an agent new capabilities, and that is exactly why it needs care.
- A server is code you run or trust. A malicious or compromised server can return harmful data, misuse credentials or expose your files.
- Tool descriptions and results go into the model's context, so a server can carry prompt injection: hidden instructions in a description or result that try to make the agent do something else.
- Servers often hold credentials, like API tokens for GitHub or your database, so scope those credentials to the minimum.
- Combining servers can be risky: an agent with access to private data and the ability to send messages externally can be manipulated into leaking that data.
Practical rules:
- Use servers from sources you trust, and review the code of community servers before running them.
- Pin versions, and review changes before updating.
- Give each server only the permissions and data it needs.
- Require approval for tools that write, send or delete.
- Log every tool call.
Agent to agent protocols
MCP connects agents to tools and data. A separate protocol, Agent2Agent (A2A), announced by Google in April 2025, is designed for agents to communicate with other agents, like one company's purchasing agent talking to a supplier's sales agent. They solve different problems and can be used together.
From the floor
In a cohort session, a builder explained why MCP matters in their work: without it, connecting to Snowflake, Oracle or another external system means writing a proprietary connector, and when that system's API changes, your code has to change too. With MCP, the vendor provides the MCP server and you connect to it as a client, so changes on their side don't break your integration. That decoupling is the reason MCP was designed as a standard protocol in the first place.
Another builder showed that installing several MCP servers, for GitHub and Playwright, was taking too long every time they set up a new development environment, so they wrote a single command to install them all, because MCP servers had become part of their everyday development setup.