What is MCP? — The Protocol That Changes Everything

AI is Smart — But Blind

Large Language Models like Claude, GPT-4, and Gemini are extraordinarily capable. They can write code, analyze data, reason through complex problems, and generate human-quality text. But there's a fundamental limitation that holds them back from being truly useful agents.

By default, an LLM has no access to:

Before MCP, developers solved this with ad-hoc solutions — custom function calling, proprietary plugins, hardcoded tool definitions. Each AI tool vendor had their own approach. It was the equivalent of every website inventing its own version of HTTP.

The result? A fragmented ecosystem where:

• Every integration was one-off (OpenAI function calling !== Claude tools !== Gemini extensions)
• Developers rebuilt the same connectors for each AI tool
• No standard for authentication, error handling, or data formats
• Vendor lock-in: tools built for GPT didn't work with Claude

What is MCP?

The Model Context Protocol (MCP) is an open standard created by Anthropic in late 2024. It defines a universal way for AI models to discover, connect to, and use external tools and data sources — regardless of which AI model or host application is being used.

Just as USB-C standardized how devices connect to peripherals, MCP standardizes how AI models connect to the outside world. Before USB-C, every manufacturer had proprietary connectors. Before MCP, every AI tool had proprietary integrations.

The Key Innovation

MCP separates the AI model from the data sources through a clean, well-defined protocol layer. This means:

A Brief History

Anthropic open-sourced MCP in November 2024. Within weeks, major IDE makers and AI tool providers announced support. By early 2025, MCP had become the de facto standard for AI-to-tool communication. By Q1 2026, virtually every major AI coding tool supports it natively.

MCP Architecture — The Three Layers

MCP uses a client-server architecture with three distinct roles:

1. Host (The AI Application)

The host is the application where the user interacts with the AI. It's the outer container that manages the overall experience. Examples include Claude Desktop, Claude Code CLI, Cursor IDE, or Windsurf.

2. Client (The Protocol Handler)

The client lives inside the host and manages the connection to one or more MCP servers. It handles protocol negotiation, capability discovery, and message routing. Each client maintains a 1:1 connection with a single server. A host can run multiple clients simultaneously.

3. Server (The Tool Provider)

The server exposes tools, resources, and prompts to the AI. It's where the actual integration logic lives — calling APIs, querying databases, reading files, etc. Servers can be local processes (stdio) or remote services (HTTP/SSE).

// User asks Claude Code: "What's the weather in Paris?"

// 1. Host (Claude Code) receives the message
// 2. Claude identifies it needs the "get_weather" tool
// 3. Client sends a tool call request to the weather MCP server
// 4. Server calls the weather API
// 5. Server returns structured data to the client
// 6. Client passes it back to Claude
// 7. Claude formats a natural language response

User  -->  Host (Claude Code)
              |
              v
           Client  --JSON-RPC-->  MCP Server  --HTTP-->  Weather API
              |                       |
              v                       v
           Claude  <--result--    { temp: 18, condition: "sunny" }
              |
              v
         "It's 18°C and sunny in Paris right now!"

The key insight is that Claude never talks to the weather API directly. It talks to the MCP server through a standardized protocol. This means the same MCP server works whether Claude, GPT, or Gemini is the model behind the host.

Capability Negotiation

When a client connects to a server, they perform a handshake:

// Client sends initialize request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-03-26",
    "capabilities": { "roots": { "listChanged": true } },
    "clientInfo": { "name": "claude-code", "version": "1.0.0" }
  }
}

// Server responds with its capabilities
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-03-26",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": { "subscribe": true }
    },
    "serverInfo": { "name": "weather-server", "version": "1.2.0" }
  }
}

After the handshake, the client knows exactly what the server offers — which tools, which resources, which prompts. The AI model can then decide when and how to use them.

The Three Primitives — Tools, Resources, Prompts

MCP defines three core primitives that servers can expose. Understanding the distinction between them is crucial for building effective MCP servers.

Tools — The Power of Action

Tools are the most commonly used primitive. They're functions that the AI model can decide to call based on the conversation context. The model sees the tool's name, description, and parameter schema, and autonomously decides when to invoke it.

{
  "name": "get_stock_price",
  "description": "Get the current stock price for a given ticker symbol",
  "inputSchema": {
    "type": "object",
    "properties": {
      "symbol": {
        "type": "string",
        "description": "Stock ticker symbol (e.g., AAPL, MSFT)"
      }
    },
    "required": ["symbol"]
  }
}

