← Back to articles

MCP (Model Context Protocol): The Quiet Revolution in AI Agents

Anthropic's new protocol might standardize how AI agents connect to tools. Here's why that matters more than it sounds.

Last month I was building an agent that needed to access files, query a database, and search the web. Sounds simple. It wasn’t.

The file access used one format. The database wrapper used another. The web search had its own authentication dance. I spent more time wiring things together than building the actual agent logic.

Then I discovered MCP, and I’m genuinely annoyed I didn’t find it sooner.

What MCP Actually Is

Model Context Protocol is Anthropic’s open specification for connecting AI models to external tools and data sources. Think of it as a standardized interface for AI agents—instead of writing custom integrations for every tool, you use MCP servers that all speak the same protocol.

The core concept is straightforward. You have an AI agent—the host—that wants to use tools. Those tools are exposed through MCP servers. The protocol defines how they communicate. One server for file access. One for databases. One for web search. Each speaks the same protocol, and they’re all interchangeable.

The USB analogy is common but slightly misleading. MCP is more like a simplified RPC (Remote Procedure Call) protocol specifically designed for LLM-tool interaction. It handles the serialization, capability discovery, and request/response patterns that every tool integration needs.

Why This Matters for Agent Developers

Let me show you the difference this makes in practice.

Before MCP, adding file access to an agent meant writing a custom tool class with methods for reading, writing, and listing directories. You needed security checks to prevent the agent from accessing things it shouldn’t. Then you had to format that tool for your specific LLM—Claude’s tool format differs from OpenAI’s function calling, which differs from everyone else’s. Every tool and every LLM combination required custom glue code.

With MCP, you add a config entry specifying which server to use and what paths it can access. The filesystem server handles all the operations, security, and message formatting. Your agent just uses it.

This isn’t just about saving typing. When someone builds an MCP server, it works with any MCP-compatible host. Build once, use everywhere. The community can share tools instead of everyone reimplementing the same integrations.

For context on how this compares to existing approaches: OpenAI’s function calling is model-specific and requires you to handle all the tool implementation yourself. LangChain tools are framework-specific and require LangChain integration. MCP aims to be model-agnostic and framework-agnostic—a tool built for MCP should work with Claude, but theoretically also with any other MCP-compatible host that emerges.

The Architecture

MCP has three component types that work together.

flowchart TD
    subgraph Hosts
        H1[Claude Desktop]
        H2[Your Agent App]
    end
    
    subgraph Protocol
        P[MCP Protocol]
    end
    
    subgraph Servers
        S1[📁 Filesystem]
        S2[🗄️ Database]
        S3[🌐 Web Search]
        S4[🔧 Custom Tools]
    end
    
    H1 <--> P
    H2 <--> P
    P <--> S1
    P <--> S2
    P <--> S3
    P <--> S4

Hosts are the AI applications that want to use tools. Claude Desktop is a host. Your custom agent could be a host. Any application that needs to give an LLM access to external capabilities can implement the host side of the protocol.

Servers are the tools themselves. A server exposes capabilities that hosts can use. The current ecosystem includes servers for filesystem access (reading, writing, directory listing), PostgreSQL and SQLite databases, GitHub (repos, issues, PRs), Slack (messages, channels), Brave Search, Puppeteer for browser automation, and generic HTTP requests. The full list is at github.com/modelcontextprotocol/servers.

The protocol defines three types of capabilities. Resources are data the AI can read—files, database records, API responses. Tools are actions the AI can take—writing files, executing queries, sending messages. Prompts are pre-built templates for common workflows.

Setting It Up

MCP is built into Claude Desktop, so that’s the easiest starting point. Here’s how to set it up on each platform.

macOS: Create or edit ~/Library/Application Support/Claude/claude_desktop_config.json

Linux: Create or edit ~/.config/Claude/claude_desktop_config.json

Windows: Create or edit %APPDATA%\Claude\claude_desktop_config.json

Here’s a working configuration with two servers:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/yourname/Documents",
        "/Users/yourname/Projects"
      ]
    },
    "brave-search": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-brave-search"],
      "env": {
        "BRAVE_API_KEY": "your-api-key-here"
      }
    }
  }
}

