Introagents toolinglanguage modelsgenerative ai

Introducing the Model Context Protocol (MCP)

One universal way to plug AI into the outside world

A language model on its own is a brain in a box: brilliant at talking, but it can't see your files, query your database, or press any buttons in the real world. To fix that, people used to hand-build a custom connector for every pairing of AI-app-and-tool — a combinatorial mess that never scaled. The Model Context Protocol (MCP), open-sourced by Anthropic in November 2024, replaces all those one-off bridges with a single open standard. The official analogy: MCP is “a USB-C port for AI applications.” Just as USB-C is one socket that any device can plug into, MCP is one standard so any compliant AI app can plug into any compliant tool or data source — build it once, and it works everywhere. Under the hood it's refreshingly simple: small programs called MCP servers expose three things — Tools (actions the AI can do), Resources (data it can read), and Prompts (templates the user can pick) — and AI apps (the hosts) talk to them by trading little JSON-RPC messages. This paper walks a total beginner all the way from “why does this exist?” to writing a working MCP server in Python or TypeScript, watching a real tool call travel end-to-end, and poking a live JSON-RPC console — then hands you an “MCP Certified” badge.

24 min readOpen standard · modelcontextprotocol.io, 2024Original paper

Anthropic

Read it your way — plain-language or full technical depth.

N×M → N+M

Integrations: before → after

Hand-wiring every AI app to every tool explodes as N×M. MCP makes each side implement one standard → N+M.

3

Server primitives

Tools (model-controlled actions), Resources (app-controlled data), Prompts (user-controlled templates).

3

Client primitives

Sampling, Elicitation, and Logging — the ways a server can call back to the client (Roots is a related capability).

2

Standard transports

stdio (local subprocess) and Streamable HTTP (remote) — same JSON-RPC either way.

JSON-RPC 2.0

Wire format

Every message is a JSON-RPC request, result, error, or notification.

Nov 2024

Open-sourced

Created and open-sourced by Anthropic on Nov 25, 2024; now a broadly adopted open standard.

10+

Official SDKs

TypeScript, Python, Java, Kotlin, C#/.NET, Go, PHP, Ruby, Rust, Swift.

2025-11-25

Current spec version

MCP is versioned by date; the version is negotiated during the initialize handshake.

Start here

What MCP is, in one breath

MCP (the Model Context Protocol) is an open standard that gives any AI app one universal way to plug into the outside world. Instead of a chatbot being a brain trapped in a box that can only talk, MCP lets it read your stuff (files, databases, docs), use tools (search, APIs, calculators), and follow workflows (ready-made prompt templates).

And under all the jargon, it's astonishingly simple: AI apps and tools just trade small blobs of JSON. Here's a real MCP message — poke at it.

An MCP message, x-rayed

Under all the jargon, an MCP message is just this — a small blob of JSON. Tap or hover any underlined field to see what it means.

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "New York" }
  }
}

This one says: “call the tool named get_weather with the argument location: New York.” That's the whole idea — AI apps and tools trade little JSON messages like this. Everything else in this paper is just which messages, and when.

Tap or hover the underlined fields. This one asks a server to run the get_weather tool for New York. That's the whole idea — the rest of this paper is just which messages, and when.

The problem

Every AI wired to every tool, by hand

A brilliant model is useless if it can't see your calendar, your codebase, or your company database — Anthropic described the old world as models “trapped behind information silos.”

The scaling pain was brutal. Say you have N AI apps and M tools. Connecting them the old way meant building a separate, custom bridge for every pair — roughly N × M brittle integrations, each with its own auth, data format, and quirks. Add one new tool and you rebuild it for every app. Nothing compounded.

MCP collapses that explosion into N + M: each AI app implements MCP once, each tool exposes an MCP server once, and they all interoperate. Drag the sliders below to feel the difference.

N×M vs N+M — drag the sliders

AIAIAI

Before: N × M

3 × 4 = 12

custom integrations

With MCP: N + M

3 + 4 = 7

MCP implementations

Every AI app wired by hand to every tool explodes as N × M. MCP adds one standard hub, so each app and each tool implements MCP once — N + M. “Build once, integrate everywhere.”

“N×M” is our shorthand for the spec's “every new data source requires its own custom implementation.” Toggle Before/With MCP and watch the wire count collapse through one standard hub.