When the user asks "What's Apple's stock price?", the AI sees this tool definition, recognizes it's relevant, and calls it with {"symbol": "AAPL"}. The server executes the function and returns the result.

Resources — Structured Data Access

Resources are data endpoints that the AI can read. Unlike tools, resources are typically selected by the application or user, not autonomously by the model. They use URI-based addressing.

// Static resource — always the same URI
{ "uri": "config://app/settings", "name": "App Settings" }

// Dynamic resource template — URI varies
{ "uriTemplate": "db://users/{userId}/profile", "name": "User Profile" }

// File resource
{ "uri": "file:///var/log/app.log", "name": "Application Logs", "mimeType": "text/plain" }

Resources are ideal for providing context — configuration files, database schemas, documentation, log files. The AI reads them to understand the environment before taking action with tools.

Prompts — Reusable Workflows

Prompts are pre-built templates that define structured interactions. They're like slash commands — the user explicitly selects one, and it generates a conversation with specific context, instructions, and tool references.

{
  "name": "analyze_stock",
  "description": "Deep analysis of a stock with technical + fundamental data",
  "arguments": [
    { "name": "ticker", "description": "Stock ticker", "required": true }
  ]
}

When triggered, the prompt generates a multi-message conversation that guides the AI through a complete workflow — fetching data, analyzing it, and producing a formatted report. Prompts are the most underused primitive but incredibly powerful for standardizing complex workflows.

Transport Layers — How Clients Talk to Servers

MCP supports multiple transport mechanisms. The transport layer determines how messages are physically delivered between client and server.

stdio — The Default for Local Development

With stdio transport, the host spawns the MCP server as a child process. Communication happens through standard input and standard output — the same pipes used by Unix commands. This is the simplest and fastest option.

{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": ["./weather-server/index.js"],
      "env": {
        "WEATHER_API_KEY": "your-api-key-here"
      }
    }
  }
}

When Claude Code starts, it reads .mcp.json, spawns the weather server process, and connects via stdio. Zero network overhead, zero configuration complexity.

Streamable HTTP — The Future of Remote MCP

For production deployments and remote servers, Streamable HTTP is the modern transport. Introduced in the 2025-03-26 protocol revision, it combines the simplicity of HTTP with the streaming capabilities of SSE.

// Client sends requests via HTTP POST
POST /mcp HTTP/1.1
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{...}}

// Server can respond with:
// A) Single JSON response (simple)
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"result":{...}}

// B) SSE stream (for long-running operations)
Content-Type: text/event-stream
data: {"jsonrpc":"2.0","id":1,"result":{...}}

Choosing the Right Transport

Who Supports MCP? — The Growing Ecosystem

MCP adoption has been remarkably fast. Within 18 months of its release, it has become the de facto standard for AI-tool integration across the industry.

AI Hosts (Clients)

Notable MCP Servers

The MCP server ecosystem is growing exponentially. As of early 2026, there are over 2,000 open-source MCP servers on GitHub, covering databases, APIs, cloud providers, developer tools, financial data, and more.

Why MCP > Function Calling, Plugins, and Custom Integrations

Before MCP, there were several approaches to giving AI tools access to external systems. Here's how they compare:

The Critical Advantage: Composability

With function calling, you define tools inline in your API call. They exist for that one session. With MCP, servers are independent processes that can be composed freely:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"]
    },
    "postgres": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "postgresql://..." }
    },
    "filesystem": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-filesystem", "/home/user/project"]
    },
    "dailytickers": {
      "command": "npx",
      "args": ["@anthropic/dailytickers-mcp"]
    }
  }
}

With this configuration, the AI agent has simultaneous access to GitHub (code), PostgreSQL (data), the filesystem (files), and DailyTickers (financial data). It can query the database, push results to GitHub, write a report to disk, and enrich it with market data — all in a single conversation.

What You'll Build in This Series

Over the next four parts, you'll go from zero to a production-ready MCP server. Here's the roadmap:

By the end of Part 5, you'll have a complete mental model of MCP — from protocol theory to production deployment. You'll know how to build servers that give AI agents real-world superpowers.

Prerequisites

• Basic JavaScript/TypeScript knowledge (Node.js)
• Node.js 18+ installed on your machine
• An MCP-compatible AI tool (Claude Code, Cursor, or similar)
• Curiosity about making AI agents actually useful

Quick Quiz — Test Your Understanding