MCP: the protocol that became the USB of artificial intelligence

Before USB, every manufacturer had its own connector. Printers, cameras, keyboards — each device required a different cable and a specific driver. It worked, but it was a compatibility nightmare.

The world of AI tools was living the same problem until mid-2025. Each assistant (Claude, ChatGPT, Gemini, Copilot) had its own way of connecting external tools. If you created a plugin for Claude, it wouldn’t work in Cursor. If you built an integration for Copilot, it wouldn’t run in Windsurf.

Then MCP (Model Context Protocol) came along and changed everything.

From 100K to 8 million downloads in 5 months

MCP was launched by Anthropic as an open protocol for connecting language models to external tools. The idea was simple: define a standard contract so any tool could be used by any AI agent, without custom integration.

In November 2025, it had 100,000 npm downloads. By April 2026, it surpassed 8 million. Not because Anthropic forced adoption, but because the problem it solves is real and the solution is elegant.

Today, all major AI agents support MCP: Claude Desktop, Claude Code, Cursor, Windsurf, Cline, OpenCode. Google adopted it for Gemini. Microsoft is integrating it into Copilot. And the number of available MCP servers already exceeds 10,000.

How it works (technically)

MCP defines three primitives:

Tools

Functions that the agent can call. Each tool has a name, a natural language description (which the model uses to decide when to call it), and a JSON schema for parameters.

{
  "name": "search_code",
  "description": "Search for code patterns across the repository",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "language": { "type": "string" }
    },
    "required": ["query"]
  }
}

The model sees this description and autonomously decides when to call the tool, which parameters to pass and how to interpret the result. No hardcoding.

Resources

Data that the agent can read. Unlike tools, resources are passive — the agent pulls information when needed. Examples: file contents, query results, system state.

Prompts (templates)

Pre-defined templates that guide the agent in specific tasks. An MCP server can offer a “review-code” prompt that instructs the agent on how to do code review following the team’s conventions.

Transport

MCP supports two transport modes:

stdio: the server runs as a child process of the client. Communication via stdin/stdout. Ideal for local tools (file reading, git, terminal).

HTTP with SSE (Server-Sent Events): the server runs remotely. The client makes HTTP requests and receives events via SSE. Ideal for cloud services.

The transport choice is transparent to the model. It calls the same tool the same way, regardless of whether it runs locally or on a remote server.

Why it worked (when others failed)

This isn’t the first attempt to standardize AI tools. ChatGPT had plugins. LangChain has tools. AutoGPT had API integration. Why did MCP succeed?

1. Radical simplicity

The entire spec fits in a few pages. A basic MCP server can be implemented in 50 lines of code. This drastically lowered the barrier to entry. Any developer can create an MCP server in an afternoon.

2. Protocol, not platform

MCP doesn’t require you to use a specific framework, language or service. It’s a protocol — a communication contract. You implement it your way.

3. Network effects

The more tools support MCP, the more agents adopt it. The more agents adopt, the more tools support it. This virtuous loop accelerated adoption after the initial critical mass.

4. Perfect timing

MCP arrived at the exact moment AI agents were evolving from “chatbots” to “agents with tools”. The demand for a standard protocol was real and urgent.

The ecosystem that emerged

MCP created an ecosystem that didn’t exist before. Some examples:

Code tools: GitNexus (knowledge graphs), Serena (semantic analysis), Context7 (library documentation). Each solves a dimension of the code understanding problem, and all work with any MCP agent.

Memory and context: MCP Context Hub (persistent memory + context optimization). Solves the problem of agents forgetting everything between sessions.

Service integration: MCP servers for GitHub, Jira, Slack, databases, REST APIs. The agent can check a Jira ticket, create a branch, write code, open a PR and post to Slack, all without leaving the conversation.

Infrastructure automation: MCP servers for Docker, Kubernetes, AWS. The agent can query logs, scale services and investigate incidents.

What previously required custom integration for each agent + tool combination now works plug-and-play. Create one MCP server and it works across all agents.

Deeper into the protocol: how communication actually flows

Understanding MCP at the implementation level reveals why it’s so flexible. The protocol follows a client-server model with JSON-RPC 2.0 as the message format. Every interaction is a structured JSON message with a method, params, and an ID for correlating requests with responses.

Here’s what a real tool call looks like at the wire level:

// Client -> Server (request)
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search_code",
    "arguments": {
      "query": "validateToken",
      "language": "typescript"
    }
  }
}

// Server -> Client (response)
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Found 12 matches in 8 files..."
      }
    ]
  }
}

The lifecycle starts with an initialization handshake where the client and server exchange capabilities. The server declares which tools, resources, and prompts it offers. The client declares what features it supports (like sampling, where the server can ask the client’s LLM to generate text). This negotiation means both sides know exactly what the other can do before any real work starts.

One detail that matters in practice: MCP supports notifications, which are one-way messages that don’t expect a response. This is how the server tells the client “my tool list changed” or “this resource was updated”. It keeps things reactive without polling.

Error handling

