If you have been around AI dev Twitter in the last year, you have heard the letters MCP roughly four thousand times. People drop it into sentences like everyone already knows what it means, and you nod along while quietly Googling it under the table. I have been there. So here is the friendly version I wish someone had handed me before I went digging through the spec.
MCP is the boring infrastructure that makes AI assistants actually useful inside real systems. That is the whole pitch. It is not a model, it is not a framework, it is not a new way to do prompts. It is the wiring.
The one-paragraph definition
The Model Context Protocol is a small JSON-RPC protocol where servers expose tools, resources, and prompts that an LLM client can call. A client (Claude Desktop, an IDE, your custom agent) connects to one or more MCP servers, asks them what they offer, and then lets the model use those capabilities during a conversation. That is it. The whole thing fits in your head in about an afternoon.
What MCP is not
This part trips people up, so let us clear it up first.
- It is not a vector store. MCP does not embed anything or do retrieval on its own. You can build a server that wraps a vector store, but the protocol itself has zero opinions about embeddings.
- It is not a chat protocol. The conversation between user and model still happens wherever it always happened. MCP only describes how the model reaches out to external capabilities.
- It is not OpenAI-style function calling. Close cousin though. Function calling is a per-request convention baked into one provider. MCP is a standalone protocol that any client and any server can speak, with discovery, lifecycle, and transport baked in.
The three primitives
Everything in MCP boils down to three things a server can offer.
Tools. Things the agent can call. A tool has a name, a JSON schema for its arguments, and a description. The model picks one, fills in the args, the server runs it, and returns a result. Think send_email, create_issue, query_database.
Resources. Things the agent can read. A resource has a URI and some content behind it. The model can list resources or fetch a specific one. Think files, log entries, rows from a table, the current weather. Read-only by design.
Prompts. Templates the agent loads. A prompt is a named, parameterised message template the server provides, so the client can offer it as a slash command or a shortcut. Useful for things like summarise_pr or draft_release_notes where you want a consistent starting point.
That is the whole vocabulary. Tools, resources, prompts. Once you see those three buckets, every MCP server you meet stops feeling magical.
Two examples in prose
Picture an MCP server that wraps your Postgres database. It exposes a handful of tools: list_tables, describe_table, run_query. The model can now answer questions like "how many orders shipped last week" by actually asking your database, instead of guessing from training data that may or may not know your schema exists.
Now picture another one that wraps your local git repo. It exposes resources for every file in the working tree and tools for things like git_log or git_diff. Suddenly Claude can read your repo the way you would, scroll through history, and quote real code back at you instead of hallucinating import paths.
Same protocol, completely different capabilities, no custom integration on the client side.
Transports
MCP supports a few ways for client and server to talk.
- stdio for local servers. The client spawns the server as a subprocess and they exchange JSON-RPC over standard in and standard out. Great for tools that run on your machine.
- HTTP plus SSE for remote servers. The original remote transport, server-sent events for the streaming side.
- Streamable HTTP, the newer transport that landed in 2025 and is now the recommended option for remote servers. Single HTTP endpoint, cleaner semantics, easier to deploy behind a normal load balancer.
For most people writing their first MCP server, stdio is the easiest way to get going. You ship a binary or a Node script, point your client at it, and you are done.
The typical install day
Adding an MCP server to a client usually looks the same everywhere. Clone or install the server, add a small block to your config file (Claude Desktop uses claude_desktop_config.json, IDEs have their own equivalents) with the command and any environment variables, restart the client, and the new tools just show up in your session. No model retraining, no plugin store, no approval process. If the server speaks the protocol, the client can use it.
Why any of this matters
Before MCP, every assistant had its own bespoke way of plugging into external systems. You wrote a custom integration for each one and prayed nothing changed. MCP is the boring layer that makes those integrations portable. Write one server, use it from Claude, from your IDE, from whatever new agent framework lands next month.
That is the quiet superpower here. MCP is what turns Claude from "chat with a really good dictionary" into "I can read your repo, query your database, and run your tools". Same model, completely different job.
If you have been putting off learning it because the name sounds like enterprise middleware, do not. It is genuinely small, genuinely useful, and an afternoon with the spec plus one toy server will take you most of the way there.