Building Your First MCP Server

When I built my first internal support dashboard, the hardest part was never the model. It was wiring the model up to the things it actually needed: the notes my team kept on common problems, and the queues a ticket had to land in. A model on its own can write a friendly reply, but it cannot read your knowledge base or move a ticket — not unless you give it a clean, safe way to reach those things.

That clean, safe way is the Model Context Protocol (MCP). In this module I will build the server side of the de-identified support-triage assistant we have been developing across this path. The assistant takes an incoming customer message, looks up what we already know, and decides where the ticket should go. The MCP server is what lets it do the looking-up and the routing without me hand-coding a brittle bridge every time.

Think of an MCP server like the service window at a busy kitchen. The cooks (your data and actions) stay in the back where it is safe. The window exposes exactly two things to the outside: a menu you can read, and a bell you can ring to place an order. The assistant never wanders into the kitchen — it only uses the window. That boundary is the whole point.

By the end of this module you will have a running server the assistant can connect to, exposing one knowledge-base lookup and one routing action.

MCP draws one line that beginners stumble over, so let me make it concrete before any code. A server offers two kinds of things, and they are not interchangeable.

A resource is something the assistant can read. It has no side effects. Asking for a resource twice changes nothing. In our triage assistant, the support knowledge base is a resource — the assistant reads the note for "export-failing" the same way you read a label on a shelf.

A tool is something the assistant can do. It has side effects, or at least makes a decision that matters. Routing a ticket to the billing queue is a tool — calling it is an action, not a lookup.

Here is the mental model I keep: a resource is a read-only shelf; a tool is a power outlet. You glance at the shelf as often as you like. You plug into the outlet deliberately, because something happens when you do.

Every MCP server also has a third piece — the server core that speaks the protocol — but the SDK gives you that for free. Your job is to declare the resources and tools.

Before writing code, I always write the contract in plain English. For the triage server it is short:

• Resource — support notes. Given a topic like export-failing, return the note my team wrote about it. Read-only.
• Tool — route a ticket. Given the customer's message, decide which queue it belongs in and whether a human needs to look.

Notice what is not here. The server does not call a language model, and it does not try to be clever. The intelligence — deciding when to look something up and when to route — lives in the assistant (the agent we build in the next module). The server just offers honest, predictable capabilities. Keeping that split clean is what makes the whole system debuggable later.

The Python MCP SDK ships a high-level interface called FastMCP that handles the protocol plumbing. Install it first:

Now the smallest possible server. This does nothing useful yet — it just starts up and speaks the protocol — but it is real and it runs:

FastMCP("support-triage") creates the server and names it. mcp.run() starts it and, by default, talks over standard input and output — which is exactly how a local assistant connects to it. Everything we add next hangs off that mcp object.

Now we give the server something to offer. First the resource — the read-only knowledge base. We attach it with the @mcp.resource(...) decorator, and the {topic} placeholder in the URI becomes the function's argument:

When the assistant reads kb://export-failing, the SDK calls support_note("export-failing") and hands back the string. No side effects, no decisions — a pure lookup, exactly what a resource should be.

Now the tool — the routing action. We use @mcp.tool(), and because it is a tool, the assistant calls it on purpose to make something happen:

This tool is deliberately simple keyword matching — and that is fine. It is a deterministic helper, not the brains of the operation. The assistant in the next module decides whether to call route_ticket at all; the tool just gives a fast, predictable answer when asked.

Mid-Module Checkpoint

Before moving on, predict the answer: if the assistant needs to read a customer's past order history, should you expose it as a resource or a tool? Why? (Hint: does reading order history change anything?) Reasoning through that distinction is the skill this whole module is teaching.

The SDK ships an inspector that launches your server and lets you poke at its resources and tools by hand. Point it at your file:

That opens a local UI where you can read kb://export-failing and call route_ticket with a sample message — the fastest way to confirm the server behaves before connecting a real assistant.

For a quick sanity check in code, remember that the decorated functions are still ordinary Python. You can call them directly:

When I built the real support-automation version of this, that layered habit is what kept me sane — I never had to wonder whether a failure was the model's fault or the server's, because I had already proven the server worked on its own.