Building Servers & Clients

A Worked Server, Tools and a Resource

The official Python SDK's FastMCP class is the fastest path from "a Python function" to "a working MCP server." Here's a weather server exposing two tools and one resource:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")

@mcp.tool()
async def get_alerts(state: str) -> str:
    """Get active weather alerts for a US state.

    Args:
        state: Two-letter US state code (e.g. CA, NY)
    """
    alerts = await fetch_alerts(state)
    if not alerts:
        return f"No active alerts for {state}."
    return "\n".join(format_alert(a) for a in alerts)

@mcp.tool()
async def get_forecast(latitude: float, longitude: float) -> str:
    """Get the weather forecast for a specific location."""
    forecast = await fetch_forecast(latitude, longitude)
    return format_forecast(forecast)

@mcp.resource("weather://stations/{state}")
async def list_stations(state: str) -> str:
    """List weather stations for a US state, as a resource clients can read."""
    stations = await fetch_stations(state)
    return "\n".join(s.name for s in stations)

if __name__ == "__main__":
    mcp.run(transport="stdio")

What @mcp.tool() actually does

The decorator inspects the function's type-annotated parameters and builds the inputSchema a client sees via tools/list — state: str becomes a required "type": "string" property, latitude: float becomes "type": "number", and so on. The docstring becomes the tool's description, which is the entire basis the model has for deciding when to call it.

What @mcp.resource() does

resource() registers a URI template — here weather://stations/{state} — as a resource clients can read via resources/read (or discover via resources/templates/list, covered in Resources & Prompts). The function's return value becomes the resource's content. Unlike a tool, nothing calls this because the model decided to — the application fetches it to provide context, per the resources primitive's application-controlled nature.

Running It: stdio vs Remote

mcp.run(transport="stdio") starts the server reading JSON-RPC from stdin and writing responses to stdout — this is exactly what a host like Claude Desktop does when it spawns your server as a subprocess, per Transports.

For a server other clients reach over the network, the same SDK supports running over Streamable HTTP instead — the tool and resource registration code above doesn't change at all; only the transport argument and how you deploy the process differ. This is the shape the MCP project brief asks you to build toward.

Testing Before You Connect It to Anything

The MCP Inspector (github.com/modelcontextprotocol/inspector) is the official tool for this. Point it at your server — stdio or HTTP — and it gives you:

• A live list of every tool, resource, and prompt the server currently reports
• The ability to call any tool manually, with arguments you type in, and see the exact result
• A raw view of the JSON-RPC traffic, useful when a schema or response shape isn't what you expected

npx @modelcontextprotocol/inspector python weather_server.py

Work through every tool and resource in the Inspector before pointing a real host at the server. A tool that works when the model calls it with well-formed arguments and a tool that works when a human tries slightly malformed ones are different tests, and the Inspector makes the second one easy to run.

Building a Client (You Probably Don't Need To)

If you are in that position, a minimal client needs to:

1. Connect over a transport (stdio: spawn the server process; Streamable HTTP: open an HTTP connection)
2. Optionally call server/discover to learn the server's supported versions and capabilities up front
3. Call tools/list (and resources/list, prompts/list as needed) to learn what's available
4. Call tools/call with a tool name and arguments when the model decides to use one, and feed the result back into the conversation

Every request needs the _meta fields covered in The MCP Architecture — protocol version, client capabilities, and client identity — since the protocol is stateless and carries that information per-request rather than negotiating it once.

Concept Checks

Key Concepts Recap

Next

With a working server, the next question is how to actually get it in front of Claude: Connecting Claude to MCP.