MCP Protocol: Three Months of Production Use

I was skeptical of MCP when I first read the spec. Another protocol, another abstraction layer, another thing to debug. Three months of running MCP servers in production for real client work has flipped my opinion. It's not exciting. It's infrastructure. That's exactly why it works.

What MCP Actually Is

Strip the marketing: MCP is a standard way for an AI agent to discover and call tools. Tools describe themselves, the agent picks which to invoke, the protocol handles the transport. It replaces bespoke integrations with one interface.

Where It Earned Its Keep

The moment MCP proved itself was when I needed the same agent to work across two projects with different toolsets. Before MCP, that meant two prompt versions and two wrapper scripts. With MCP, the agent just queried the available tools and adapted.

{
  "mcpServers": {
    "filesystem": {"command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path"]},
    "postgres": {"command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres"]}
  }
}

Two servers, and the agent knows what it can do in both contexts.

The Boring Part Is the Win

MCP doesn't do anything magical. It standardizes something that used to be ad-hoc. That's the whole value. Instead of writing 'how does this agent talk to my database' from scratch each time, I pick an MCP server and move on.

Specs and reference implementations at the MCP docs.