Key Takeaways
- MCP is a universal translator for AI tools: Before MCP, every AI assistant had its own plugin system — OpenAI plugins, Claude tools, Gemini extensions. MCP creates one standard so a tool built once works with any compatible AI.
- Three capabilities: MCP servers expose Tools (functions the AI calls, like
search_database), Resources (data the AI reads, like the contents of a file), and Prompts (reusable templates the AI loads). Most server implementations focus on Tools. - Sovereign by design: MCP servers run locally or on infrastructure you control. A local MCP filesystem server lets Claude access your files without those files ever leaving your machine.
- Adoption in 2026: MCP is past the “early adopter” phase. Cursor, Zed, Windsurf, Claude Desktop, and Claude Code all support MCP natively. The MCP registry lists over 3,000 published servers as of April 2026.
Introduction
Direct Answer: What is the Model Context Protocol (MCP) and how does it work?
The Model Context Protocol (MCP) is an open standard, published by Anthropic in November 2024 and now maintained as a community standard, that defines a universal interface for connecting AI language models to external tools, data sources, and services. It works as a client-server protocol: the AI assistant (Claude, GPT-4o, Cursor’s AI) acts as the MCP client and sends JSON-RPC messages to MCP servers, which are small programs that expose specific capabilities. An MCP server might provide access to your local filesystem, a PostgreSQL database, your Slack workspace, or GitHub repositories. The AI sends a tools/call request with parameters; the server executes the action and returns results; the AI incorporates those results into its response. MCP servers can run on your local machine (keeping data private) or on a remote server. As of April 2026, MCP is supported by Claude Desktop, Claude Code, Cursor, Zed, Windsurf, and most major AI coding tools.
“MCP is to AI assistants what USB is to computers — a standard connector that lets any tool plug into any AI. Before USB, every device needed its own cable. Before MCP, every AI needed its own plugin API.”
The Problem MCP Solves
Before MCP, connecting an AI to external tools was messy. OpenAI had its plugin system. Anthropic had Claude’s tool-use API. Google had Gemini extensions. Each required a different implementation — if you built a database integration for ChatGPT, it didn’t work with Claude, even though both models could in principle call the same database.
Developers building AI-powered applications faced a choice: support one AI and lock in your users, or build and maintain parallel integrations for each AI they wanted to support. Teams at companies with multiple AI tools used internally were maintaining 3–5 separate integration codebases for the same underlying tools.
MCP solves this with a single standardised interface. An MCP server for PostgreSQL, once built, works with every MCP-compatible client. A developer building a new AI tool writes one MCP server and immediately gets compatibility with Claude, Cursor, Zed, and any future MCP client.
How MCP Works: The Architecture
┌────────────────────────────────────────────────────────┐
│ MCP HOST (AI Client) │
│ e.g. Claude Desktop, Cursor, your custom LLM app │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ AI Model (Claude, GPT-4o, local Ollama model) │ │
│ │ Receives tool results, incorporates into reply │ │
│ └──────────────┬───────────────────────────────────┘ │
│ │ JSON-RPC 2.0 │
│ ┌──────────────▼───────────────────────────────────┐ │
│ │ MCP Client Layer │ │
│ │ Manages connections to MCP servers │ │
│ └──────────────┬───────────────────────────────────┘ │
└─────────────────│──────────────────────────────────────┘
│
┌────────┴─────────────────────────────┐
│ (stdio or HTTP/SSE transport) │
▼ ▼
┌─────────────────┐ ┌─────────────────────┐
│ MCP SERVER │ │ MCP SERVER │
│ (local) │ │ (remote) │
│ filesystem │ │ github.com API │
│ Tools: │ │ Tools: │
│ - read_file │ │ - search_repos │
│ - write_file │ │ - create_issue │
│ - list_dir │ │ - get_pr │
│ │ │ │
│ Resources: │ │ Resources: │
│ - file:///path │ │ - repo contents │
└─────────────────┘ └─────────────────────┘The Three MCP Capabilities
1. Tools — functions the AI can call
Tools are the most commonly used MCP capability. A Tool is a named function with a defined JSON Schema input specification. When the AI decides to use a tool, it sends a tools/call request; the server executes it and returns results.
Example tool call flow:
User: "What's in my /tmp/logs directory?"
AI → MCP client: tools/call { name: "list_directory", arguments: { path: "/tmp/logs" } }
MCP filesystem server: executes ls /tmp/logs
Server → AI: { contents: ["app.log", "error.log", "debug.log"] }
AI → User: "Your /tmp/logs directory contains three files: app.log, error.log, and debug.log."The AI never directly accessed the filesystem — it asked the MCP server to, and the server returned the result.
2. Resources — data the AI can read
Resources are addressable data items — files, database rows, API responses — that the AI can request by URI. A filesystem server might expose file:///home/user/project/README.md as a resource. The AI reads it, the contents are injected into context.
Resources are read-only from the AI’s perspective. They’re appropriate for large data the AI needs to understand but shouldn’t modify directly.
3. Prompts — reusable templates
Prompts are pre-defined instruction templates stored in the MCP server that the user or AI can invoke by name. A code review server might expose a code_review prompt template that structures the AI’s review output consistently. Less commonly used than Tools, but useful for teams who want standardised AI outputs.
The Transport Layer: stdio vs HTTP/SSE
MCP servers communicate with clients via one of two transports:
stdio (standard input/output): The MCP client launches the server as a subprocess and communicates via stdin/stdout. This is the dominant pattern for local MCP servers — simple, fast, no network ports required. The filesystem server, database servers, and most personal-use servers use stdio.
HTTP/SSE (HTTP with Server-Sent Events): The MCP server runs as an HTTP server. The client connects via HTTP. This is used for remote MCP servers (GitHub, Slack, cloud services) and for servers that need to be shared across multiple AI clients simultaneously.
Your ~/.claude/claude_desktop_config.json distinguishes them clearly:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/projects"],
"transport": "stdio"
},
"github": {
"url": "https://mcp.github.com/sse",
"transport": "http-sse"
}
}
}The filesystem server is launched as a subprocess (stdio). The github server is a remote HTTP endpoint.
MCP in Practice: What It Enables
For individual developers: Claude Desktop with an MCP filesystem server can read your local project files, understand your codebase structure, and answer questions about it — without uploading your code to any cloud. A local PostgreSQL MCP server lets Claude query your development database directly during a debugging session.
For AI coding assistants: Cursor, Zed, and Windsurf use MCP to connect their AI features to GitHub (reading PR context), local file systems (understanding project structure), and documentation servers (reading framework docs). The AI assistant in these editors is an MCP client; GitHub Copilot’s equivalent features use proprietary implementations of the same concept.
For enterprise workflows: A company can build MCP servers for their internal tools — JIRA, Confluence, internal databases, monitoring dashboards — and expose them to their AI assistant deployment. The AI gets context-aware access to company data without that data being sent to AI provider APIs, because the MCP server can be deployed on-premises.
For sovereign local AI stacks: Ollama-based local models support MCP via the OpenAI-compatible API. Any MCP client that supports custom model endpoints (Cursor, Continue, LibreChat) can connect a local Qwen3 14B or Llama 4 Scout to the same MCP servers as cloud models. Full local stack: local model + local MCP servers = zero data leaving your infrastructure.
MCP vs Competing Standards
| Feature | MCP (Anthropic, 2024) | OpenAI Function Calling | LangChain Tools |
|---|---|---|---|
| Open standard | ✓ Apache 2.0 | ✗ Proprietary | ✓ MIT |
| Cross-model | ✓ Any MCP client | ✗ OpenAI models only | Partial |
| Server reusability | ✓ Build once, use anywhere | ✗ API-specific | ✗ Framework-specific |
| Local execution | ✓ stdio servers | N/A | ✓ |
| Remote execution | ✓ HTTP/SSE | ✓ | ✓ |
| 2026 adoption | Wide (Claude, Cursor, Zed) | Wide (GPT-4 apps) | Framework-scoped |
MCP’s key advantage over OpenAI function calling is portability — a tool built as an MCP server works with Claude, with local Ollama models, with any future MCP client. It is the only cross-vendor standard for AI tool integration with significant adoption in 2026.
Getting Started: Your First MCP Server in 5 Minutes
# Install the official MCP filesystem server
npm install -g @modelcontextprotocol/server-filesystem
# Add to Claude Desktop config (~/.claude/claude_desktop_config.json)
mkdir -p ~/.claude
cat > ~/.claude/claude_desktop_config.json << 'EOF'
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/home/YOUR_USERNAME/projects"
]
}
}
}
EOF
# Restart Claude Desktop
# Now ask Claude: "What files are in my projects directory?"For building your own MCP server in Python, see the MCP Protocol: Build a Server in Python Dev Corner guide.
The Sovereignty Angle
MCP enables a sovereignty architecture that was previously difficult to achieve. Before MCP, giving an AI assistant access to your local files, databases, or internal tools required either sending data to a cloud API or building complex custom integrations. With MCP, a local server mediates access — the AI asks the server, the server accesses the resource, the result is returned.
For teams handling sensitive data, MCP enables a clear data boundary: the AI model can be cloud-hosted (Claude API) while all tool execution happens on-premises via local MCP servers. Sensitive database queries, file reads, and internal API calls never leave the corporate network. The cloud AI sees only the results the local MCP server decides to return.
For fully sovereign deployments (no cloud AI), a local Ollama model combined with local MCP servers achieves zero external data transmission after initial model download.
Conclusion
MCP is the infrastructure standard that enables AI assistants to reliably connect to tools and data. It solves the fragmentation problem that plagued AI integrations in 2023–2024, provides a clean sovereign architecture (local servers, local data), and has achieved broad adoption across the major AI development tools as of 2026. Understanding MCP is now as fundamental for AI-adjacent development as understanding REST APIs is for web development.
Build your own MCP server with our MCP Protocol: Build a Server in Python guide, or see the complete local AI agent stack in LangChain and LangGraph with Ollama.
People Also Ask
Is MCP only for Claude, or does it work with other AI models?
MCP is an open standard and works with any AI client that implements it. As of April 2026, native MCP support exists in: Claude Desktop and Claude Code (Anthropic), Cursor, Zed, Windsurf, Continue (VS Code extension), LibreChat, and several open-source AI chat interfaces. OpenAI’s ChatGPT does not natively support MCP (it uses its own plugin/tool system), but community projects provide MCP compatibility layers. Local models via Ollama support MCP through OpenAI-compatible API wrappers.
What is the difference between MCP and a regular REST API?
A REST API is a general-purpose HTTP interface — any application can call it. MCP is a protocol specifically designed for AI model communication with tools. The key differences: MCP servers self-describe their capabilities via a tools/list endpoint so the AI can discover what a server can do without prior documentation; MCP messages are structured for AI context windows (responses include metadata AI models use for planning); and MCP handles the back-and-forth conversation pattern of agentic AI (multiple tool calls in a single session) more cleanly than a stateless REST API.
Can I build an MCP server for my own database or internal tool?
Yes — and it is straightforward. Anthropic publishes SDKs for Python (pip install mcp) and TypeScript (npm install @modelcontextprotocol/sdk). A minimal MCP server exposing a single database query tool is approximately 40 lines of Python. The server declares its tools with JSON Schema, implements the call_tool handler, and Anthropic’s SDK handles the transport, serialisation, and protocol negotiation. See MCP Protocol: Build a Server in Python for a step-by-step implementation.
Is MCP secure? Can an MCP server access my machine without permission?
MCP servers only have the permissions you grant them at the OS level. A filesystem MCP server launched with npx @modelcontextprotocol/server-filesystem /home/user/projects can only access /home/user/projects — it cannot access /home/user/.ssh or system directories unless you explicitly grant it access. The MCP protocol itself has no escalation mechanism — the server cannot grant itself additional permissions. Review the code of any third-party MCP server before running it, as with any third-party software. Anthropic maintains a list of officially audited MCP servers at the MCP registry.
Further Reading
- MCP Protocol: Build an AI Tool Server in Python — hands-on implementation guide
- LangChain and LangGraph with Ollama: Build Local AI Agents — use MCP tools in LangGraph agent workflows
- Best Local LLM Models for Coding in 2026 — local models that work with MCP
- Build a Sovereign Local AI Stack — full infrastructure including MCP integration
Last verified: April 25, 2026. MCP specification version 2024-11-05. MCP registry count verified April 25, 2026.