The analogy

MCP is a USB-C port for AI apps

The official flagship analogy, straight from the docs: “Think of MCP like a USB-C port for AI applications.” Before USB-C, every device had its own charger and a drawer full of adapters. One standard port replaced all of them.

MCP does the same for AI-to-tool connections. Once every tool and every AI “speaks MCP,” any AI can talk to any tool — no custom translator in between. It's a common language (a lingua franca), a universal adapter, a wall-outlet standard. The tagline: build once, integrate everywhere.

Think of it like…

A wall outlet. Appliance makers and outlet makers never coordinate one-on-one — they both build to the one plug standard, and everything just works. MCP is that standard plug, for AI and tools.

The anatomy

Host, Client, and Server

MCP has exactly three roles:

  • Host — the AI app you actually use (Claude Desktop, an AI IDE, a chatbot). It runs the show: holds the conversation, decides what to connect to, asks you for consent, and creates one client per server.
  • Client — a connector inside the host. Each client keeps a private, stateful 1:1 link to exactly one server.
  • Server — an independent, swappable program that exposes tools, data, and prompts. It can run locally or remotely.

The golden rule: one host runs many clients, and each client talks to exactly one server. Servers are walled off — a server can't read your whole conversation or peek at other servers. Explore it:

The host / client / server map

Host (the AI app)

Client 1
1:1
Files serverresources
Client 2
1:1
GitHub servertools
Client 3
1:1
Weather servertools

Host

The AI app you actually use (Claude Desktop, an AI IDE, a chatbot). It runs the whole show: it holds the conversation, decides what to connect to, asks you for consent, and creates one client per server. The full chat history stays here — servers never see it.

The golden rule: one host runs many clients, and each client talks to exactly one server(1:1). Servers stay isolated — they can't read the whole conversation or peek at each other.

Tap each role to see what it does. Notice the strict 1:1 client↔server links and the isolation between servers — that separation is a core safety property.

How they talk

JSON-RPC 2.0 and the handshake

Every MCP message is JSON-RPC 2.0 — a tiny, well-known format with just four message shapes: a request (has an id and a method), a result (the reply, same id), an error (a code + message), and a notification (a one-way message with no id and no reply). MCP adds two rules: the id may never be null, and it can't be reused within a session.

When a client and server first connect, they run a short handshake: the client sends initialize (which version it speaks + its capabilities), the server replies with the version it agrees on and its capabilities, and the client sends an initialized notification to say “ready.” Only then does real work begin. There's no “shutdown” message — closing happens at the transport layer. Step through the whole sequence:

The lifecycle, message by message

Client (host)Server
→initialize
1/7requestinitialize

The client opens the conversation. It says which MCP version it speaks, what features it supports (its capabilities), and who it is. It won't send anything else until the server replies.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {},
      "elicitation": {}
    },
    "clientInfo": { "name": "ExampleClient", "version": "1.0.0" }
  }
}

Notice the id pairs a reply to its request (1↔1, 2↔2, 3↔3), the middle message is a notification(no id, no reply), and there's no “shutdown” message — closing happens at the transport layer.

Walk initialize → result → initialized → tools/list → tools/call and back, with the REAL spec JSON at each step. Watch how the id pairs each reply to its request.

For the curious — capability negotiation

During initialize, each side declares which optional features it supports (tools, resources, prompts, logging, sampling, elicitation, roots…). Those declarations are binding for the whole session — a side may only use a feature that was successfully negotiated. That's how MCP stays extensible: new capabilities can be added without breaking old clients.

The building blocks (server side)

The three server primitives — and who's in control

A server can expose three kinds of things, and the key to understanding them is asking “who's in the driver's seat?”

  • Tools are model-controlled — actions the AI decides to call to DO something (tools/list to discover, tools/call to run).
  • Resources are application-controlled — data the app pulls in for context, addressed by a URI (resources/list, resources/read).
  • Prompts are user-controlled — reusable templates the user picks, often as slash commands (prompts/list, prompts/get).

Tab through them with the real request/response JSON for each:

Tools · Resources · Prompts

Tools model-controlled

Actions the AI can DO — query a database, call an API, run code. Each has a name, a description the model reads, and an input schema.

The buttons and levers on a control panel — the model presses them.

discover: tools/listuse: tools/call
Real spec messages

