Building MCP Servers

The Hook

Figure: A stylized bridge connecting chaotic data islands to an organized AI agent, representing a standardized protocol.

How do we bridge the gap between our data and AI agents in a standardized, scalable way?

We have powerful LLMs, and we have our valuable data and business logic. But connecting them has been a messy process of custom integrations and brittle glue code. We need a standard. We need a protocol. That’s what MCP is. Today, we’re going to master the art of building these connectors in Python. We’ll start with the foundational SDK, discover how to speed up development with FastMCP, and finally, learn how to instantly AI-enable our existing web applications.

Today’s Journey

1. The Foundation (MCP Python SDK)
   • Core concepts: Server, Resources, Tools, Prompts
   • Understanding the primitives
2. The Accelerator (FastMCP)
   • Developer experience first
   • Decorators and simplified patterns
3. The Bridge (FastAPI-MCP)
   • Integrating with existing web apps
   • Preserving auth and documentation

Our journey today has three distinct stages. First, we’ll build the foundation by exploring the official MCP Python SDK. This gives us a deep understanding of the core concepts: Servers, Resources, Tools, and Prompts. Next, we’ll accelerate our workflow with FastMCP, a tool designed to let us “move fast and make things” by removing boilerplate. Finally, we’ll cross the bridge to the real world with FastAPI-MCP, showing how to expose our existing FastAPI applications to agents with zero friction.

Part 1: The Foundation (MCP Python SDK)

The Problem: The Integration Mess

Connecting AI to data is hard

• Every tool has a unique API
• Every LLM needs custom glue code
• N tools \(\times\) M models = N \(\times\) M integrations
• Fragile, hard to maintain, not scalable

We need a standard protocol.

Before we define MCP, let’s understand the problem it solves. Right now, connecting AI to data is a mess. Every tool has a different API, and every model provider requires a different format for tools. If you have N tools and M models, you end up writing N times M integration scripts. It’s fragile, it’s hard to maintain, and it doesn’t scale. We need a universal standard.

What is MCP?

Model Context Protocol

• Standardized way to connect LLMs to tools and data
• Like a web API, but for AI interaction
• Separates context from intelligence

Think of the Model Context Protocol, or MCP, as HTTP for AI agents. It’s a standardized way to connect Large Language Models to the tools and data they need. Instead of building custom integrations for every model, MCP provides a uniform structure. It neatly separates the distinct challenge of providing context from the interaction with the LLM itself.

Step 1: Install the SDK

Get the official library:

uv add mcp

Import in Python:

import mcp
from mcp.server.mcpserver import MCPServer

Getting started is simple. We install the official mcp package using uv. This provides all the core primitives we need to build our server. Then, we import the MCPServer class, which will be our main entry point.

The Core Concept: Server

MCPServer is your main interface

from mcp.server.mcpserver import MCPServer

mcp = MCPServer("Demo")

• Handles connection management
• Protocol compliance
• Message routing
• Lifecycle management

Figure: A central server rack with a Python logo connecting to smaller nodes as a hub. (Click to Enlarge)

In the official SDK, the MCPServer instance is your main interface. You initialize it with a name, and it handles the heavy lifting: managing connections, ensuring protocol compliance, routing messages, and handling the application lifecycle. It’s the robust foundation we build upon.

Resources: Reading Data

Expose data to LLMs

@mcp.resource("file://documents/{name}")
def read_document(name: str) -> str:
    """Read a document by name."""
    return f"Content of {name}"

• Read-only data sources (like GET requests)
• Side-effect free (mostly)
• URI templates for dynamic access

Figure: A magnified open document folder symbolizing read-only access to structured data.

Resources are how we get data into the LLM’s context. Think of them like GET endpoints in a REST API. They are designed for reading files, fetching database rows, or retrieving system state. They should be side-effect free—interaction with them shouldn’t change the state of the world significantly.

Tools: Taking Action

Let LLMs perform computations