MCP uses standard JSON-RPC error codes plus custom ones for tool-specific failures. When a tool call fails, the error message goes back to the model, which can decide whether to retry, try a different approach, or ask the user for help. This is a subtle but important design choice: errors are part of the conversation, not silent failures.

More real-world use cases

Beyond the developer tools ecosystem, MCP is being adopted in ways I didn’t expect when I first started using it.

Data analysis pipelines

A data team I work with built MCP servers that wrap their SQL databases, dbt models, and data quality dashboards. Their analysts use Claude to ask questions like “what’s the conversion rate trend for the last 90 days, broken down by acquisition channel?” The agent queries the database via MCP, runs the analysis, and generates visualizations. No custom dashboard needed.

Customer support automation

One startup built an MCP server that wraps their entire support stack: Zendesk tickets, knowledge base, customer data (with PII redaction), and Slack. Their support agents (human ones) use Claude with these MCP tools to draft responses, pull customer history, and escalate issues. The resolution time dropped by 40% because the agent handles the information gathering while the human focuses on the actual problem-solving.

Internal developer platforms

Platform engineering teams are building MCP servers that expose their internal tools: CI/CD pipelines, feature flags, service catalogs, incident management. Instead of learning 10 different UIs, developers describe what they want (“deploy the latest staging build of auth-service to production” or “create a feature flag for the new checkout flow”) and the agent orchestrates the right tools.

Research and literature review

Academic teams are using MCP servers that connect to paper databases (Semantic Scholar, arXiv), citation graphs, and note-taking tools. A researcher can ask “find recent papers on transformer efficiency that cite the FlashAttention paper” and get structured results with summaries and relevance scores.

MCP vs. alternatives: an honest comparison

MCP isn’t the only approach to connecting AI models with external tools. Here’s how it compares with the main alternatives:

vs. OpenAI Function Calling

OpenAI’s function calling is similar in concept (define tools with JSON schemas, let the model decide when to call them) but it’s tightly coupled to OpenAI’s API. You define functions in the API request, and the model returns function call objects in the response. The key difference: function calling is an API feature, not a protocol. Your tools only work with OpenAI models. MCP tools work with any compatible agent.

vs. LangChain Tools

LangChain provides a tool abstraction within its framework. You define tools as Python classes with descriptions and schemas, and the framework handles orchestration. The limitation: your tools are bound to the LangChain ecosystem. If your agent runs on Cursor, Claude Code, or any non-LangChain setup, those tools don’t transfer. MCP tools are framework-agnostic by design.

vs. Custom API integrations

Before MCP, most teams built custom integrations for each agent-tool pair. Agent A calls Tool B via a bespoke REST wrapper. This works but doesn’t scale. With N agents and M tools, you need N x M integrations. MCP reduces this to N + M: each agent implements the MCP client once, each tool implements the MCP server once.

vs. ChatGPT Plugins (deprecated)

ChatGPT plugins used OpenAPI specs to define tool capabilities. It was a good idea but had two fatal flaws: it was exclusive to ChatGPT, and the plugin marketplace created a walled garden. MCP is open, not controlled by any single company, and works across all major agents.

The bottom line: MCP wins not because it’s technically superior in every dimension, but because it’s an open, simple, cross-platform protocol. That combination is rare and powerful.

Implications for software architecture

MCP is changing how we think about development tools. Before, each tool was an isolated application with its own interface. Now, tools are becoming interface-less services that expose capabilities via MCP.

This has two important consequences:

1. The interface is the agent

If your tool works via MCP, the “interface” is the AI agent. Users don’t need to learn a new UI. They simply describe what they want in natural language and the agent calls the right tool.

2. Free composition

MCP tools are composable. The agent can combine GitNexus (understand code structure) + Context Hub (search architectural decisions) + GitHub MCP (open a PR) in a single task. This composition happens dynamically, without pre-configured integration.

This echoes the Unix philosophy: each tool does one thing well and communicates via a standard protocol (pipes in Unix, MCP in the AI era).

How to create an MCP server

The official SDK supports TypeScript and Python. Here’s a minimal TypeScript server:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "my-tool", version: "1.0.0" });

server.tool(
  "greet",
  "Greet someone by name",
  { name: z.string() },
  async ({ name }) => ({
    content: [{ type: "text", text: `Hello, ${name}!` }]
  })
);

const transport = new StdioServerTransport();
await server.connect(transport);

That’s it. This server can be used by Claude Code, Cursor, Windsurf or any other MCP client. The barrier to entry is intentionally low.

What comes next

MCP is still evolving. Some areas in development:

• Standardized authentication: today each server implements auth its own way. A standard authentication spec is under discussion.
• Result streaming: for tools that return large data (logs, search results), progressive streaming is essential.
• Server discovery: a centralized registry where agents can automatically discover relevant MCP servers.

But the protocol core is already stable and adopted. Companies building AI tools without MCP support are, in practice, building for an isolated ecosystem. Just like building a peripheral without USB in 2010.

MCP isn’t the only thing that matters in the AI ecosystem. But it’s the glue that connects everything. And that’s enough to change the game.

---

Links:

• MCP Specification
• TypeScript SDK
• Python SDK
• MCP Servers Directory