Request →

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "New York" }
  }
}

← Response

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Current weather in New York:\nTemperature: 72°F\nConditions: Partly cloudy"
      }
    ],
    "isError": false
  }
}

The whole mental model is “who's in the driver's seat.” Tools = the model decides, Resources = the app decides, Prompts = the user decides.

Each tab shows who controls it, an analogy, the discover/use methods, and the real spec JSON. The control model is the whole mental model.

The building blocks (client side)

The client can talk back too

MCP is two-way — a server can call back to the client. There are three client primitives:

  • Sampling — a server borrows the host's LLM (sampling/createMessage) to add an AI step, without holding any API keys of its own. You approve the call.
  • Elicitation — a server asks you for a bit of structured input mid-task (elicitation/create); the client renders a form. Never for sensitive data.
  • Logging — a server sends structured log messages up to the client.

There's also Roots — a related capability (not one of the three primitives) where the client tells a server which folders it may work in (roots/list). At every callback, a human or the app stays in the loop. Try them:

Sampling · Elicitation · Logging · Roots

Samplinglets a server borrow the host's LLM (sampling/createMessage) — so the server needs no API keys of its own, and you approve the call.

⚠ Server wants to ask the LLM: “What is the capital of France?”

MCP is two-way: servers can call back to the client. The three client primitives are Sampling, Elicitation, and Logging; Roots is a related capability. A human or the app stays in the loop at every callback.

Approve a sampling request, fill an elicitation form, watch server logs stream in, and test a roots boundary. Notice you're always in control.

The pipe

stdio vs Streamable HTTP

The transport is just the pipe the JSON-RPC messages flow through — the messages are identical either way. There are two standard ones:

  • stdio — the host launches the server as a local subprocess and talks over stdin/stdout. Simplest, no network, credentials from the environment. Great for local tools (files, git, a local database).
  • Streamable HTTP — the server is remote, reached over one HTTP endpoint (POST, plus an optional SSE stream for server-initiated messages). Uses session + version headers, Origin checks, and OAuth for auth. Use it for hosted/cloud servers. (It replaced the older “HTTP+SSE” transport.)

Pick a pipe

Host
stdin / stdout
local subprocess
stdioStreamable HTTP
Where the server runsSame machine (subprocess)Remote / networked
The pipestdin / stdout (newline-delimited JSON)HTTP POST (+ optional SSE stream)
ServesOne hostMany clients concurrently
AuthFrom environment (no OAuth)OAuth 2.1, Origin checks
Best forLocal tools: files, git, DBsHosted / cloud servers

The transport is just the pipe — the JSON-RPC messages are identical either way. Streamable HTTP replaced the older “HTTP+SSE” transport.

Toggle stdio vs Streamable HTTP, send a message, and compare them point by point. Same protocol, different plumbing.

Hands on

Build your own MCP server (real code)

Here's the payoff for developers: a working MCP server is a handful of lines. Below is a real one that exposes a single add tool — in both Python (using FastMCP) and TypeScript (using the official SDK). This exact code was run during fact-checking: a client calling add(2, 3) gets 5, and the schema is generated for you from the types.

Toggle the language, step through it line by line, then hit Run (simulated) to watch it come alive over stdio.

Build-a-server playground

verified · runs today
server.py
1from mcp.server.fastmcp import FastMCP
2 
3# 1) Create the server. The name is how hosts label your connector.
4mcp = FastMCP("Demo")
5 
6# 2) Expose a tool. @mcp.tool() turns a type-hinted function into an
7#    MCP tool: the hints BECOME the input schema, the docstring the
8#    description the model reads to decide when to call it.
9@mcp.tool()
10def add(a: int, b: int) -> int:
11    """Add two numbers and return the sum."""
12    return a + b
13 
14# 3) Run over stdio. The host launches this process and talks JSON-RPC
15#    over stdin/stdout — so NEVER print() to stdout here.
16if __name__ == "__main__":
17    mcp.run(transport="stdio")

Newbie traps: never print()/console.log on a stdio server (it corrupts the channel — log to stderr); in TS use "type": "module" + .js imports and a raw zod shape (not z.object); use ABSOLUTE paths in the host config; and write a good tool description — the model picks tools from it. (SDK version numbers drift — check pypi.org / npm at build time.)

