Understand Anthropic's Model Context Protocol (MCP), how it standardizes tool and resource access for AI agents, and when to build an MCP server instead of raw function calling.
26 min read2026-04-05mediummcpmodel-context-protocolai-agentstool-useai
MCP is an open protocol (Anthropic, November 2024) that standardizes how AI models connect to external tools, data sources, and prompt templates.
It collapses the N x M integration problem: instead of building custom connectors for every (AI client, tool) pair, you build one MCP server that works with any conforming client.
Three primitive types: tools (model-controlled actions), resources (application-controlled data), and prompts (user-controlled templates).
Architecture: Host (Claude Desktop, Cursor) contains an MCP Client that connects to MCP Servers over stdio (local) or HTTP+SSE (remote), using JSON-RPC 2.0.
As of early 2026, 40+ open-source MCP servers exist (filesystem, GitHub, Slack, Postgres, etc.) and clients include Claude, Cursor, Zed, Sourcegraph Cody, and Continue.dev.
Use MCP when your tools need to work with multiple AI clients. Use raw function calling when you control both ends and portability does not matter.
Your team builds a code search tool for your LLM-powered assistant. It works with your OpenAI-based agent. Then your team adopts Cursor. And Claude Desktop. And a LangGraph-based internal agent. Each AI client has a different tool integration format, so you end up maintaining four separate implementations of the same underlying tool.
That is the N x M integration problem. N AI clients, M tools. Every combination requires custom glue code. When the tool's API changes, you update four places. Behavior drifts between implementations because nobody tests all four.
Continue Reading with Premium
Unlock this article and every other in-depth system design guide on the platform with NotesFromSDE Premium.
I have seen teams rewrite the same Slack integration three times for three different AI clients within a single quarter. Each version had slightly different error handling and different parameter names. MCP exists so you never do that again.
The bottom line: MCP collapses N x M custom integrations down to N + M standard ones. That is the entire value proposition.
The Model Context Protocol is an open specification for communication between AI model hosts and servers that expose tools, data, and prompts. Anthropic published it in November 2024, but it is developed as a community standard with contributions from multiple companies.
Think of MCP as USB-C for AI integrations. Before USB-C, every device had a different cable and connector. Before MCP, every AI client had a different tool integration format. USB-C gives you one physical interface that works with any device. MCP gives you one protocol that works with any conforming AI client.
The protocol is transport-agnostic and uses JSON-RPC 2.0 as its message format. It defines a clear separation: the AI application (the host) contains an MCP client, the tools live in MCP servers. The client discovers what the server offers, and the model decides what to use and when.
If you know Language Server Protocol (LSP) from the editor world, MCP follows the same philosophy. LSP standardized how editors talk to language tools so you build one language server and every editor can use it. MCP does the same for AI tool access.
The specification is open-source (MIT license) and hosted on GitHub. Official SDKs exist for TypeScript and Python, with community SDKs for Rust, Go, Java, and C#. Anthropic stewards the spec but does not control it. Any company can build MCP clients or servers without permission or licensing.
The host application (Claude Desktop, Cursor, your custom agent) embeds an MCP client. That client maintains connections to one or more MCP servers. Each server exposes some combination of the three primitives. The model, through the host, discovers available capabilities and decides what to use based on the current task.
One important constraint: each MCP client maintains a 1:1 connection with each server. A host that connects to five servers has five independent client instances. The servers do not know about each other. Coordination across servers (if needed) happens in the host application, not at the protocol layer.
A single host can connect to many servers simultaneously. Your Cursor instance might connect to a filesystem MCP server, a GitHub server, and your company's internal search server, all at once. Each server is independent and stateless from the others.
MCP defines three primitive types, each with a different control model:
Primitive
Controlled by
Purpose
Example
Tools
Model decides when to invoke
Execute actions
run_tests(file), send_slack(channel, msg)
Resources
Application decides when to read
Provide data into context
file:///src/main.py, db://users/123
Prompts
User decides when to activate
Reusable prompt templates
code-review(diff), summarize(document)
Tools are the most familiar if you know function calling. A tool has a name, a description the model reads, and a JSON Schema for parameters. The model decides whether and when to call a tool based on the conversation. The key difference from raw function calling: the tool lives in an external server, not embedded in your API request.
Resources are data endpoints the model can read. Think of them like GET endpoints in a REST API. A filesystem server exposes files as resources. A database server exposes tables or rows. Resources use URIs (file:///path, db://table/id) and can include MIME types for structured data.
Prompts are reusable templates with arguments. A code review server might expose a code-review prompt that takes a diff and returns a structured review prompt. This centralizes prompt engineering in the server, so every client benefits from improvements to the template.
For your interview: the three primitives map to three control models. Tools are model-controlled, resources are application-controlled, prompts are user-controlled. That distinction is the design insight most candidates miss.
Stdio (local): The MCP server runs as a subprocess on the same machine as the client. Communication happens over standard input/output. This is the most common setup for development tools. Claude Desktop launches an MCP server process, pipes JSON-RPC messages through stdin/stdout, and the server responds.
HTTP + Server-Sent Events (remote): The MCP server runs as an HTTP service. The client sends requests via HTTP POST and receives streaming responses via SSE. This is for production deployments, shared team servers, and cloud-hosted tools.
Both transports carry the same JSON-RPC 2.0 messages. The protocol is the same; only the wire format differs.
The transport choice has real implications. Stdio servers start in ~100ms and have zero network overhead, but they are limited to the local machine. HTTP/SSE servers require hosting infrastructure and add network latency, but they can serve an entire team. Most teams start with stdio for development and switch to HTTP/SSE for production or shared tooling.