MCP (Model Context Protocol) is an open standard for connecting AI applications such as Claude Code to outside systems: a browser, an IDE, an issue tracker, a database, a docs service. A program called an MCP server wraps a system in a set of tools the model can call. Connect a server and the agent can read and act in that system directly, instead of working from what you paste into the chat.
Where it came from
Anthropic created MCP and open-sourced it in November 2024, framing it as one protocol to replace a separate custom integration for every data source. In December 2025 Anthropic donated it to the Agentic AI Foundation, a fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. That is why the same servers work outside Claude too: ChatGPT, VS Code and Cursor are MCP clients as well.
How it works
Three parts take part in every connection:
- Host: the AI application with the model, for example Claude Code.
- Client: one connection to one server. The host opens a separate client for each server it connects to.
- Server: the program that offers capabilities. A local server runs as a process on your machine and talks over standard input and output (stdio). A remote server runs elsewhere and talks over HTTP.
The messages between client and server are JSON-RPC 2.0, a simple request-and-response format in JSON.
A server can offer three kinds of things:
- Tools: functions the model can call to do something, such as run a query, call an API or fetch a page.
- Resources: data the application can pull into the context, such as a file, a database schema or an issue.
- Prompts: ready-made prompt templates the user can run.
What a tool looks like
Think of a server as a wrapper over an API, in a shape the model can use. The client asks the server for its tools (tools/list), and each tool comes back as a name, a plain-language description of what it does and when to use it, and a JSON Schema for its parameters. This is one tool from DeepWiki, a free remote server that answers questions about public GitHub repositories, as the server returns it (the output schema and metadata are left out):
{
"name": "read_wiki_structure",
"description": "Get a list of documentation topics for a GitHub repository.",
"inputSchema": {
"type": "object",
"properties": {
"repoName": {
"type": "string",
"description": "GitHub repository in owner/repo format (e.g. \"facebook/react\")."
}
},
"required": ["repoName"]
}
}The model sees only this. When your request matches a description, the model decides to call the tool and fills in the parameters. The host sends the call to the server (tools/call), the server does the real work against its API, database or files, and the result goes back into the conversation as a tool result. From there on it is part of the context window like anything else.
What it means for daily work
- The agent can do only what the tools allow. An MCP server is not the full API of a service and not everything you can click in its UI. If the server’s author did not write a tool for an action, the agent cannot do it through that server, even though the service supports it.
- A useful signal. If you keep copying data into the chat from another tool, such as a ticket from the tracker or a graph from monitoring, a server for that tool is worth connecting.
- Every server is trust and context. A server is code that runs with access to a system, and every tool result it returns takes room in the context. See MCP in Claude Code for connecting servers safely and MCP tool search for what they cost.
Related
- MCP in Claude Code: how to add, scope, allow and secure servers.
- MCP tool search: why connected servers barely cost context until they are used.
- Agentic loop: how tool calls fit into the agent’s work cycle.
- Context window: where tool results end up.