Also known as: Model Context Protocol, MCP server, MCP client
MCP is Anthropic's open standard for connecting LLMs to tools and data sources. An MCP server exposes a catalog of tools, resources, and prompts; any MCP-aware client can use them.
MCP — the Model Context Protocol — is an open standard introduced by Anthropic in late 2024 for connecting LLMs to the tools, data, and context they need. The core idea: instead of every LLM application reimplementing every tool integration from scratch, an MCP server exposes a tool catalog over a standard protocol, and any MCP client (a model harness, an IDE, an agent runtime) can use those tools without bespoke glue code.
Without a standard, integrating M LLM clients with N tools is M × N integration work. Every chat app reimplements GitHub, every coding agent reimplements Postgres, every research tool reimplements web search. MCP turns this into M + N: each client speaks MCP once, each tool ships an MCP server once, and they compose.
The point of MCP is not new capability. It’s that one tool integration now flows to every agent runtime instead of rotting separately in twenty.
An MCP server can expose three kinds of primitives:
Most MCP servers in the wild ship just tools, but the resource and prompt primitives matter for richer integrations.
An MCP-aware client (Claude Desktop, Cursor, an agent harness) connects to one or more MCP servers — typically over stdio for local processes or HTTP/SSE for remote ones — and dynamically loads their catalogs. The catalogs are translated into the underlying model’s function-calling format on the way in, and tool results flow back through the same standard.
The user experience is: install an MCP server, restart your client, and your agent can suddenly query your database, read your Notion, or interact with your custom internal API — without writing integration code.
Two reasons:
Every MCP tool’s name and description gets serialized into the model’s context as part of the function-calling schema. Install ten servers, each exposing fifteen tools, and you’ve burned 5-10K tokens of context on tool definitions before the user’s prompt is even read. Worse, the model now has to disambiguate between near-duplicate tools across servers (github_create_issue vs linear_create_issue vs gitlab_create_issue) and tool-selection accuracy drops measurably past ~30 tools in scope. The current production pattern: scope MCP servers per task with explicit allow-lists, or use a meta-tool that lazily loads server catalogs only when a sub-task touches that domain.
Function calling is the contract between one model and one runtime. MCP is the contract between one runtime and any tool provider — a separate process that exposes a tool catalog over a standard protocol. MCP solves the M-by-N problem: M clients × N tool integrations becomes M + N instead of M × N.
Three primitives: tools (functions the model can call), resources (data the model can read, like files or query results), and prompts (templates the user can invoke). A single server can expose all three; most ship just tools.
MCP was introduced by Anthropic but is an open spec — and the broader ecosystem (Cursor, Windsurf, OpenAI's Agents SDK, third-party clients) has adopted it. Any model that supports tool use can be wired to an MCP server with thin adapter code.