After saving the config, restart Claude Desktop. The servers start automatically when Claude launches. You can verify they’re working by asking Claude to list files in your Documents folder or search for something.

Security Considerations

This is important: MCP servers run with significant privileges. The filesystem server can read and write files wherever you give it access. A database server can execute queries. A browser automation server can interact with websites.

Principle of least privilege: Only give servers access to what they need. Don’t give the filesystem server access to / or your entire home directory. Specify exactly which folders it should access.

API key management: Store sensitive keys in environment variables or a secrets manager, not in the config file directly. If you commit your config to version control, you’ll leak credentials.

Network exposure: By default, MCP servers communicate over stdio (standard input/output) with the host process. They’re not exposed to the network. If you’re building a custom setup that exposes servers over HTTP or WebSockets, you need authentication and authorization.

Sandboxing: MCP doesn’t provide sandboxing itself. If you’re running untrusted servers or giving agents access to sensitive systems, consider running servers in containers with limited permissions.

For production deployments, you’ll want additional controls—audit logging of all tool invocations, rate limiting, and probably human approval for sensitive operations. The protocol supports these patterns but doesn’t enforce them.

Building Your Own Server

If you need a tool that doesn’t exist, here’s a minimal working MCP server in TypeScript:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";

// Create server instance
const server = new Server(
  { name: "my-custom-server", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

// Define available tools
server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "get_weather",
      description: "Get current weather for a city",
      inputSchema: {
        type: "object",
        properties: {
          city: { type: "string", description: "City name" },
        },
        required: ["city"],
      },
    },
  ],
}));

// Handle tool calls
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "get_weather") {
    const city = request.params.arguments?.city as string;
    // In reality, call a weather API here
    const weather = `Weather in ${city}: 72°F, sunny`;
    return {
      content: [{ type: "text", text: weather }],
    };
  }
  throw new Error(`Unknown tool: ${request.params.name}`);
});

// Start server
async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("Weather MCP server running");
}

main();

Save this as weather-server.ts, compile with tsc, and reference it in your config:

{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": ["/path/to/weather-server.js"]
    }
  }
}

The SDK handles protocol details—message framing, capability negotiation, error formatting. You just implement your tool logic.

The Honest Assessment

MCP isn’t perfect, and you should understand the tradeoffs before betting on it.

Advantages: The reduction in integration work is dramatic—days of custom code become a config file. The standardization creates real ecosystem benefits where servers built once work everywhere. If MCP becomes widely adopted, tools built today work with hosts released tomorrow.

Disadvantages: MCP is Anthropic-centric. They built it primarily for Claude, and while the protocol is open, other LLM providers haven’t adopted it yet. If you’re using OpenAI exclusively, there’s limited value today—you’d be building for a hypothetical future where OpenAI supports MCP.

The ecosystem is also young. There are dozens of servers, not hundreds. You might still need custom integrations for specialized tools. Many existing servers are designed for local development; cloud and enterprise patterns are still emerging.

When to use MCP: You’re building with Claude and need multiple tools, you want to leverage community-built servers, or you’re prototyping and want to move fast.

When to skip MCP: You need one highly-optimized custom integration, you’re exclusively using non-Anthropic models, you need production-grade security guarantees today, or you have existing integrations that work fine.

Where This Goes

Short-term, I expect the MCP ecosystem to grow to a hundred or more servers over the next six months. Claude Desktop will become meaningfully more useful as a result.

Medium-term, other LLM providers will either adopt MCP, create competing standards, or the community will build adapters. “MCP compatible” might become a selling point for developer tools.

Long-term, tool integration becomes commoditized. The interesting problems shift from “how do I connect this tool” to “how do I orchestrate many tools effectively.”

The Bottom Line

MCP is boring infrastructure that makes exciting things easier to build. It won’t make headlines, but it might be one of the more important developments for practical AI agents.

If you’re building agents with Claude, start using MCP now. The time investment pays back quickly.

If you’re using other models, keep MCP on your radar. Either it becomes a broader standard and you’ll want to use it, or competing standards emerge and you’ll want to understand the pattern.