MCP Servers: Building Your First One in 30 Minutes

MCP servers sound heavy until you build one. Then you realize it is a short-lived process that reads JSON from stdin, writes JSON to stdout, and exposes a few tools. That is the whole protocol in one sentence.

What You Actually Build

An MCP server declares a list of tools, each with a name, description, and JSON schema for inputs. Claude (or any MCP client) reads the tool list, decides when to call one, and receives the result. You write the tool implementations.

# minimal_mcp.py
from mcp.server.fastmcp import FastMCP
 
mcp = FastMCP('my-server')
 
@mcp.tool()
def get_weather(city: str) -> str:
    '''Get weather for a city.'''
    return f'Sunny in {city}, 24C'
 
if __name__ == '__main__':
    mcp.run()

That is a complete MCP server. One tool, one function. Register it in Claude Desktop's config and Claude can call get_weather during a conversation.

Why Build One

I have three local MCP servers running: one reads my Strapi content, one queries DynamoDB staging, one runs my project-specific linter. Each one saves me from copy-pasting output into chat. Claude calls the tool, reads the result, continues. Zero context switching.

What To Expose

Start with read-only tools. Queries, lookups, searches. Those are safe and useful. Write tools (create, update, delete) come later, after you trust the shape of the prompts. Destructive tools need confirmation flows you design carefully.

See the MCP specification and the Python SDK. Your first server takes half an hour. The second one takes ten minutes because you already know the shape.