MCP (Model Context Protocol) is an open protocol that standardizes how large language model (LLM) applications connect to external tools, data sources, and services. Instead of building a custom integration for every model-and-tool pair, developers implement MCP once and any MCP-compatible host can use any MCP-compatible server. It defines a common message format for discovering capabilities, passing context, and invoking actions, so the "plumbing" between an LLM and the outside world becomes reusable rather than bespoke.
What Is the Model Context Protocol (MCP)?
MCP is a protocol in the same everyday sense as HTTP or USB: a written agreement about message shapes and behavior that lets independently built software interoperate. It was introduced by Anthropic as an open standard and has since been adopted by a range of LLM application developers and tool providers. The core idea is separation of concerns. On one side sits the host — the chat app, IDE plugin, or agent runtime where the model actually runs. On the other side sits a server that exposes capabilities: functions the model can call, resources (files, database rows, documents) it can read, and reusable prompt templates. The host and server never talk directly in the MCP architecture; a client component inside the host maintains a one-to-one connection to each server.
The protocol itself is built on JSON-RPC 2.0, a lightweight remote procedure call format where requests and responses are JSON objects with a method name, parameters, and an ID for matching replies. That choice matters practically: transports stay simple. MCP supports a stdio transport, where the client launches the server as a local subprocess and communicates over standard input/output, and an HTTP-based transport for remote servers. Because the wire format is just JSON-RPC, you can debug an MCP integration with ordinary logging tools rather than a specialized SDK.
What does a server actually expose? Three primitive types. Tools are callable functions with a name, a description, and a JSON Schema describing their arguments — the model reads that schema to decide when and how to call them. Resources are addressable, read-only data identified by URIs that the host can fetch and place into context. Prompts are parameterized templates a server offers so users or hosts can invoke a known-good instruction pattern. A host performs a capability handshake when it connects, so it knows exactly which of these a given server supports before anything is invoked. This is also why MCP is sometimes described as a "context protocol" rather than merely a tool protocol: it governs what enters the model's context window, not just what actions the model can trigger.
The standardization benefit compounds. A team that writes an MCP server for its internal ticketing system can use it from a desktop chat client, a coding assistant, and a custom agent without rewriting glue code. Likewise, a host that speaks MCP gains access to every server in the ecosystem. The protocol does not dictate how the model chooses tools or how the host renders results; those remain implementation decisions, which keeps MCP narrow and composable.
Why LLMs Need a Standard for Context and Tools
An LLM on its own is a text-in, text-out function. It has no memory of your files, no ability to query a database, and no way to take an action in the world. Everything useful beyond conversation comes from what the surrounding application injects into the prompt (context) and what it lets the model request (tools). Before a standard existed, each application invented its own conventions: one vendor's function-calling format, another's plugin manifest, a third's proprietary retrieval pipeline. The result was an N-times-M integration problem — every host needed custom code for every tool, and switching models meant rewriting the integration layer.
The costs of that fragmentation are concrete. Tool definitions and invocation formats differ across providers, so the same calendar integration might need three implementations. Security and permission logic gets reimplemented per integration, often inconsistently. Context assembly — deciding which documents, rows, or API responses to put in the prompt — is ad hoc, which makes behavior hard to reproduce and debug. And there is no shared vocabulary for capability discovery, so a host cannot ask a tool provider "what can you do?" in a machine-readable way; a human has to wire it up manually.
MCP addresses this by fixing the contract at the boundary between applications and capabilities. Tools describe themselves with schemas; resources are addressable by URI; the transport and message format are specified. A developer building a host implements the client once and gets compatibility with any conforming server. A developer building an integration implements a server once and reaches any conforming host. This is the same dynamic that made language server protocols and package registries valuable: the standard is boring, and that is the point.
There is a second, subtler need: context discipline. Models have finite context windows, and stuffing everything in is expensive and degrades quality. MCP gives hosts a structured way to discover what data exists and fetch only what is relevant, rather than pre-loading an undifferentiated blob. Combined with explicit tool schemas, this lets the application — not guesswork — control what the model sees and does, which is essential for reliability, auditing, and permissioning in real deployments.
How MCP Works: Hosts, Clients, and Servers
MCP splits every integration into three roles:
- Host: the application the user actually interacts with — an IDE, a chat app, a desktop assistant. The host decides which tools and data the model may see and enforces user consent.
- Client: a connector inside the host. The host creates one client per server, and each client keeps a single, stateful session with that server. Clients translate between the host's needs and the protocol's messages.
- Server: a small program that exposes capabilities. Three primitives matter most: tools (functions the model can call, like
query_database), resources (read-only data addressed by URI, like a file or a table), and prompts (reusable templates the user can invoke).
Communication happens over JSON-RPC 2.0 — a lightweight request/response format where every message names a method and carries typed parameters. The transport is usually standard input/output (stdio) for local servers the host launches as child processes, or HTTP with Server-Sent Events (SSE) for remote servers that push streamed responses. The protocol is bidirectional: servers can request sampling (an LLM completion) or user input from the host, rather than only answering.
The lifecycle is a capability handshake. On connect, client and server exchange initialize messages declaring what each supports (e.g., "I offer tools and resources," "I can handle sampling"). Both sides then use only negotiated features — which is why older clients don't break on newer servers.
Worked example: cost of tool definitions
Assume a server exposes 10 tools, each with a 150-token description and schema, and the system prompt adds 500 tokens. Tool overhead per request:
10 tools x 150 tokens = 1,500 tokens
1,500 + 500 system = 2,000 input tokens per turn
2,000 x 20 turns = 40,000 extra input tokens per conversation
At an assumed input price of $3 per million tokens, that's 40,000 / 1,000,000 x 3 = $0.12 per conversation — an estimate that scales linearly with tool count, so trimming or lazy-loading tool definitions is a real lever.
Practical Use Cases and Getting Started with MCP
Common patterns: an IDE host letting the model read repository files and run tests through a local server; a chat host querying a database via a read-only server; a support assistant pulling tickets from an internal API through a remote SSE server. Build servers when an integration should be reused across hosts; build hosts when you need a single UX over many servers.
Getting-started checklist:
- Pick one capability (e.g., "search our docs") and write a server exposing it as a single tool with a tight JSON schema.
- Start with stdio transport locally; log every request and response.
- Return errors as structured JSON-RPC errors, not stack traces; set timeouts and paginate large results.
- Validate all inputs server-side — the model will send malformed arguments eventually.
- Require explicit host-side confirmation for write or destructive tools.
- Test with a second host to confirm you haven't leaked host-specific assumptions.
- Measure tokens per turn before and after adding tools, using the formula above.
Frequently Asked Questions
What problem does MCP solve for LLM applications?
LLMs can only reason over what is placed in their context window, but every app was wiring up tools and data sources differently, so integrations were rebuilt for each model and each product. MCP (Model Context Protocol) standardizes that connection: a server exposes tools, data, and prompts through one protocol, and any compatible host can use them. This decouples integrations from specific LLM providers and reduces the custom glue code needed to give a model access to outside systems.
How is MCP different from function calling or plugins?
Function calling is a model-level capability: the model emits a structured request to call a function, and your application executes it. Plugins are typically a vendor-specific packaging of tools for one assistant ecosystem. MCP is a transport-and-discovery layer between an application (the host) and external capabilities (servers), and it can sit underneath function calling: the host fetches the server's tool list, presents those tools to the model, and routes the model's call requests over MCP. In short, function calling decides when to call something; MCP standardizes how that something is discovered and reached.
Do I need MCP if I only use one LLM provider?
Not strictly. With a single provider and a handful of integrations, direct function calling is simpler and has fewer moving parts. MCP pays off when you have several tools or data sources, when you want to reuse the same integrations across multiple apps or models, or when you want third parties to ship connectors you can adopt without custom code. Treat it as an interoperability layer you add when integration sprawl becomes the bottleneck.
What are MCP servers and what can they expose?
An MCP server is a process that speaks the protocol and advertises capabilities to a connected host. It typically exposes three primitives: tools (callable functions the model can invoke, such as a database query), resources (readable data identified by a URI, such as a file or record), and prompts (reusable templates the user or app can select). Servers can run locally over standard input/output or remotely over HTTP, and they handle the actual execution while the host mediates access and permissions.
How does MCP affect inference cost and latency?
MCP itself adds little compute; the cost comes from what it puts in the context. Tool definitions and resource contents consume tokens on every request they are included in, and multi-step tool use means extra model round-trips, so both token cost and latency grow with the number of tools exposed and calls made. Practical mitigations are exposing only relevant tools, summarizing or paginating large resources, and caching results. Expect overhead ranging from negligible for a few small tools to substantial for large tool catalogs, depending on your setup.