Problem
›
Overview
›
vs FC
›
vs REST
›
Architecture
›
Lifecycle
›
Primitives
›
Transport
›
Ecosystem
›
Use Cases
›
Quiz
• The Problem • ~12 min read
The N×M Integration Mess
Every AI system that needs to connect to external data must build a custom connector. N AI apps × M data sources = N×M bespoke integrations. No standards, no reuse, no ecosystem.
N×M
Custom integrations
Nov 2024
MCP released
Open
Source & standard
15k+
GitHub stars
The core problem: Even the most capable frontier models are limited by information silos. Connecting Claude to your Postgres database requires writing custom code. Connecting it to Slack requires different custom code. Connecting it to GitHub requires yet more custom code. There is no standard.
No Reuse
A Slack connector for Claude cannot be reused for ChatGPT. Every team rebuilds the same thing from scratch.
Security Gaps
Each custom integration has unique auth flows, permission models, and attack surfaces — multiplying audit burden.
Fragile Context
When an agent switches tools or data sources mid-task, it loses context. No standard for handing off state.
Why "Fragile Context"? — A Step-by-Step Demo
Imagine the agent is given this task: "Find customers inactive for 30 days, look up their Slack IDs, and send each a follow-up."
That needs 3 tools in sequence. The problem isn't whether the tools work — it's what happens to the data between them. Step through both worlds:
or click canvas to step
Press Play or Step to walk through the task. Watch what happens to the data at each handoff.
Why "No Reuse"? — A Concrete Example
The Slack API itself is the same for everyone. The problem is the glue code between the LLM and Slack.
Claude and ChatGPT speak completely different formats — so you write the connector twice. Pick an AI to see its format:
Claude (Anthropic SDK) — Tool definitions go inside the
tools array of the API request.
Claude responds with a tool_use content block. You extract input, call Slack, then pass the result back
as a tool_result in the next message. This format is unique to Anthropic — zero reuse with any other AI.
Why "Security Gaps"? — A Concrete Example
Three things multiply when you have N×M custom integrations: auth methods (how credentials are stored and rotated),
permission scope (what the AI is actually allowed to do), and
attack surfaces (places where something can go wrong).
Each custom connector handles all three differently. Click a scenario to explore:
Auth Chaos — Each integration invents its own credential strategy.
Slack needs a Bot Token + a Signing Secret stored in env vars.
GitHub needs a PAT or OAuth App with its own scope syntax.
Postgres needs a connection string with plaintext credentials.
Stripe needs an API key with its own rotation schedule.
Your security team must audit each one separately — four different patterns, four different failure modes.
Why didn't function calling solve this? ▼
Function calling (tool use) lets an LLM invoke a function — but who defines the function, how it authenticates, and where it runs is still custom per-integration. MCP standardizes the protocol around tools, not just the LLM's ability to call them.
What about LangChain / LlamaIndex connectors? ▼
Framework-specific connectors (LangChain tools, LlamaIndex loaders) are excellent — but they only work within that framework. A LangChain tool cannot be directly used by a Claude Desktop session or a VS Code Copilot agent. MCP aims to be model- and framework-agnostic.
• The Protocol
MCP: USB-C for AI
Model Context Protocol is an open standard that defines how AI applications connect to external data sources and tools. One protocol. Build once, integrate everywhere.
The USB-C analogy: USB-C provides a standardized physical and electrical interface so any device can connect to any peripheral. MCP provides a standardized software interface so any AI host can connect to any MCP server — regardless of which LLM powers the host or what system the server exposes.
For Developers
Build one MCP server for your database. It works with Claude, ChatGPT, VS Code Copilot, Cursor — any MCP host. No per-integration work.
For AI Applications
Access a growing ecosystem of pre-built MCP servers for Google Drive, Slack, GitHub, Postgres, and more — instantly, with no custom code.
For End Users
AI assistants that can actually access your data and take actions on your behalf — your calendar, your files, your databases, your workflows.
Open Standard
MCP is fully open-source (MIT). Anthropic created it but doesn't own it. Any company can implement it, extend it, or build tooling around it.
Who uses MCP today? ▼
Claude (Anthropic), ChatGPT (OpenAI), VS Code (Microsoft), Cursor, Zed, Replit, Codeium, Sourcegraph, Block, Apollo, and many more. The ecosystem grew rapidly after the Nov 2024 release.
Is MCP just for Claude? ▼
No. Anthropic created MCP, but it is deliberately model-agnostic and fully open. OpenAI, Microsoft, and many other companies have adopted it. The goal is universal adoption, not lock-in.
• Clarification • Most Common Question
MCP vs Function Calling — Not the Same Thing
Function calling lets an LLM decide to invoke a tool. MCP is the standard for how that tool is discovered, authenticated, and invoked — regardless of which LLM or host is driving. They operate at different layers.
Function Calling alone — The LLM can decide to use a tool, but everything around that decision is custom: how the tool is defined, where it runs, how it authenticates, how results come back. Each AI app re-implements all of this differently. Works for one app, zero reuse.
| Feature | Function Calling | MCP |
|---|
The key insight: Function calling is a capability of the LLM — the ability to decide "I should call this function." MCP is a protocol layer — the standard for how tools are discovered, how results flow back, how auth works, and how the same server works with any AI. You need both: the LLM's function calling to decide when to use a tool, and MCP to define how that tool works.
• Clarification • vs REST APIs
MCP vs REST APIs — Different Problems
REST APIs are designed for human developers to write integrations. MCP is designed for AI agents to discover and use tools autonomously. The difference isn't technical elegance — it's who does the integration work.
6
Steps via REST (human required)
3
Steps via MCP (fully autonomous)
1
Human in the loop (REST)
0
Humans needed (MCP)
REST flow — The AI encounters a task that needs weather data. It has no way to discover that OpenWeatherMap exists, what its endpoint is, or how to authenticate. A human developer must read the docs, write integration code, and wire it up. The AI only sees the result after all that manual work is done.
The core distinction: A REST API is a contract between two human developers — the provider writes docs, the consumer writes code. MCP is a contract between a server and an AI agent — the server declares its tools in machine-readable format with LLM-optimised descriptions, and the AI discovers and uses them without any human writing integration code.
| Feature | REST API | MCP |
|---|---|---|
| Discovery | Human reads docs manually | Dynamic tools/list — AI discovers automatically |
| Designed for | Human developers writing code | AI agents acting autonomously |
| Input schema | OpenAPI spec (optional, external) | inputSchema baked into every tool, always present |
| Tool description | Human prose in docs (no machine format) | LLM-optimised description field per tool |
| Response format | Raw JSON / HTML — AI must parse | Typed content blocks — AI reads directly |
| Session / state | Stateless — every request is independent | Lifecycle + capability negotiation + notifications |
| Auth standard | No universal standard — API key / OAuth / custom | OAuth 2.0 for remote, env vars for local |
| Autonomous AI use | No — needs human to write integration code first | Yes — AI discovers and calls tools without human code |
Can an AI use a REST API directly without MCP? ▼
Technically yes — if you hardcode the endpoint, auth, and response parsing into the AI's system prompt or tool definitions. But that's exactly the N×M problem: someone must write that custom code for every API, every AI app, every time. MCP makes this reusable — the weather MCP server works with Claude, ChatGPT, and VS Code without rewriting anything.
Does MCP replace REST APIs? ▼
No. MCP servers call REST APIs internally. The Slack MCP server calls Slack's REST API under the hood. MCP is the protocol between the AI and the server — REST (or gRPC, GraphQL, etc.) is the protocol between the server and the actual data source. They work at different layers.
What about OpenAPI / Swagger specs — can't AI read those? ▼
OpenAPI specs are a step in the right direction — machine-readable API descriptions. But they're optional, often outdated, and not LLM-optimised. MCP tool descriptions are written specifically for LLMs to understand when and how to use each tool. Plus MCP adds transport, auth, lifecycle, and bidirectionality that OpenAPI doesn't cover.
• The Architecture
Three Roles, One Protocol
MCP has three distinct roles: the Host (AI application), the Client (connection manager inside the host), and the Server (the thing that exposes data/tools). The protocol defines how all three interact.
Hover over a component to learn about its role in the MCP architecture.
MCP Host
The AI application — Claude Desktop, VS Code, your custom agent. The Host coordinates one or more MCP Clients and owns the conversation with the LLM.
MCP Client
One Client per Server connection, created by the Host. The Client maintains the dedicated connection and handles protocol-level communication with its Server.
MCP Server
A program exposing tools, resources, and prompts. It can run locally (on the same machine) or remotely (on Sentry's servers, for example). It doesn't know which LLM is behind the Host.
MCP Host (VS Code)
├── MCP Client 1 ──[stdio]──> MCP Server: Filesystem (local)
├── MCP Client 2 ──[stdio]──> MCP Server: Database (local)
└── MCP Client 3 ──[HTTP]──> MCP Server: Sentry (remote)
Why is there a Client between Host and Server? ▼
The Client is the dedicated connection object for one server. A Host connecting to 5 servers creates 5 independent Clients — each managing its own connection lifecycle, capability set, and message stream. This isolation means a crashed Server only affects its Client, not the entire Host.
Can one Server serve many Clients? ▼
Yes, for remote servers (Streamable HTTP transport). A Sentry MCP server running on Sentry's infrastructure can serve hundreds of VS Code instances simultaneously. Local servers (stdio) typically serve one Client at a time since they're spawned as child processes.
• Under the Hood
Connect, Negotiate, Use
Every MCP session follows a defined lifecycle: initialize, negotiate capabilities, then exchange messages. The protocol is JSON-RPC 2.0 — simple request/response with notification support.
Initialization — The client sends an
initialize request with its capabilities. The server responds with its own capabilities. Both parties now know what the other supports.
Capability negotiation is MCP's handshake. The client declares what it can do (e.g., "I support elicitation"), and the server declares what it exposes (e.g., "I have tools and resources, and I'll notify you if my tool list changes"). Neither side sends unsupported messages after this.
// JSON-RPC 2.0 Initialize Request
{
"jsonrpc": "2.0", "id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-06-18",
"capabilities": { "elicitation": {} },
"clientInfo": { "name": "claude-desktop", "version": "1.0.0" }
}
}
// Server Response
{
"jsonrpc": "2.0", "id": 1,
"result": {
"capabilities": { "tools": { "listChanged": true }, "resources": {} },
"serverInfo": { "name": "filesystem-server", "version": "1.0.0" }
}
}
What is JSON-RPC 2.0? ▼
A lightweight remote procedure call protocol using JSON. Every request has a
method, optional params, and an id for matching responses. Notifications have no id and expect no response. MCP uses JSON-RPC 2.0 for all data layer communication.Is MCP stateful or stateless? ▼
MCP is fundamentally stateful — connections have lifecycle, and capability negotiation state persists for the session. However, a subset of MCP can be made stateless using the Streamable HTTP transport, which is useful for serverless deployments.
⚙ Interactive: Capability Negotiation Matrix
Toggle which capabilities the client and server declare during
initialize. See exactly which JSON-RPC methods become available — and which ones are blocked because neither party declared support.
Client declares:
Server declares:
Toggle capabilities above to see which methods activate.
• Server Primitives
Tools, Resources & Prompts
MCP servers expose three kinds of primitives. Each has a different role: Tools are executable actions, Resources are readable data, and Prompts are reusable interaction templates.
Tools are executable functions the AI can invoke. Examples:
query_database, fetch_url, send_email. Each tool has a name, description, and JSON Schema for its input parameters. The LLM decides when to call them; the user can approve.
// tools/list response (excerpt)
{
"tools": [{
"name": "query_database",
"description": "Execute a SQL SELECT query against the connected database",
"inputSchema": {
"type": "object",
"properties": {
"query": { "type": "string", "description": "SQL query to execute" }
},
"required": ["query"]
}
}]
}
Discovery
Clients call
*/list to discover primitives: tools/list, resources/list, prompts/list. Lists can be dynamic — servers notify when they change.Execution
Tools are invoked with
tools/call. Resources are read with resources/read. Prompts are fetched with prompts/get.Bidirectional
Clients also expose primitives. Servers can call
sampling/complete to ask the host LLM for a completion, or elicitation/request to ask the user for input.What's the difference between Tools and Resources? ▼
Tools are executable — they perform actions (query DB, call API, send email). Resources are readable — they provide context data (the DB schema, a file's contents, an API response). The distinction matters: the LLM invokes tools, but reads resources as background context.
What is Sampling, and why is it powerful? ▼
Sampling lets an MCP server ask the host LLM for a completion without needing its own LLM SDK or API key. A server can say "given this context, what should I do next?" — and the host's LLM answers. This enables server-side intelligence that stays model-agnostic.
• Transport Layer
Local vs Remote Transport
The transport layer is how bytes move between client and server. MCP defines two: stdio for local processes, and Streamable HTTP for remote services. Same JSON-RPC protocol, different wires.
stdio transport — The Host spawns the MCP Server as a child process. They communicate over stdin/stdout. Zero network overhead, maximum performance. Used for local servers like the filesystem server, database server, or any server running on the same machine.
stdio Transport
Host spawns Server as child process. Communicates via stdin/stdout.
Best for: local tools (filesystem, DB, shell), developer workflows, private data.
One server instance per client connection.
Best for: local tools (filesystem, DB, shell), developer workflows, private data.
One server instance per client connection.
Streamable HTTP
Client sends HTTP POST to server endpoint. Server can respond with SSE stream for long-running operations.
Best for: SaaS integrations (Sentry, GitHub, Slack), shared infrastructure, remote teams.
One server serves many clients.
Best for: SaaS integrations (Sentry, GitHub, Slack), shared infrastructure, remote teams.
One server serves many clients.
// stdio: server spawned as child process
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/user"]
}
}
}
// Streamable HTTP: remote endpoint
{
"mcpServers": {
"sentry": {
"url": "https://mcp.sentry.io/mcp",
"headers": { "Authorization": "Bearer <token>" }
}
}
}
What is SSE and why does HTTP transport use it? ▼
Server-Sent Events (SSE) is a one-way HTTP stream from server to client. For long-running tool calls (e.g., a database query that takes 10 seconds), SSE lets the server stream progress updates and the final result without the client polling. The initial request is HTTP POST; the streaming response is SSE.
How does auth work for remote servers? ▼
Streamable HTTP supports standard HTTP auth: bearer tokens, API keys, or custom headers. MCP recommends OAuth 2.0 for user-delegated access. Local stdio servers typically inherit the shell environment's credentials (env vars, config files).
• The Ecosystem • What This Means
The MCP Ecosystem
From a Nov 2024 Anthropic release to a cross-industry standard in months. Pre-built servers for every major system. Clients in every major AI app. The N×M problem becomes N+M.
N+M
Integrations needed
15+
Official servers
1000+
Community servers
Free
MIT license
The N×M to N+M shift: Before MCP, connecting 5 AI apps to 10 data sources required 50 custom integrations. With MCP, each AI app implements MCP once (N implementations) and each data source builds one MCP server (M servers). Total work: N+M instead of N×M.
Official Servers
Anthropic ships reference servers for: Google Drive, Slack, GitHub, Git, Postgres, SQLite, Puppeteer, Fetch, Memory, Filesystem, and more.
MCP Clients
Claude Desktop, Claude Code, ChatGPT, VS Code Copilot, Cursor, Zed, Replit, Codeium, Sourcegraph, and dozens more all support MCP.
SDKs
Official SDKs in Python, TypeScript, Java, Kotlin, C#, Swift, and Ruby. Build your server in the language you already use.
How do I build my own MCP server? ▼
Pick an SDK (Python or TypeScript are most popular), define your tools/resources/prompts, and run it. A minimal weather server in Python with the MCP SDK is ~50 lines. The SDK handles all protocol-level concerns (lifecycle, JSON-RPC, transport).
What is the MCP Inspector? ▼
An official debugging tool (open-source) for MCP servers. Connect it to any server and explore its tools, resources, and prompts interactively. Essential for development and testing before wiring a server into a production AI host.
Will MCP replace existing frameworks? ▼
MCP is a protocol, not a framework. LangChain, LlamaIndex, and similar tools are orchestration frameworks. They are complementary — frameworks can use MCP servers as tool sources. MCP focuses solely on the protocol for context exchange; it doesn't dictate how AI applications manage conversation flow or orchestration logic.
• Apply It • Use-Case Simulator
What Would You Wire Up?
MCP servers only matter if they solve a real problem for you. Pick your role — see which servers you'd connect, what flows between them, and what tasks become possible.
Developer setup — Wire up GitHub (code review, PR summaries), Filesystem (read/write project files), Postgres (query your dev database), and Browser (test rendered output). Your AI assistant can now review a PR, find the relevant code files, check the database schema, and open a browser to verify — all in one conversation.
• Knowledge Check
Quiz — How Well Do You Know MCP?
8 questions covering the N×M problem, architecture, primitives, transport, and how MCP differs from function calling.