MCP is everywhere. Every AI tool announcement in early 2026 mentions it. Every "modern AI stack" article lists it. But when you ask people what MCP actually is, you get either a PhD thesis or a marketing pitch.

Here's the one-sentence version: MCP is a USB port for AI agents.

That's the whole explanation. OK fine, here's the rest. 😼

The world before the standard

Picture your setup circa late 2024. You're building an AI agent — a program that uses a large language model (LLM — the brain behind ChatGPT, Claude, Gemini) to make decisions and take actions on its own. Your agent needs to query a PostgreSQL database, search the web, manage GitHub issues, and read local files.

For every single tool, you write custom integration code:

# Every tool needs its own glue code
from custom_postgres import query_db
from custom_github import create_issue
from custom_search import web_search
from custom_files import read_file

# Each integration has different:
# - Authentication methods
# - Response formats
# - Error handling
# - Connection management

Every AI vendor built their own integration system. Claude had "tool use." OpenAI had "function calling." LangChain had "tools." They all did the same thing in incompatible ways. Building an integration for one meant rebuilding it for another.

This is the serial-port-parallel-port-proprietary-charger era of AI tooling. Remember that? Before USB, every device had its own cable. Pure chaos. 😹

The gap that needed filling

The problem wasn't that integrations were hard. The problem was that they were hard every single time. A new tool comes out — you write another 200 lines of custom integration. Multiply that by every AI client on the market. The math is brutal.

Someone needed to define a universal plug.

Enter MCP

Anthropic introduced MCP (Model Context Protocol) in late 2024 as an open standard — a universal plug standard for AI tools, like USB but for data. By March 2026, it's become the default way AI agents connect to the outside world.

Here's what connecting four tools looks like with MCP:

{
  "mcpServers": {
    "postgres": { "command": "npx", "args": ["-y", "@mcp/server-postgres", "..."] },
    "github": { "command": "npx", "args": ["-y", "@mcp/server-github"] },
    "search": { "command": "npx", "args": ["-y", "@mcp/server-brave-search"] },
    "files": { "command": "npx", "args": ["-y", "@mcp/server-filesystem", "/home"] }
  }
}

Four tools. Four lines of config. No custom code. Every server speaks the same protocol — a set of rules for how programs communicate — and every client understands it.

The architecture: three actors, zero magic

MCP has exactly three moving parts:

┌──────────────────┐
│       HOST       │  (Claude Code, Cursor, your app)
│                  │
│  ┌────────────┐  │
│  │   CLIENT   │──── MCP Protocol ──── SERVER (Postgres, GitHub)
│  └────────────┘  │
│                  │
│  ┌────────────┐  │
│  │   CLIENT   │──── MCP Protocol ──── SERVER (Search, Files)
│  └────────────┘  │
└──────────────────┘

Host — the AI application you interact with. Claude Code, Claude Desktop, Cursor, Windsurf, or your own custom app.

Client — lives inside the host. Manages the connection to one server. A host can run many clients connected to many servers at once.

Server — provides tools and data. Runs as a separate process — a standalone program — either on your machine or on a remote server.

No orchestration layer. No message queue. No service mesh. Just a client talking to a server over a standard protocol. That's the whole thing. 😸

What flows through the pipe

MCP servers can provide three types of things:

1. Tools — actions the AI can take

Tools are functions — self-contained operations — the AI can call. Like "run a SQL query" or "create a GitHub issue."

{
  "name": "query",
  "description": "Run a read-only SQL query against the database",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sql": { "type": "string", "description": "The SQL query to execute" }
    },
    "required": ["sql"]
  }
}

When the server starts, it tells the client: "Here are the tools I provide, here's what each does, here are the parameters." The AI model reads these descriptions and decides when to use them — the same way you decide which app to open on your phone.

2. Resources — data the AI can read

Resources are pieces of data the server exposes. A file's contents, a database schema (the structure of your tables), a configuration.

The distinction matters: tools do things, resources provide context. The AI reads resources to understand the environment before acting. Think of it as reading the restaurant menu before ordering.

3. Prompts — starter templates

Pre-written templates the server offers, like "analyze this table" or "review this pull request." They're convenience shortcuts that know how to use the server's tools effectively.

Most people ignore prompts and just talk to their AI normally. That's fine. They're optional.

Tracing a real request

Let's follow what happens when you type "Show me all users who signed up today" in Claude Code with a Postgres MCP server connected:

1. YOU type: "Show me all users who signed up today"

2. CLAUDE sees the Postgres MCP tools are available
   (query, list_tables, describe_table)

3. CLAUDE calls 'describe_table' first to understand
   the users table structure

4. CLIENT sends to SERVER:
   { "method": "tools/call",
     "params": { "name": "describe_table",
                 "arguments": { "table": "users" } } }

5. SERVER queries PostgreSQL, returns the schema

6. CLAUDE writes a SQL query based on the schema:
   SELECT * FROM users WHERE created_at >= CURRENT_DATE

7. CLIENT sends the query to SERVER, SERVER runs it

8. CLAUDE formats the results and shows them to you

The whole thing takes 1-2 seconds. You asked in English, the AI figured out the SQL, the MCP server ran it, and you got results. No manual query writing. This is the "aha" moment for most people. 😻

