MCP: The Protocol That Ate GitHub — aniketkarneai.com | aniketkarneai.com
daily

MCP: The Protocol That Ate GitHub

How Anthropic's Model Context Protocol went from internal experiment to essential infrastructure in under 18 months — and what it means for every AI developer building with agents.

In January 2025, Anthropic quietly released a protocol specification called MCP to a small group of developers. By December, it had 50,000 GitHub stars. Today, in mid-2026, it powers integrations across VS Code, Docker, GitHub, and dozens of cloud platforms — and it’s become so foundational that new developers assume it always existed.

The story of how MCP took over is a case study in how infrastructure protocols win: not by being first, but by being the easiest thing that actually works.

The Problem MCP Solved

Before MCP, connecting an AI agent to external tools meant writing custom integrations for every new tool. The agent needed access to your codebase, your Slack, your file system, your database. Each integration was a one-off: custom auth, custom API calls, custom error handling. An agent that could reason about code couldn’t automatically also check your calendar or search your documentation without you building that bridge from scratch.

The industry responded with two bad options: either build a monolithic agent with everything baked in (great for demos, terrible for production), or build point-to-point integrations that became a maintenance nightmare as tools changed.

MCP’s insight was simple: treat tool access like a filesystem. Instead of custom API code for each tool, define a standard interface that any MCP-compatible server can implement. The agent speaks MCP to the server. The server translates to the tool. Change your vector database? Swap out the MCP server, not the agent’s code.

// What MCP client initialization looks like
{
  "jsonrpc": "2.0",
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "roots": {"listChanged": true},
      "sampling": {}
    },
    "clientInfo": {
      "name": "aco-system",
      "version": "1.0.0"
    }
  }
}

The protocol handles capability negotiation, resource access, and tool invocation through a unified message format. No more per-tool SDKs.

Why It Stuck (And Why Others Didn’t)

Google hadAgent Space. OpenAI had chat extensions. Anthropic’s competitors all tried to own the agent layer. MCP took the infrastructure bet: instead of building a better agent, build the plumbing that makes any agent work with any tool.

This is a pattern we’ve seen before. HTTP won over proprietary B2B protocols because it was good enough for anyone to implement. USB replaced a dozen proprietary connector standards because it was universally accessible. MCP is playing the same role for AI tool integration.

The numbers support the bet. The official MCP SDK repository has over 22,000 stars. The unofficial list of MCP servers maintained by the community — everything from Salesforce to Slack to file system access — has grown from 12 servers at launch to over 200 today. Anthropic’s own Claude desktop app uses MCP to connect to every major tool in a developer’s stack.

What This Means for Agent Builders

For Aniket’s work on multi-agent systems — particularly the ACO System’s pipeline architecture — MCP is significant in a specific way. The fixed pipeline structure (PM → Architect → Developer → Reviewer) defines how work flows. MCP defines what each stage can connect to. You can swap out the tools available at any pipeline stage without changing the stage itself.

The protocol is not the whole story. MCP doesn’t solve orchestration, doesn’t define agent roles, doesn’t handle multi-turn state management. Those are still the hard problems. But for the peripheral question of “how does my agent talk to the world,” it’s increasingly the default answer.

And in infrastructure, being the default is everything.

Aniket Karne
DevOps & AI Engineer · Amsterdam
Back to all posts