Python ⇄ TypeScript, revealed step by step, with a simulated stdio run. The code is verbatim and runs today.

Putting it together

Watch a tool call, end to end

So what actually happens when you ask an MCP-connected assistant “what's the weather in New York?” The surprising part: the model never fetches the weather itself. It reads the tools it discovered, decides to call get_weather, and emits a structured tool-call message with the arguments filled in. The client sends it to the server (after the host gets your consent), the server actually runs it, and the result flows back for the model to turn into a sentence. Trace it hop by hop:

Trace a request end to end

“What's the weather in New York?”
You
→
Host / LLM
→
Client
→
Server
→
Answer

The aha: the model never touches the outside world itself. It just emits a structured tool call; the client and server actually run it, and the model narrates the result. The “magic” is message-passing.

Pick a question and watch it travel User → Host/LLM → Client → Server → answer, with the real JSON at the call and result hops. The magic is just message-passing.

Safety

Security and trust: humans stay in control

MCP lets AI touch real systems and run real code, so trust is built into its principles:

  • User consent & control — you must explicitly consent to and understand all data access and actions; the host should show clear approval UIs.
  • Data privacy — hosts must get consent before exposing your data to a server, and must not send it elsewhere.
  • Tool safety — tools are arbitrary code execution. Tool descriptions are untrusted unless the server is trusted, and the host must get your explicit consent before invoking any tool.
  • LLM sampling controls — you approve any server-initiated sampling and control what the server can see.

Crucially, MCP can't enforce these at the protocol level — it's on implementors to build real consent and authorization flows. For remote (HTTP) servers the spec defines OAuth 2.1-based auth; local stdio servers rely on OS-level trust.

The one rule to remember

Nothing runs behind your back. A well-built MCP host asks for your explicit approval before a tool acts — treat any “auto-approve everything” setting, or a server you don't trust, with real caution.

The world of MCP

Who speaks MCP

MCP was created and open-sourced by Anthropic on November 25, 2024, launching with early adopters like Block, Apollo, Zed, Replit, Codeium, and Sourcegraph. It's now a broadly adopted open standard — supported across Claude and ChatGPT (OpenAI), and dev tools like VS Code, Cursor, and MCPJam.

