Model Context Protocol Explained: Build Your First MCP Server

Eighteen months ago, connecting a language model to your database, your ticketing system, and your file store meant writing three bespoke integrations — and then writing them again for the next model, and the next framework. Every team rebuilt the same plumbing, slightly differently, and none of it was reusable. The integration layer was a swamp.

The Model Context Protocol drained it. MCP is an open standard for how AI applications talk to external tools and data, and it spread faster than almost any developer protocol in recent memory: by late 2025 there were more than ten thousand public servers, the SDKs were pulling tens of millions of downloads a month, and the protocol had been handed to the Linux Foundation to steward. If you build anything agentic, MCP is now table stakes. Here’s the mental model — and a server you can run today.

What the Model Context Protocol actually is

The cleanest analogy is the one the community settled on: MCP is USB-C for AI. Before USB-C, every device had its own connector; after it, one port spoke to everything. MCP plays that role between AI apps and the world. It defines a small client-server protocol where the host application — Claude, your IDE, your agent — runs an MCP client, and each capability you expose runs behind an MCP server. Client and server speak JSON-RPC over a defined transport, and the model discovers what’s available at runtime.

• Tools — functions the model can call, with typed inputs and outputs. A tool might query your database, file a ticket, or hit an internal API. This is the primitive people reach for first.
• Resources — read-only data the host can pull into context: files, records, documents. Think addressable context the model can reference rather than actions it can take.
• Prompts — reusable, parameterized templates a server offers, so common workflows aren’t re-typed by every user.
• Transport — how client and server connect. Local servers use stdio (the host launches the server as a subprocess); remote servers use streaming HTTP, which is where most production deployments are heading.

Why it spread so fast

Protocols usually die in committee. MCP didn’t, because it solved a problem every AI team had at the same moment — and it solved the math. The old world was M×N: M models or frameworks times N tools, each pairing a custom integration. MCP makes it M+N. Write a server once and every MCP-aware client can use it; adopt a client once and every existing server lights up. That asymmetry is why the ecosystem compounded.

• One integration, every client. A server you write for one host works in any MCP-compatible app, unchanged.
• Discovery is built in. The client asks the server what it can do; you don’t hard-code a tool list into every app.
• It rode the agent wave. As agentic coding tools exploded, they all needed a tool layer — and MCP was the one already there.
• Governance signaled permanence. Handing the spec to a foundation backed by the major AI labs told teams it was safe to build on, not a single vendor’s whim.

Build your first MCP server

The fastest way to understand MCP is to expose one tool. Here’s a complete server in Python using the official SDK. It offers a single tool that returns the weather for a city — stubbed so it runs with no API key — and it speaks over stdio, so any local MCP client can launch it.

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

mcp = FastMCP("weather-demo")

@mcp.tool()
def get_weather(city: str) -> str:
    """Return the current weather for a city."""
    # Real code would call a weather API here.
    fake = {"London": "13C, drizzle", "Tokyo": "24C, clear"}
    return fake.get(city, f"No data for {city}")

if __name__ == "__main__":
    # stdio transport: the host launches this file as a subprocess.
    mcp.run()

That’s the whole server. The decorator turns a typed Python function into a tool the model can call; the SDK generates the JSON schema from your type hints, so the model knows get_weather takes a string named city. Point any MCP client at the file and the tool appears in its list, ready to invoke. You wrote a function and got an integration.

The genius of MCP isn’t the protocol — it’s the refusal to let every team solve the same integration problem privately. Standards win not by being clever, but by being boring in the same way everywhere.

Where teams get it wrong

• Treating tool output as trusted. The model decides what to call; your server decides what’s allowed. Validate every argument and authorize every action server-side — an MCP server is an attack surface, not a convenience layer.
• Exposing too much. A server that wraps your whole database as one tool invites the model to do damage. Offer narrow, purposeful tools, not a raw SQL pipe.
• Ignoring the remote story. stdio is perfect for local dev, but production usually means an HTTP server with auth — a different security and deployment problem. Plan for it early.
• Skipping descriptions. The model picks tools from their descriptions. Vague docstrings cause wrong calls; treat the description as part of the API, not a comment.
• No observability. If you can’t see which tools fired with which arguments, you can’t debug the agent or prove what it did. Log every call from day one.

Where MCP is headed

The 2026 roadmap is about growing up: better remote transport, real authentication and authorization, and registry infrastructure so clients can find trustworthy servers instead of copy-pasting configs. Now that the spec lives under a neutral foundation with the major labs as members, the bet is that MCP becomes invisible plumbing — the layer nobody thinks about because it just works, the way nobody thinks about TCP.

You don’t need to wait for any of that to start. The protocol that matters is the one running on your machine in twenty lines of Python. Build one server, watch a model discover and call it, and the whole agentic ecosystem stops looking like magic and starts looking like something you can ship into.