@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers together."""
    return a + b

• Perform computation or actions
• Side effects allowed (database writes, API calls)
• Model-controlled execution

Figure: Interlocking gears and a wrench interacting with a data block to symbolize active computation.

When the agent needs to do something, it uses Tools. These are the functional counterparts to resources. Tools allow the LLM to perform computations, query databases, or call external APIs. This is where the agency comes in—the LLM decides when to call a tool and what arguments to pass.

Prompts: Interaction Templates

Reusable templates for users

@mcp.prompt(title="Code Review")
def review_code(code: str) -> str:
    return f"Please review this code:\n\n{code}"

• User-controlled invocation
• Standard workflows (e.g., “Fix Bug”, “Summarize”)
• Pre-packaged instructions

Figure: A clipboard with a structured form and pencil representing reusable templates.

Prompts are reusable templates for interactions. Think of them as slash commands or menu options for the user. They provide a structured way to start a task, like “Review this code” or “Check system health,” making standard workflows repeatable and easy to use.

Part 2: The Accelerator (FastMCP)

Framework vs Library

The Distinction:

• MCP SDK (Library): “Mechanism, not Policy.” Provides the plumbing (JSON-RPC, Core Types). precise, but low-level.
• FastMCP (Framework): “Batteries Included.” Provides the policy (Decorators, Validation). Opinionated and fast.

The Engineering Trade-off: Control vs. Velocity

From an engineering perspective, the distinction is between a library and a framework. The official SDK is a library—it gives you the mechanisms (the plumbing of JSON-RPC) but enforces no policy. FastMCP is a framework—it gives you the policy (decorators, validation) and batteries. The trade-off is classic: do you want absolute control over the bits, or do you want development velocity?

The Implementation Gap

Raw SDK (Plumbing)

# 1. Manual Schema
Tool(
    name="get_weather",
    inputSchema={
        "type": "object",
        "properties": {
            "city": {"type": "string"}
        }
    }
)

# 2. Manual Routing
if name == "get_weather":
    city = args["city"]
    return f"Sunny in {city}"

FastMCP (Framework)

# 1. Logic is Interface
@mcp.tool()
def get_weather(city: str) -> str:
    """Get current weather"""
    return f"Sunny in {city}"

Let’s look at the code side-by-side to see the real impact. On the left, with the Raw SDK, you are manually defining JSON schemas and writing if/else routing blocks. On the right, with FastMCP, your code is the interface. The schema is inferred from your type hints. This isn’t just about saving keystrokes; it’s about eliminating a whole class of bugs.

The Hidden Cost: Schema Drift

When implementation diverges from definition.

• SDK: You update the code, but forget the JSON schema. \(\rightarrow\) Runtime Error.
• FastMCP: Single source of truth. The code generates the schema.

In 2026, manual schema maintenance is technical debt.

The biggest problem isn’t verbosity; it’s Schema Drift. In the SDK approach, if you change your function arguments but forget to update the manual JSON schema, you have a bug that only explodes at runtime. In FastMCP, type introspection ensures your schema and code are always perfectly in sync. Manual schema maintenance is a technical debt risk we can avoid.

Step 1: Install FastMCP

Installation:

uv add "fastmcp"

That’s it.

Installation is just as easy. Add the fastmcp package. It includes everything you need, including the CLI tools for development and the dependencies for running the server.

Comparison: The “Batteries”

Feature	Raw SDK	FastMCP
Registration	Manual list_tools	@mcp.tool
Validation	Manual Checks	Automatic (Pydantic)
Observability	Self-Implemented	OpenTelemetry Native
Drift Risk	High	None

Here is the capabilities matrix. FastMCP adds the layer that the SDK explicitly leaves out: automatic validation, native observability via OpenTelemetry, and zero-config tool registration. It fills the “gap” between the raw protocol and a production-ready application.

Core Abstractions

1. Components: What you expose (Tools, Resources, Prompts)
2. Providers: Where they come from (Functions, Files, OpenAPI)
3. Transforms: How they look (Namespacing, Filtering)

Figure: A circular flow diagram showing Providers, Transformers, and Components in a data refinement cycle.

FastMCP organizes the world into three concepts. Components are what you expose. Providers are where those components come from—your functions, files on disk, or even an external API spec. And Transforms let you shape that data—renaming tools, filtering them for security, or versioning your API. It’s a powerful compositional model.

Running FastMCP

Development (Hot Reload)

fastmcp dev server.py

Production

if __name__ == "__main__":
    mcp.run() # Auto-selects streamable-http

For development, fastmcp dev gives you hot reloading and an inspector to test your tools. For production, mcp.run() automatically selects the robust streamable-HTTP transport. It covers the full lifecycle of your application development.

Part 3: The Bridge (FastAPI-MCP)

The Integration Challenge

You have a FastAPI app.

• Do you rewrite it for MCP?
• Do you duplicate your authentication?
• Do you maintain two codebases?

No. You Mount.

Figure: A split-screen showing an overwhelmed developer facing duplicate stacks of FastAPI and MCP code.

Now, what if you already have a massive FastAPI application? Rewriting everything as MCP tools would be a nightmare of duplication—logic, auth, validation. We don’t want two codebases. We want to expose our existing investment to the AI world.

Step 1: Install FastAPI-MCP

Add the package:

uv add "fastapi-mcp"

Requirements: - Existing FastAPI app - Python 3.10+

To bridge the gap, we use the fastapi-mcp package. Install it alongside your existing FastAPI application. It’s a lightweight wrapper that brings MCP capabilities to your existing routes.

FastAPI-MCP: One App, Two Interfaces

from fastapi import FastAPI
from fastapi_mcp import FastApiMCP

app = FastAPI()
mcp = FastApiMCP(app)

mcp.mount() # Adds /mcp endpoint

• Zero Config: Point at your app, it works
• Native Integration: Uses ASGI (in-memory, fast)
• Preserves Auth: Depends(...) just works

Figure: A visual transformation showing FastAPI and MCP blocks merging into a single unified block.

This is fastapi-mcp. With essentially three lines of code, you mount an MCP server inside your FastAPI app. It automatically discovers your routes and converts them into MCP tools. It uses the efficient ASGI transport, so there’s no network overhead. And crucially, it respects your existing authentication.

What Gets Preserved?

Everything.

• Request Models \(\rightarrow\) Tool Input Schemas
• Response Models \(\rightarrow\) Tool Output Schemas
• Docstrings \(\rightarrow\) Tool Descriptions
• Dependencies \(\rightarrow\) Security & Context

When I say it converts your routes, I mean it does it intelligently. Your Pydantic request models become strict input schemas for the LLM. Your response models define the output structure. Your docstrings become the instructions for the agent. And your dependencies—like database sessions or user context—are fully preserved.

Deployment Options

1. Mounted (Monolith)

• Simplest. One container, one process.
• Best for most use cases.

2. Separate (Microservices)

• Scale independently.
• mcp = FastApiMCP(original_app_url=...)
• Good for high-traffic separation.

You have choices in deployment. You can mount it directly, which is the simplest “monolithic” approach—perfect for most teams. Or, if you need to scale your AI traffic separately from your user traffic, you can deploy the MCP server as a separate microservice that proxies requests to your main API.

Key Takeaways

The Foundation (SDK)

• Server: The central hub governing the protocol
• Resources: Reading data (File://, DB://) safely
• Tools: Executing actions (API calls, side effects)
• Prompts: Reusable templates for user interaction

Let’s recap the core pillars. The SDK gives us the Server, our central hub. We use Resources to read data safely, Tools to perform actions and computations, and Prompts to create reusable templates for our users. This is the raw material of any MCP server.

FastMCP Benefits

• Developer Experience: “Move fast and make things”
• Less Boilerplate: No manual JSON schemas
• Type Inference: Python hints \(\rightarrow\) MCP Specs
• Instant Dev Server: Hot reloading included

FastMCP takes that foundation and accelerates it. It prioritizes developer experience, removing the need for manual schema definitions by inferring everything from your Python type hints. Plus, the built-in dev server with hot reloading makes iteration a breeze.

FastAPI Integration

• Zero Rewrite: Mount existing app as MCP server
• Protocol Agnostic: HTTP/SSE handled automatically
• Security Preserved: Existing Depends() just work
• Dual Interface: Serve humans and agents simultaneously

And for our existing applications, FastAPI-MCP offers a zero-rewrite solution. By mounting your app, you get protocol handling for free, you preserve your existing security model, and you serve both human users and AI agents from a single codebase.

Which Tool When? (1/2)

1. MCP Python SDK
   • You need full control over the protocol.
   • You are building low-level custom integrations.
   • You are building an MCP Client.
2. FastMCP
   • You are building a new server from scratch.
   • You want speed and simplicity.
   • You want built-in best practices.

So, which tool should you reach for? Use the Official SDK if you need low-level control or are building a client. Reach for FastMCP if you’re building a new server from scratch and want the best developer experience.

Which Tool When? (2/2)

3. FastAPI-MCP
   • You have an existing FastAPI application.
   • You want to reuse logic, auth, and models.
   • You want to become AI-Ready instantly.

… And use FastAPI-MCP if you’re sitting on a goldmine of existing FastAPI services that you want to open up to the new world of AI agents.

The Complete Picture

You are now equipped to build.

• Foundational understanding
• Rapid development tools
• Integration strategies

Go connect your world.

Figure: A three-layered pyramid showing the SDK foundation, FastMCP builder tools, and FastAPI-MCP bridge.

You now have the complete picture. You understand the foundation, you have the tools for speed, and you have the bridge for integration. The era of isolated data is over. You are now equipped to build the connectors that will power the next generation of AI applications. Go connect your world.