"Building an MCP server is surprisingly approachable — define a few tools, describe them clearly, and any AI host can use them."
Level: Intermediate · Time: ~14 min · Prerequisites: Module 25
Learning Objectives
By the end of this module, you will be able to:
- Outline the steps to build an MCP server
- Define a tool with a clear description
- Understand why descriptions matter so much
- Test a server locally
1. What a Server Provides
An MCP server is a small program that exposes capabilities (tools, resources, prompts) over the protocol. SDKs exist for Python, TypeScript, C#, Java, and more, so you write ordinary functions and the SDK handles the MCP messaging.
Explain like I'm new: Building a server is like writing a few normal functions, then putting a standard label on each so any AI app understands what it does and how to call it. The SDK does the "speaking MCP" part for you.
2. The Basic Steps
- Create the server with the SDK.
- Define tools — a function + a clear description + typed inputs.
- (Optional) add resources and prompts.
- Choose a transport — stdio (local) or HTTP (remote).
- Run and connect a host to it.
Conceptually (Python-style pseudocode):
[object Object], mcp.server ,[object Object], Server
server = Server(,[object Object],)
,[object Object],
,[object Object], ,[object Object],(,[object Object],) -> ,[object Object],:
,[object Object],
,[object Object], lookup_weather(city)
server.run() ,[object Object],Key idea: The tool's description and input types are part of the interface — the LLM reads them to decide when and how to call it. A vague description means the model misuses (or ignores) your tool. Write descriptions for the model, not just for humans.
3. Why Descriptions Matter
The model chooses tools based purely on their names and descriptions. "get_weather: Get the current weather for a city" is clear. "gw: does weather" is not. Precise, unambiguous descriptions are the difference between a reliable server and a frustrating one. The description should also spell out when to use the tool and what it returns: "Returns today's temperature and conditions for a given city; use for current weather, not forecasts." That extra sentence prevents the model from reaching for the tool in the wrong situation or misreading its output.
Real-world use case: A team builds an internal MCP server exposing search_tickets, get_customer, and create_ticket. Now any AI tool the company adopts — today's assistant or next year's — can support agents instantly, because the capabilities live in one reusable server.
Explain like I'm new: Writing a tool description is like labeling a button for someone who's never seen your app. "Submit" is vague; "Submit order and charge card" tells them exactly what happens. The model reads your label to decide whether to press — so write it for a careful stranger.
4. Testing Locally
Most SDKs ship with an inspector — a tool to connect to your server, list its capabilities, and call them by hand. Test each tool in isolation before wiring it to an LLM, so you can tell "server bug" from "model confusion." This separation saves hours of debugging: if the inspector shows your get_weather tool returning the right data but an agent still stumbles, the problem is the description or the prompt, not the function. Fix the code first, then tune how the model sees it.
Common mistake: Returning huge, messy blobs from a tool. The result goes into the model's limited context window. Return clean, concise, relevant data — trim and format results so you don't waste context or confuse the model.
Hands-On: Try This
Try this: Write a one-line description for three tools of a "notes" server: add_note, search_notes, delete_note. Make each so clear the model would never confuse them. Then decide which needs user approval (hint: delete_note). That's real MCP server design.
✅ Checkpoint
- What does an MCP server expose?
- Why are tool descriptions critical?
- What's an easy way to test a server before using an LLM?
Answers: 1) Tools, resources, and prompts over the protocol. 2) The model picks tools from their names/descriptions, so clarity determines correct use. 3) Use the SDK's inspector to list and call capabilities by hand.
Key Takeaway: An MCP server exposes tools (and resources/prompts) using an SDK that handles the protocol — you mostly write normal functions with clear descriptions and typed inputs, since the model chooses tools from those. Pick a transport (stdio/HTTP), test with the inspector, and return clean, concise results to protect the context window.
Further Learning
Adapted from Microsoft's MCP for Beginners (MIT License).