MCP Explained: The New USB-C of AI Agents

Every developer who has connected an LLM to more than two or three external systems has hit the same wall. Wire up a database, and you write a custom integration. Wire up a ticketing system, and you write another one, with its own auth flow, its own schema conventions, its own way of describing what it can do. Add a third client application that needs the same two systems, and you're maintaining the same integration logic twice, in two codebases, that will drift out of sync within a quarter.

That's the problem Model Context Protocol was built to remove, and it's why the "USB-C for AI" comparison, overused as it's become, is actually accurate. Before USB-C, every device had its own connector and its own cable. USB-C didn't make any single device smarter. It made every device speak the same physical and electrical language, so any cable worked with any port. MCP does the same thing for AI applications and the tools, data, and systems they need to reach.

This is a deep architectural explainer, not a marketing pitch: what MCP actually solves, how it differs from a REST API, the full client-server model, its three core primitives, how auth works, what changes when a server is remote instead of local, the real security risks, a working first server, how this looks in production, how it compares to plain function calling, and what the July 2026 specification rewrite (2026-07-28, the biggest revision since MCP launched) actually changed under the hood.

What MCP Actually Solves

Before a shared protocol existed, connecting M AI applications to N external tools meant writing roughly M × N custom integrations. Every client had to know, ahead of time, exactly how to talk to every tool it wanted to use: which endpoint, which auth scheme, which response shape.

The core idea is that a server describes its own capabilities in a standard, machine-readable way, and a client discovers and uses them dynamically instead of having that knowledge hard-coded at build time. That single design choice is what makes it fundamentally different from how most APIs work today.

MCP vs REST APIs

REST and MCP solve related but distinctly different problems, and the confusion between them usually comes from both using JSON over HTTP.

MCP isn't a replacement for REST. A well-built MCP server frequently wraps a REST API on the inside, translating that API's fixed endpoints into MCP's self-describing tools so an LLM-driven client can use it without custom glue code.

MCP Client/Server Architecture

An MCP deployment has three roles, and it's worth being precise about them because "client" and "server" alone undersell the architecture.

A single host can run several clients at once, each one connected to a different server: one client talking to a filesystem server, another to a database server, another to an internal ticketing server. The host is what aggregates all of those capabilities into a single experience for the user.

Every message on the wire is JSON-RPC 2.0: requests, responses, and notifications. What differs between deployments is the transport carrying those messages:

That change alone is worth sitting with, because it reshapes what a production MCP deployment looks like, covered in the Production Architecture section below.

Tools, Resources, and Prompts

MCP defines exactly three kinds of capability a server can expose, and the distinction between them is about who decides to invoke each one, not just what they technically do.

Authentication and Authorization

Local stdio servers usually don't need their own auth story. They run inside the user's own machine, under the user's own account, so the operating system's permissions are already the trust boundary. Remote, HTTP-based servers are a different matter entirely, and MCP's authorization model is built on OAuth 2.1 with PKCE.

If you're building or integrating a remote MCP server today, issuer validation isn't optional hardening to consider later. It's the specific fix for a documented attack against the exact flow MCP relies on.

Remote MCP

The distinction between local and remote MCP is really a distinction in trust model and deployment shape.

Remote MCP is what makes MCP genuinely useful at organizational scale: one team stands up a single hosted server in front of their internal ticketing system or knowledge base, and every employee's AI client, regardless of which application they're using, connects to that same server instead of each person configuring their own local integration.

One trade-off is worth knowing: the same revision removes SSE stream resumability (the Last-Event-ID mechanism). If a response stream breaks mid-request, the client can no longer resume it. It simply re-issues the whole request as a new one. That's a deliberate simplicity-over-resilience trade, consistent with the stateless-core theme of the whole release.

MCP Security

Connecting an LLM to live tools and data widens the attack surface in ways a pure chat interface doesn't have, and MCP's own design amplifies a few specific risks worth naming directly.

Building Your First MCP Server

Here's a minimal but complete server using the official TypeScript SDK, exposing a single tool over stdio:

import { McpServer, StdioServerTransport } from '@modelcontextprotocol/server';
import * as z from 'zod/v4';
 
const server = new McpServer({ name: 'greeting-server', version: '1.0.0' });
 
server.registerTool(
  'greet',
  {
    description: 'Greet someone by name',
    inputSchema: z.object({
      name: z.string().describe('The person to greet'),
    }),
  },
  async ({ name }) => {
    return {
      content: [{ type: 'text', text: `Hello, ${name}!` }],
    };
  }
);
 
server.connect(new StdioServerTransport());

Production Architecture

A server that works from your laptop over stdio and a server that holds up in production for an organization are different engineering problems. A few things the July 2026 spec makes directly relevant to production deployments:

MCP vs Function Calling

These get confused constantly because MCP tools, at the wire level, are ultimately delivered to a model as something very close to a function-calling schema. The difference is entirely in what sits around that schema.

Where MCP Is Going

The July 2026 specification isn't a small point release. It's described by its own authors as the largest revision since MCP launched, and it delivers on a roadmap built around four goals: a stateless core that scales on ordinary HTTP infrastructure, an authorization model that matches how OAuth and OpenID Connect are actually deployed, a formal deprecation policy so the protocol can keep evolving without breaking existing servers overnight, and a real extensions framework for functionality that doesn't belong in the protocol core.

That last point is where the near-term future is heading. Rather than growing the core specification indefinitely, new capability now ships as opt-in extensions:

The Bottom Line

MCP's real contribution was never a clever new wire format. It was deciding that AI applications and the tools they use should agree on one shared language instead of every pairing inventing its own. The July 2026 specification pushes that idea further: a stateless core that scales the way ordinary web infrastructure already knows how to scale, authorization hardened against a real attack class, and new capability landing as opt-in extensions instead of an ever-growing core.

The USB-C comparison holds up because it's the right kind of boring. A good connector standard doesn't make headlines for what it does. It makes headlines for how much custom cabling nobody has to build anymore.