Model Context Protocol
Every tool you give an agent costs tokens before it asks a single question. MCP defines how to give agents the right tools at the right cost.
Model Context Protocol standardizes how AI models access external capabilities — databases, APIs, file systems, and other tools. Before MCP, every AI application invented its own integration layer. MCP is the USB-C standard for agent-tool connections: build the server once, use it with any MCP-compatible client.
Architecture
Three roles, one protocol:
Host (Claude Code, Cursor, Claude Desktop)
└── Client (one per server connection)
└── Server (exposes tools/resources/prompts)
└── External system (DB, API, filesystem)
| Role | Job | Examples |
|---|---|---|
| Host | Contains the LLM, manages all client connections | Claude Code, Cursor, Claude Desktop |
| Client | Protocol adapter — one per server, handles transport | Built into the host application |
| Server | Exposes capabilities to the client | Supabase MCP, GitHub MCP, Perplexity MCP |
Connection flow:
- Host creates a client for each configured server
- Client connects via transport (subprocess stdio for local; HTTP+SSE for remote)
- Client and server negotiate capabilities (handshake lists what's available)
- Model receives all tool schemas; calls tools as it reasons
- Results flow back through client into model context
Three Primitives
Every MCP server exposes some combination of three capability types:
| Primitive | What it is | Token behavior |
|---|---|---|
| Tools | Functions the model calls — search, query, write, execute | Schema in context always; result only when called |
| Resources | File-like data the model can read — documents, DB records, configs | Loaded on request; can be large |
| Prompts | Reusable prompt templates with typed arguments | Minimal schema cost; injected on demand |
Tools are the main capability. Resources and prompts extend the pattern for read-heavy and templated workflows.
Token Economics
Loading tools is not free. Research shows MCP tool definitions inflate input tokens by 3x to 236x depending on the toolset. Every schema loaded before the first message is tokens unavailable for reasoning.
Session budget = context_window × 0.6 (reserve 40% for reasoning)
MCP overhead = Σ(tool_schema_tokens) + Σ(tool_result_tokens)
Target = schema overhead < 15% of session budget
Static vs dynamic loading:
| Strategy | Token cost | Best for |
|---|---|---|
| Static (always load) | All schemas in context from turn 1 | Toolsets of ≤5 tools used every session |
| Dynamic (load on demand) | Only schemas for tools currently needed | Large toolsets — reduces overhead by 96% |
| Team profiles (curated sets) | Right tools per role, nothing extra | The recommended approach |
The practical rule: if a tool isn't in your team's Always Load column, don't load it. See the adoption radar and team matrices for per-team tool profiles.
Transport Types
| Transport | How it works | Best for |
|---|---|---|
| stdio | Server runs as a subprocess; client communicates via stdin/stdout | Local servers — filesystem, CLI tools |
| HTTP + SSE | Server runs as a remote HTTP service; client connects via SSE | Cloud-hosted servers — APIs, SaaS integrations |
stdio is zero-latency and needs no networking. HTTP enables remote, shared server instances — one Supabase MCP server for the whole team.
Why MCP vs Function Calling
Traditional function calling required each application to define its own tools. No reuse across applications. No standard security model. No dynamic discovery.
| Dimension | Function calling | MCP |
|---|---|---|
| Integration | Per-application custom code | Standard protocol — build once |
| Discovery | Static tool list at startup | Dynamic capability negotiation |
| Security | Defined per integration | Server-enforced access controls |
| Composability | Each agent rebuilds the stack | Shared server ecosystem (2,000+ servers) |
| Resources | Tools only | Tools + resources + prompts |
The compounding effect: a well-designed MCP server built once works in Claude Code, Cursor, Claude Desktop, and any future client without modification.
Context
- MCP Tool Selection — Adoption radar, team profiles, decision checklist, governance protocol
- MCP Server Catalog — Reference list of available servers
- A2A Protocol — Agent-to-agent communication (complements MCP)
- Agent Commerce — Transaction protocol layer above MCP
- Agent Frameworks — Frameworks that orchestrate MCP clients
Links
- MCP Specification — Official protocol documentation
- MCP Token Research — Academic benchmarks on token inflation
- Dynamic Toolsets — 96% reduction approach
Questions
Which MCP server design decision — tool schema clarity, stateless versus stateful context, or authentication model — has the most impact on agent reliability at scale?
- At what tool count does an MCP server become too complex for an agent to reliably select the right tool without additional routing logic?
- If dynamic loading reduces token overhead by 96% but increases tool calls by 2-3x, when is static loading still worth it?
- Which of the three primitives (tools, resources, prompts) is most underused — and what workflow does that gap represent?