From “How Does This Work?” to “How Did I Build Without This?”
The first time I tried to set up a Model Context Protocol (MCP) server from scratch, it was a weekend project that turned into a two-day slog through JSON schemas, transport negotiation, and a growing suspicion that I had accidentally wandered into enterprise middleware territory. I got it working eventually, but I remember thinking: “This is supposed to be the protocol that connects AI to everything. Why does it feel like I’m filing tax returns?”
That was last year. MCP was powerful, but it wasn’t exactly beginner-friendly. You had to hand-write JSON Schema for your tool parameters, manage session IDs, handle transport lifecycle manually — and that was before you even got to the authentication layer. A lot of developers I know looked at it, nodded respectfully, and went back to building custom API integrations.
Fast-forward to today, and the landscape has shifted. FastMCP — the Python framework that now powers roughly 70% of all MCP servers across every language — has matured into something genuinely approachable. And with the MCP protocol itself about to get a major stateless update that makes deployment dramatically easier, there’s never been a better time to learn how to build your own MCP server.
What Exactly Is MCP?
If you’re not familiar, think of MCP as a standard way for AI models to talk to external tools and data sources. It’s the plumbing — the standardized interface that lets a chatbot reach into your database, query your calendar, search your internal documentation, or trigger a workflow in Salesforce without engineers building custom integrations for every single connection.
Anthropic originally designed it for Claude, but the protocol is model-agnostic. Any LLM that implements the MCP client side can talk to any MCP server. It’s like USB-C for AI tools — one connector, endless possibilities.
FastMCP: The “Make It Pythonic” Approach
FastMCP started as a community project by Prefect (the workflow orchestration company) and became so popular that version 1.0 was actually incorporated into the official MCP Python SDK. Today, the standalone project is downloaded over a million times a day, and it’s the de facto standard for building MCP servers in Python.
Why? Because it turns what used to be a verbose, schema-heavy process into something that looks like a regular Python script. You define a function, add a decorator, and FastMCP handles the rest — JSON Schema generation, transport negotiation, protocol lifecycle, everything.
Installation
Getting started is refreshingly simple. If you have Python installed, you just need pip or uv:
pip install fastmcpOr if you’re using uv (which I’ve been preferring lately for its speed):
uv add fastmcpThat’s it. One command and you’re ready to build. To verify it installed correctly:
fastmcp versionYou should see version information confirming FastMCP 3.x and MCP 1.25+ support.
Your First MCP Server
Create a file called my_server.py:
from fastmcp import FastMCP
mcp = FastMCP("My First Server")
if __name__ == "__main__":
mcp.run()That’s a complete, working MCP server. It doesn’t do anything useful yet, but it handshakes correctly with any MCP client and advertises itself properly.
Adding a Tool
Let’s make it useful. Add a function with the @mcp.tool decorator:
from fastmcp import FastMCP
mcp = FastMCP("My First Server")
@mcp.tool
def greet(name: str) -> str:
"""Greet someone by name."""
return f"Hello, {name}!"
@mcp.tool
def add(a: int, b: int) -> int:
"""Add two numbers together."""
return a + b
if __name__ == "__main__":
mcp.run()Notice what you don’t see: no JSON Schema, no manual parameter validation, no type coercion logic. FastMCP reads your Python type hints and generates the correct MCP schema automatically. The docstrings become the tool descriptions that the AI model sees when deciding which tool to call.
Running the Server
There are two main ways to run your server depending on where your AI client lives.
Stdio Transport (Local AI Clients)
If your AI client runs on the same machine — Claude Desktop, Codex CLI, or any local agent — use the default stdio transport:
python my_server.pyOr with the FastMCP CLI:
fastmcp run my_server.py:mcpThe server communicates over standard input/output, which is how most desktop AI tools expect to connect. The CLI option is useful because you can override the transport at runtime without changing your code.
HTTP Transport (Remote Access)
Want to expose your server over the network so other machines or AI agents can reach it?
if __name__ == "__main__":
mcp.run(transport="http", port=8000)This starts an HTTP server on port 8000 that speaks the MCP protocol. Any MCP client — local or remote — can connect to it at http://localhost:8000/mcp.
Connecting from a Client
FastMCP also provides a client library, so you can test your server programmatically:
import asyncio
from fastmcp import Client
async def main():
client = Client("http://localhost:8000/mcp")
async with client:
result = await client.call_tool("greet", {"name": "Felix"})
print(result) # Hello, Felix!
asyncio.run(main())The client handles transport negotiation, authentication, and protocol versioning transparently. You just specify the URL and start calling tools.
What the Stateless Update Means for You
This is where things get interesting. The TechCrunch piece published yesterday — written by Russell Brandom — detailed how MCP is about to get a major architectural upgrade. The core change: MCP is moving to a stateless session model on the server side.
Under the current system, an MCP client connects to a server, exchanges a handshake, and gets back a session ID. Every subsequent request includes that ID so the server remembers the conversation. That works fine for a single server, but picture a real deployment — you’re running behind a load balancer with dozens of server instances across multiple regions. Each request could land on a different machine, and now every machine has to know about session IDs that some other machine handed out. As Arcade founder Nate Barbettini put it: “It fights the load balancer instead of working with it.”
The new stateless approach removes that burden. Servers won’t need to track session state anymore, which means load-balanced deployments become trivial. For developers like us building MCP servers for internal tools or side projects, this is a huge deal — enterprise-grade deployment patterns become accessible without the complexity.
Practical Things You Can Build
Once you have a working MCP server, the use cases start piling up fast:
Database query tools. Give your AI agent read-only access to a PostgreSQL database so it can answer questions about your data directly. One decorator, one connection string.
Internal API wrappers. If your company uses Jira, Slack, or a custom CRM, wrap their APIs as MCP tools. Your AI coding assistant can then look up tickets, post messages, or check order status without toggling between apps.
Documentation search. Connect your AI agent to your internal knowledge base or wiki. Instead of guessing, it can pull the exact answer from your documentation.
File system operations. Build tools that read, search, or analyze files in specific directories. Great for code review automation or log analysis.
And here’s the thing — you don’t have to choose between self-hosting and using cloud AI services. With MCP, you can feed your local tools and data into whatever model you prefer, whether that’s a locally-run open-source model or a cloud API. It bridges the gap between the two approaches I wrote about in “Done Renting AI”.
A Word on Safety
One concern that comes up whenever I talk about giving AI agents access to tools is safety. You’re essentially letting an AI model call functions on your system — what stops it from running a destructive command or leaking sensitive data?
This is a valid worry, and it’s something I’ve covered in detail before — from keeping AI agents on a leash with Destructive Command Guard to auditing what your AI tools actually upload to the cloud. With MCP, the principle is the same: you control exactly which tools you expose and what permissions they have. No tool executes unless you explicitly define it and the AI client calls it with your specific parameters.
Start with read-only tools. Add write capabilities carefully. And always know what your AI agent can actually do — not just what you think it can do.
Where to Go From Here
The MCP ecosystem is moving fast. FastMCP 3.x is stable and production-ready, the protocol itself is getting the stateless treatment that makes deployments dramatically simpler, and the community around it keeps growing.
If you’re already using AI coding assistants like Claude, Codex, or even Grok Build — which supports MCP plugins natively — building your own MCP server is the next logical step. It’s the difference between using AI tools and extending them.
Start with a simple server, add one tool at a time, and see what sticks. You might be surprised how quickly “I should build an MCP server for that” becomes your reflex.