Model Context Protocol (MCP)

An LLM on its own is a brain in a jar — it can reason, but it can’t read your files, query your database, or call your APIs. Model Context Protocol (MCP), introduced by Anthropic in late 2024 and since adopted across the industry, is the open standard that connects that brain to the outside world. If you’ve heard it called “the USB-C port for AI applications,” that’s exactly the idea: one standard plug, so any agent can talk to any tool without custom glue for every pair.

The problem it solves

Before MCP, every AI app that wanted to use, say, GitHub, Slack, and Postgres had to write and maintain a bespoke integration for each — the classic M×N problem: $M$ apps times $N$ tools equals a combinatorial mess of one-off connectors.

MCP turns that into an M+N problem. Tool authors write one MCP server; app authors write one MCP client. Any client can then talk to any server.

The architecture

Three roles, built on JSON-RPC 2.0 messages:

Role	What it is
Host	The AI application the user interacts with (Claude Desktop, an IDE, your agent)
Client	Lives inside the host; maintains a 1:1 connection to one server
Server	A separate program exposing capabilities over the protocol

Communication happens over a transport:

• stdio — the server runs as a local subprocess; messages flow over stdin/stdout. Best for local tools (filesystem, git).
• Streamable HTTP — the server is a remote web service. Best for hosted, multi-user, or SaaS integrations.

What a server exposes

An MCP server can offer three kinds of capability — and knowing the difference is the key to using MCP well:

Primitive	Controlled by	Analogy	Example
Tools	The model decides when to call	A function the agent can invoke	create_issue(title, body)
Resources	The application attaches as context	A file/record the app reads	A document, a table row, a log
Prompts	The user invokes deliberately	A saved template/slash-command	”Summarize this PR”

Tools are the ones people mean most of the time — model-callable functions with a JSON schema for their arguments, exactly like function calling, but discovered dynamically at connect time rather than hard-coded.

A tiny server (TypeScript)

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "weather", version: "1.0.0" });

server.tool(
  "get_forecast",
  { city: z.string() },                       // argument schema
  async ({ city }) => {
    const data = await fetch(`https://api.example.com/wx?q=${city}`).then(r => r.json());
    return { content: [{ type: "text", text: `${city}: ${data.summary}, ${data.tempC}°C` }] };
  }
);

// Expose over stdio so a local host can spawn it
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
await server.connect(new StdioServerTransport());

Point any MCP host at this process and the agent can now call get_forecast mid-conversation — no changes to the model, just a new plug in the port.

Why it caught on

• Write once, use everywhere. A server you build works in Claude, in IDEs, and in any other MCP host — the integration outlives any single app.
• Dynamic discovery. Hosts learn a server’s tools at runtime, so agents gain abilities without redeployment.
• Broad adoption. What began at Anthropic became a de-facto cross-vendor standard through 2025, with major AI platforms shipping MCP support — which is what makes building a server worth the effort.

Pitfalls & good practice

• Security is real. A server can run code and touch data. Only connect servers you trust; treat tool descriptions and results as untrusted input (a malicious server could try prompt injection through them).
• Don’t over-expose. Fifty tools bloat the context and confuse the model. Expose a focused set; split unrelated capabilities into separate servers.
• Write descriptions for the model, not humans. The description of each tool is how the agent decides when to use it — precise, action-oriented descriptions dramatically improve tool selection.

Where it fits

MCP is the plumbing that gives an agent its tools. How the agent decides to use them is the agentic loop; connecting an agent to a knowledge base is often done with RAG, which itself is frequently delivered as an MCP server.