MCP: A Common Protocol for Connecting LLMs to Tools

Every LLM app that wants to read a file, query a database, or call an API needs some way to describe that capability to the model and route the model's requests back to the right system. Before MCP, every vendor built that wiring differently. MCP is Anthropic's attempt at a shared standard for it.

The problem it solves

N×M integrations — Without a standard, connecting M different LLM apps to N different tools means building M×N custom integrations. Each app writes its own connector for Slack, its own connector for GitHub, its own connector for a Postgres database.

No portability — A tool integration built for one LLM app usually can't be reused in another. The tool description format, the auth handling, the request/response shape — all of it is bespoke.

Context fragmentation — Tools built ad hoc for a single app tend to be shallow: enough to answer one demo query, not enough to be a real interface to the underlying system.

What MCP is

MCP defines a client-server protocol for exposing data and functionality to LLM applications, built on JSON-RPC.

MCP servers — A server exposes one or more capabilities: tools (functions the model can call), resources (data the model can read, like files or database records), and prompts (reusable prompt templates). A server might wrap a single system — GitHub, Google Drive, a local filesystem — or several related ones.

MCP clients — The LLM application (Claude Desktop, an IDE, a custom agent) runs an MCP client that connects to one or more servers, discovers what they expose, and routes model requests to the right server.

Transport — Servers can run locally over stdio, which is common for filesystem or local-tool access, or remotely over HTTP with server-sent events, which is common for hosted services like a company's internal API.

The three primitives

Tools — Functions with a name, a description, and a JSON schema for inputs. The model decides when to call one based on the conversation; the client executes it and returns the result.

Resources — Structured or unstructured data the client can fetch and inject into context — a file's contents, a database row, a page from a wiki. Unlike tools, resources are typically read, not invoked with arguments.

Prompts — Predefined prompt templates a server can offer, often parameterized, so a client doesn't have to hardcode common workflows.

Why build a server instead of a custom integration

Building against MCP instead of a proprietary plugin API means the same server works across every MCP-compatible client without rewriting it. Anthropic ships MCP support in Claude Desktop and the API; other vendors have added client support since. A team maintaining a GitHub integration built as an MCP server gets Claude Desktop, IDE plugins, and custom agents as consumers, without three separate integration codebases.

There's a real ecosystem argument here too: a growing catalog of community and vendor-built servers (Slack, Postgres, Google Drive, Sentry, and others) means many integrations don't need to be built at all.

Tradeoffs

MCP is young, and that shows up in a few places.

• Server quality varies a lot — some are thin wrappers with poor error handling, others are well-built
• Security models differ by transport: a local stdio server runs with the permissions of whatever launched it, which is a different trust boundary than a hosted HTTP server behind auth
• Discovery and versioning across many servers is still mostly manual; there's no centralized registry with strong guarantees yet
• Not every LLM vendor supports it, so it's not yet a universal standard the way HTTP is

None of that erases the core value: MCP moves tool integration from "build it per app" to "build it once, connect it everywhere that speaks the protocol." Whether it becomes the actual industry standard depends on adoption outside Anthropic's own ecosystem, which is still playing out.

If you're deciding whether to build a custom tool integration or an MCP server, the MCP server is almost always the better long-term bet — the marginal cost over a custom integration is small, and the reuse is large.