The transport layer — how bits travel

MCP works over two transport methods:

STDIO (local servers) — the server runs as a child process on your machine. Communication happens over stdin/stdout — the same text pipes your terminal uses. This is the most common setup:

{
  "mcpServers": {
    "my-server": {
      "command": "node",
      "args": ["server.js"],
      "env": { "DB_URL": "..." }
    }
  }
}

Simple, fast, no network involved.

Streamable HTTP (remote servers) — for servers on different machines. Cloud-hosted, shared across a team, or third-party services:

{
  "mcpServers": {
    "remote-server": {
      "url": "https://mcp.example.com/sse",
      "headers": { "Authorization": "Bearer your-token" }
    }
  }
}

Requests go as regular HTTP POST. Responses stream back in real time. This is how enterprise deployments work — centralized servers that multiple developers connect to.

Build your own in 20 lines

Here's the simplest working MCP server you can write using the official TypeScript SDK:

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

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

server.tool(
  "hello",
  "Says hello to someone",
  { name: { type: "string", description: "Person to greet" } },
  async ({ name }) => ({
    content: [{ type: "text", text: `Hello, ${name}!` }]
  })
);

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

Install the SDK (npm install @modelcontextprotocol/sdk), define your tools, connect the transport. The SDK handles protocol negotiation — the handshake where client and server agree on what they both support — message parsing, and error handling.

A practical example — weather API

server.tool(
  "get_weather",
  "Get current weather for a city",
  {
    city: { type: "string", description: "City name" },
    units: { type: "string", description: "celsius or fahrenheit", default: "celsius" }
  },
  async ({ city, units }) => {
    const response = await fetch(
      `https://wttr.in/${encodeURIComponent(city)}?format=j1`
    );
    const data = await response.json();
    const current = data.current_condition[0];
    const temp = units === "fahrenheit"
      ? current.temp_F + "°F"
      : current.temp_C + "°C";
    return {
      content: [{ type: "text", text: `${city}: ${temp}, ${current.weatherDesc[0].value}` }]
    };
  }
);

Now your AI agent can check the weather. More importantly, see the pattern: fetch data from any API (application programming interface — the way programs talk to each other), wrap it in an MCP tool, and every MCP-compatible client on the planet can use it.

The capability handshake

When a client first connects to a server, they negotiate:

Client: "I support tools, resources, and prompts. What do you have?"
Server: "I provide 3 tools and 2 resources. Here they are."
Client: "Got it. Ready."

This means clients don't need to know what a server provides in advance. Servers can add or remove features without breaking anything. Different clients can use the same server differently. It's graceful evolution, not brittle coupling.

What's not perfect

Let's not pretend this is flawless. As of March 2026:

Security is still your problem. An MCP server can do anything you give it permission to do. A malicious server could exfiltrate data through tool calls. There's no built-in sandboxing — no automatic isolation from the rest of your system. You trust each server the way you trust any npm package you install. Think about that for a second.

Discovery is messy. Finding the right MCP server for your use case means browsing registries like mcpservers.org or glama.ai/mcp/servers. There's no centralized, verified marketplace yet. Quality varies wildly.

Debugging is rough. When a tool call fails, the error messages often travel through multiple layers — client, protocol, server, underlying API — and come out the other end as mush. Getting better, but still painful.

Performance overhead exists. Every tool call is a JSON-RPC round trip — a request-response message in JSON format. For local STDIO servers, this is negligible. For remote servers over HTTP, latency adds up when the AI chains multiple calls.

What this means for you

If you use AI coding tools like Claude Code or Cursor: MCP means your AI keeps getting new abilities without software updates. A new MCP server for Jira appears? Install it, and your AI manages your tickets. A new server for AWS? Your AI manages your infrastructure. You don't wait for the tool vendor to build integrations — the community builds them.

If you build tools or APIs: MCP means you write one integration and it works with Claude, Cursor, Windsurf, Cline, and every future MCP-compatible client. One server, dozens of clients. That's the USB math.

If you're a founder: building an MCP server for your product is becoming table stakes, like building a REST API was 10 years ago. If your developer tool doesn't have an MCP server, your users will ask why.

The ecosystem as of March 2026

  • Official servers from Anthropic: PostgreSQL, GitHub, Filesystem, Brave Search, Puppeteer, Google Maps, Slack, and more — see the MCP servers repository
  • Enterprise servers from AWS, Cloudflare, Sentry
  • Community servers for Docker, Kubernetes, Notion, Linear, Figma, Stripe — hundreds and counting
  • The 2026 roadmap focuses on agent-to-agent communication, horizontal scaling, and a .well-known discovery mechanism so servers can advertise themselves automatically

USB killed the proprietary charger. MCP kills custom integrations.

MCP is the most important thing to happen to AI tooling since context windows — the AI's working memory — got long enough to fit a real codebase. It's not sexy. It's a JSON-RPC protocol over stdio. But USB wasn't sexy either, and it killed every proprietary connector in its path.

The smartest thing you can do right now: stop reading specification documents. Install a Postgres MCP server, connect it to Claude Code, and ask it about your database. You'll understand MCP in 30 seconds.

The specification is for the people building the protocol. You're using it. 😹