If you've wired an LLM into a real application, you've felt the pain: the model is smart but blind. It doesn't know your database, your files, your ticketing system, or today's date unless you spoon-feed all of it into the prompt. So everyone built their own bespoke glue — a custom integration per tool, per app, per model. The result was a lot of code doing roughly the same job in mutually incompatible ways.
The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in late 2024, that tries to end the reinventing. The pitch is simple: define one protocol for how an AI application talks to external context and capabilities, so a connector you write once works across any client that speaks MCP. If you've heard it described as "USB-C for AI integrations," that's the idea — a common port instead of a drawer full of proprietary cables.
The mental model: clients and servers#
MCP borrows the client/server split that web developers already live in.
- An MCP server exposes some capability — access to a filesystem, a database, a GitHub repo, a search index, an internal API. It's a small program that knows how to do one category of thing.
- An MCP client lives inside an AI application (a chat app, an IDE assistant, an agent) and connects to one or more servers on the model's behalf.
- The host is the AI application itself, which manages those client connections and decides what to surface to the model.
The key win is the many-to-many decoupling. A server author doesn't need to know which AI app will use it; a client author doesn't need a custom integration per data source. Write a Postgres MCP server once, and every MCP-capable assistant can query databases through it.
What a server actually offers#
An MCP server can expose three kinds of things, and the distinction is worth getting right because it's the part people most often blur:
Tools are actions the model can invoke — functions with typed inputs, like create_issue, run_query, or send_email. Tools are model-controlled: the model decides when to call them, and they can have side effects. This is the piece that turns a chatbot into an agent.
Resources are data the model can read — a file, a row, a document, an API response. Resources are application-controlled context: they're loaded into the conversation as reference material rather than triggered as actions. Think "here is the file you asked about," not "go do something."
Prompts are reusable templates — parameterized message sequences a server can offer for common workflows, so a "summarize this PR" flow can be shared rather than re-typed.
Keeping these straight matters: a read that quietly mutates state should be a tool, not a resource, and a dangerous action dressed up as a resource is a security smell.
How they talk#
Under the hood, MCP uses JSON-RPC 2.0 for messages, so the wire format is boring and familiar. The connection runs over one of a couple of transports:
- stdio — the client launches the server as a subprocess and talks over standard input/output. This is the common case for local tools (your editor spawning a filesystem server).
- HTTP with streaming — for servers that run as a remote service, using HTTP with server-sent streaming for responses.
As a developer, you rarely hand-write JSON-RPC. Official SDKs (TypeScript and Python among them) give you a typed server where you register tools and resources with their schemas, and the protocol details are handled for you. Defining a tool looks roughly like declaring a function plus a schema for its arguments, and returning a result — much like writing an API route.
Why it matters if you build for the web#
Three reasons this is more than a curiosity:
- Reuse across clients. The connector you build isn't locked to one product. As more editors, chat apps, and agent frameworks adopt MCP, a single well-written server reaches all of them.
- A cleaner boundary. MCP pushes you to define capabilities with explicit schemas and clear read/action separation — the same discipline that makes a good HTTP API. That structure is good for humans, not just models.
- It's where the ecosystem is heading. Adoption moved quickly through 2025 across major AI tools. Understanding the protocol now is a lot like understanding REST early: it becomes a baseline expectation rather than a specialty.
The parts to be careful about#
MCP is plumbing, and plumbing that can take actions deserves respect. A few things to keep front of mind:
- Servers run with real permissions. A filesystem server can read files; a database server can run queries. Scope those permissions tightly and never expose more than a task needs.
- Tool calls are model-decided. For anything destructive or irreversible, keep a human in the loop with an explicit confirmation step rather than letting the model fire it autonomously.
- Treat server output as untrusted input. Content coming back from a tool can carry instructions aimed at manipulating the model. Don't blindly concatenate it into a privileged context.
None of this is a reason to avoid MCP — it's the same care any integration layer deserves once it can do more than read.
The takeaway#
MCP doesn't make models smarter. It makes them connected, through a standard connector instead of a hundred one-off adapters. If your work involves giving AI access to real data and real actions, it's worth an afternoon to build a small server and feel how the pieces fit — the mental model transfers directly to the AI features you'll be asked to ship.
FAQ#
What problem does the Model Context Protocol solve?#
Before MCP, every AI application built custom, incompatible integrations to connect a model to external data and tools. MCP standardizes that connection so a single server (say, for a database or a filesystem) works across any client that speaks the protocol, eliminating the per-app, per-tool glue code.
What's the difference between a tool and a resource in MCP?#
A tool is an action the model can invoke — a function with typed inputs that can have side effects, chosen by the model. A resource is data the model can read — a file or record loaded as reference context by the application. Reads that change state should be modeled as tools, not resources.
Is MCP tied to a specific model or company?#
No. MCP is an open standard introduced by Anthropic but designed to be model- and vendor-neutral. Any AI application can implement an MCP client, and servers are agnostic about which client connects to them.
Do I have to write JSON-RPC by hand to build an MCP server?#
No. MCP uses JSON-RPC 2.0 on the wire, but official SDKs (including TypeScript and Python) give you a typed interface where you register tools and resources with their schemas. You write something close to a normal function plus an argument schema, and the SDK handles the protocol.
References: