An MCP server is the smallest possible bridge between an AI agent and a real system — a few dozen lines of code that turn "call this function" into "call this live API," and building one yourself is the fastest way to actually understand the Model Context Protocol instead of just using someone else's. 🧩 Why this matters beyond the tutorial: every MCP server your organization installs — whether it's the official GitHub server, a Postgres connector, or something an intern wired up over a weekend — becomes a piece of the attack surface and the reasoning surface for every agent that talks to it. A tool with a vague description gets misused by the model. A tool with no input validation gets exploited by whatever the model was tricked into passing it. Learning to build one from scratch, end to end, against a real API like GitHub's, is what turns "I've heard of MCP" into "I can review, harden, and ship one." 🔐 📑 In This Post...

The Model Context Protocol (MCP) doesn't have one wire format — it has three, and only two of them are still recommended. stdio runs a server as a local subprocess and swaps messages over standard input/output; HTTP+SSE was the original remote transport and used two separate endpoints; Streamable HTTP replaced it with a single endpoint that can answer with a plain reply or open into a live stream. Picking the wrong one for the job is the single most common reason a working MCP integration falls over the moment it leaves a developer's laptop. 🔌 This isn't a cosmetic choice. GitHub's own hosted MCP server, Anthropic's remote connectors in Claude, and most enterprise MCP gateways today are built on Streamable HTTP specifically because the older SSE design couldn't survive a load balancer. Meanwhile Claude Desktop and Claude Code still default local, developer-machine servers to stdio, because for a single trusted process on one machine, a network transport i...