Build with MCP

What MCP actually is

Before MCP, every AI app connected to every tool with its own bespoke glue. If you had M assistants and N tools, you were writing something close to M×N one-off integrations. The Model Context Protocol, introduced by Anthropic in late 2024 and now maintained as an open standard, replaces that mess with a single contract. Write a tool as an MCP server once, and any MCP-capable client can use it. People often call it "USB-C for AI" — one plug, many devices.

Under the hood MCP is not magic. It's a messaging standard built on JSON-RPC 2.0: structured request/response messages with names, parameters, and results. A server advertises what it can do, the client asks for those things, and the model decides when to call them. A server exposes three kinds of capability — tools (actions the model can invoke, like "search tickets" or "send an invoice"), resources (data the model can read, like a file or a database row), and prompts (reusable templates a user can trigger). Learn those three words and most of MCP falls into place.

Start with the official overview at modelcontextprotocol.io and the architecture guide — they're the canonical source and stay current as the spec evolves.

The architecture: host, client, server

Three roles, and the naming trips people up, so hold them clearly. The host is the AI application you actually use — Claude Desktop, Claude Code, an IDE, or an agent you built. The host spins up one client for each server it connects to; the client is a thin connector that owns a single dedicated session. The server is the program that exposes tools, resources, and prompts. So a host talking to three servers is running three clients — one apiece.

The protocol splits into two layers. The data layer is the JSON-RPC conversation: initialization and version handshake, capability discovery ("what tools do you have?"), tool calls, and notifications. The transport layer is how those messages physically move between client and server. The clean part of the design is that the same JSON-RPC messages ride over any transport, so the logic you write doesn't change when you switch from a local server to a remote one.

This is why MCP scales: your tool code doesn't know or care which model is on the other end, and the model doesn't know how your tool is implemented. The contract in the middle is the whole point.

Transports: stdio vs Streamable HTTP

MCP defines two standard transports, and picking the right one is mostly about where the server runs. stdio uses standard input and output streams to talk to a server running as a local subprocess on the same machine. It's the simplest and fastest option — no network, no ports, no auth — and it's how most personal, local servers connect. Local stdio servers usually serve a single client.

Streamable HTTP is the transport for remote servers. The client sends messages by HTTP POST, and the server can stream results back using Server-Sent Events when it needs to. Because it rides on ordinary HTTP, it supports the authentication you already know — bearer tokens, API keys, custom headers — and one remote server can serve many clients at once.

The spec is versioned by date, and a July 2026 release candidate adds a stateless core, an extensions framework, and hardened authorization. Check the specification for the current revision before shipping.

Build your first server

Enough theory — write one. The official Python SDK ships a helper called FastMCP that turns a decorated function into a fully-formed tool. Install it, save the file below, and you have a real MCP server that speaks the protocol over stdio.

# install:  pip install "mcp[cli]"
# server.py — a minimal MCP server with one tool
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")

@mcp.tool()
def get_forecast(city: str) -> str:
    """Return a short weather forecast for a city."""
    # A real server would call a weather API here.
    return f"{city}: 72F and clear."

if __name__ == "__main__":
    mcp.run()  # speaks MCP over stdio by default

That's a complete server. The docstring becomes the tool's description that the model reads, the type hints become the input schema, and the return value flows back as the tool result. Prefer TypeScript? The TypeScript SDK mirrors this exactly. Every official SDK exposes the same primitives — pick the language you already work in.

Connect it to a client

A server does nothing until a host launches it. For a local stdio server, you register it in the host's config. In Claude Desktop that means adding an entry to claude_desktop_config.json telling it the command to run:

{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["/absolute/path/to/server.py"]
    }
  }
}

Restart the host, and your get_forecast tool appears. Ask "what's the forecast for Denver?" and the model calls it. The same server works from Claude Code and a growing list of other MCP-capable clients — the config format varies slightly, but the server is identical. That reuse is the payoff of a shared protocol: you wrote the tool once.

While developing, use the SDK's built-in inspector to call your tools directly without a full host in the loop — it's the fastest way to confirm a server behaves before wiring it into an assistant. The clients directory lists what supports MCP today.

Security basics

An MCP server can run code, read files, and hit APIs on your behalf, so treat installing one exactly like installing any other software: know who wrote it and what it can touch. A few habits keep you safe. Only connect servers you trust — a malicious server can describe a tool one way and do something else. Apply least privilege: give a server the narrowest file paths, scopes, and API keys it needs, never your master credentials. Be deliberate with write and delete tools — keep destructive actions behind a confirmation, and don't let an agent run them unattended.

For remote servers, authentication is non-negotiable. Streamable HTTP carries standard auth, so require a token on every request and validate it; never expose a server to the open internet unauthenticated. Keep secrets in environment variables, out of tool descriptions and logs. The 2026 spec revision explicitly hardens the authorization story, which tells you the ecosystem takes this seriously — you should too.