There are official SDKs in 10+ languages (TypeScript, Python, Java, Kotlin, C#/.NET, Go, PHP, Ruby, Rust, Swift), a set of reference servers (Filesystem, Git, Fetch, Memory, Sequential Thinking, Time, and more), and the MCP Inspector for testing your own. Want to explore the protocol yourself? Here's a live JSON-RPC console — type a method and see the exact response.

Live JSON-RPC console

mcp-console — offline, spec-accurate
Type an MCP method and hit Enter. Try "tools/list", "tools/call get_weather", or "help".
›

Try a real method — or a fake one like does/not/exist to see the -32601 Method not found error. This is exactly the JSON an MCP client and server trade.

Type real methods — initialize, tools/list, tools/call get_weather — and get spec-accurate JSON. Try a fake method to see the -32601 error. Fully offline and deterministic.

You made it

The whole thing, in plain words

Let's recap the mental model:

  • AI models are brains in a box; MCP gives them a standard, safe way to reach the outside world.
  • It turns N×M custom integrations into N+M — a USB-C port for AI.
  • A host runs clients, each with a 1:1 link to a server; servers expose Tools (model), Resources (app), and Prompts (user).
  • They trade JSON-RPC 2.0 messages, starting with an initialize handshake.
  • It's two-way (sampling, elicitation, logging), travels over stdio or Streamable HTTP, and keeps a human in the loop.

That's genuinely most of MCP. Now earn your badge:

Get MCP Certified

Question 1 of 7score 0

What problem does MCP solve?

Seven questions, one per concept. Score 5+ to mint your “MCP Certified” badge — with a little celebration. It's saved on your device.

The lasting idea

Give a model hands, not just a mouth — through one open standard instead of a thousand custom wires. That's MCP. If the Transformer made models smart and RAG made them knowledgeable, MCP is how they finally reach the systems where real work happens.

Key takeaways

  • MCP is an open standard (from Anthropic, Nov 2024) that gives any AI app one universal way to connect to tools and data — “a USB-C port for AI applications.”
  • It turns the N×M explosion of custom integrations into N+M: each app and each tool implements MCP once.
  • Three roles: a Host runs Clients, and each Client has a strict 1:1 link to one Server; servers stay isolated from each other and the full conversation.
  • Everything is JSON-RPC 2.0, beginning with an initialize → initialized handshake that negotiates capabilities; there's no shutdown message.
  • Servers expose three primitives by who controls them — Tools (model), Resources (app), Prompts (user); clients offer Sampling, Elicitation, and Logging (with Roots as a capability).
  • Two transports (stdio for local, Streamable HTTP for remote) carry the same messages; a working server is only a handful of lines; and a human stays in the loop before any tool runs.

References

  1. Anthropic (2024). Introducing the Model Context Protocol. anthropic.com
  2. (2025). Model Context Protocol — Documentation & Specification. modelcontextprotocol.io
  3. (2025). MCP Specification (2025-11-25). modelcontextprotocol.io/specification
Share X LinkedIn

Keep exploring

IntermediateFeatured

Chain-of-Thought Prompting Elicits Reasoning in Large Language Models

Ask a big model to show its work — and it starts to reason

Big language models were surprisingly bad at multi-step problems — grade-school math, logic puzzles — often blurting a wrong final answer. This paper found a shockingly simple fix that requires no training at all: in the few examples you show the model (the “prompt”), don't just show it question-and-answer pairs — show it the *reasoning in between*. Write out the step-by-step thinking that leads to each answer. The model then imitates that pattern on new problems, producing its own “chain of thought” before answering — and accuracy leaps. The headline result: prompting a 540-billion-parameter model with just eight worked examples hit 56.9% on the GSM8K math benchmark — up from 17.9% with ordinary prompting — beating the previous best (a model specially fine-tuned for the task and paired with a separate verifier, at 55%). The twist: this only works in *large* models. In small ones, showing the steps does little or even hurts. Reasoning-by-prompting is an ability that *emerges* with scale — a discovery that reshaped how people use LLMs.

chain-of-thoughtpromptingreasoning
14 min4 interactiveExplore
IntroFeatured

QLoRA: Efficient Finetuning of Quantized LLMs

Fine-tune a 65-billion-parameter model on one gaming GPU

LoRA already made fine-tuning cheaper by training tiny add-on matrices instead of the whole model. But there was still a wall: you had to fit the giant frozen base model in GPU memory just to run it — and a 65-billion-parameter model needs over 780 GB, far beyond any single GPU. QLoRA smashes that wall by squashing the frozen base model down to 4 bits per number (instead of the usual 16), roughly a 4× shrink, so the whole thing fits in under 48 GB — a single high-end GPU. It does this without hurting quality, using three clever tricks: a new 4-bit number format (NF4) tuned to how weights are actually distributed, “double quantization” that even compresses the compression bookkeeping, and “paged optimizers” that spill memory to the CPU during brief spikes instead of crashing. The tiny LoRA add-ons still train in full precision on top. To prove it works, they fine-tuned a chatbot called Guanaco in 24 hours on one GPU — and it reached 99.3% of ChatGPT's score on a popular benchmark. QLoRA is why hobbyists and small labs can now fine-tune enormous models at home.

QLoRAquantization4-bit
15 min4 interactiveExplore
IntroFeatured

Retrieval-Augmented Generation for Large Language Models: A Survey

RAG — giving a language model an open book to read from

A language model only knows what it saw during training. So it can confidently make things up (“hallucinate”), it can't know anything recent, and it can't see your private documents. Retrieval-Augmented Generation (RAG) fixes this with a simple, powerful idea: before the model answers, go fetch relevant text from an external library and hand it to the model along with the question — like turning a closed-book exam into an open-book one. The basic recipe has three steps: (1) Indexing — chop your documents into chunks and store them so they're searchable by meaning; (2) Retrieval — when a question comes in, pull the few most relevant chunks; (3) Generation — feed those chunks plus the question to the model so its answer is grounded in real sources. This survey organizes the whole field into three generations of increasingly sophisticated RAG — Naive, Advanced, and Modular — and breaks every system into three parts: what you retrieve, how you use it, and how the model generates. RAG is now one of the most widely used techniques in real-world AI, because it makes answers more accurate, up-to-date, and traceable to a source.

RAGretrievalhallucination
15 min6 interactiveExplore
All papers