MCP
The Model Context Protocol — a standard socket between models and the tools they call.
Prerequisites
- Tool Calling — MCP is a transport and lifecycle around tool calling, not a replacement for it.
- Agent Foundations — the loop MCP servers plug into.
Why this section exists
Before MCP, every (application × tool) pair was its own integration. Five agent apps that each need Jira, GitHub, Postgres and Slack means twenty bespoke adapters, twenty auth stories, twenty places to fix the same bug. It's the N×M problem, and the industry has solved it the same way several times before — LSP for editors and language servers, ODBC for apps and databases.
MCP is that solution for models and tools: write the tool server once, and any MCP-speaking client can use it. N×M becomes N+M.
Key insight
MCP does not make a model more capable. It makes integration cheaper and more uniform. For a single app with three tools, defining functions directly in the API call is genuinely the right choice. MCP earns its complexity when tools must be shared across applications, owned by different teams, or distributed to clients you don't control.
MCP is recent enough that most discussion of it stops at the acronym. The client/host/server split, the transports, and the security model are where the actual engineering lives — and they are what this section covers.
What's in here
| Page | The question it answers |
|---|---|
| The MCP Protocol | Host/client/server architecture, transports, tools vs resources vs prompts, connection lifecycle |
| Building MCP Servers | Writing one, the auth and security model, and MCP vs plain function calling |
Where this connects
- Agents — MCP servers are where an agent's tools come from.
- Security — a third-party tool server is untrusted code inside your agent's decision loop; tool-description poisoning and confused-deputy issues live here.
- Design: LLM Gateway — governed tool access is the same governance problem as governed model access.