How to Think About Building an MCP Server
An MCP server is the piece of software that lets an AI assistant reach your system. Building one is less about code than about decisions: what to expose, how to name it, what to protect. This guide walks through those decisions in plain terms, so that whether you write the server yourself or ask someone to, you know what a good one looks like.
Start with the questions, not the system
The temptation is to expose everything your database can do. Resist it. An AI model reading your server sees a list of tool names and descriptions, and it picks from that list to answer a user's question. A long list of low level operations makes it guess. A short list of clear, purposeful tools makes it right.
So begin with the questions people actually ask. For a hotel: is the restaurant open tonight, do you have a table for four, can I book it, is the pool child friendly, what time is checkout. Each becomes a candidate tool or resource. Everything else waits.
Tools, resources and prompts
MCP gives you three kinds of thing to publish.
Tools are actions. They take inputs and do something or compute something: check availability for a date and party size, reserve a table, look up the hours of a named outlet. Tools are what let an agent act.
Resources are data to read. A list of outlets with their descriptions, the current menu, the pet policy. The model reads them for context without calling an action.
Prompts are reusable instructions. A "plan a dinner at this property" prompt that tells the model which tools to use in which order. Optional, but useful for common multi step tasks.
A good first server often has three to six tools and a few resources. That is enough to be genuinely useful and small enough that the model uses it correctly.
Describe each tool like you are briefing a new employee
The model chooses tools by reading their descriptions. A tool called "query" with the description "runs a query" will be ignored or misused. A tool called "check_table_availability" described as "returns whether a table is available at a named restaurant for a given date, time and party size" will be called correctly on the first try.
Name the inputs clearly and say what format they take. A date is a date in a specific form. A party size is a whole number. The more precisely the inputs are typed, the fewer malformed requests you receive.
Return structured results
The result a tool sends back goes straight into the model's context. Return clear fields, not a dump. "available: yes, times: 19:00, 19:30, 20:00" is better than a page of HTML. Keep results compact; the model's context is limited, and a bloated response crowds out everything else.
Decide what the model may do, and enforce it
The model proposes, your server disposes. Treat every incoming request as untrusted. Validate inputs. Check permissions. For anything irreversible or costly, such as a booking or a cancellation, consider making the tool request a confirmation step, or have it create a pending reservation that a person approves. The model should never be the only thing standing between a request and a consequence.
Log every call. You will want to know what agents asked for, what they received, and where they got confused.
Keep facts in one place
If your server reads from the same source of truth as your website and your structured data, every channel agrees. If the server has its own copy of the hours, it will drift. The ideal is a single store of facts, ideally a knowledge graph, that the website, the markup and the MCP server all read from.
The takeaway
A good MCP server is small, clearly described, strictly validated, and fed from the same facts as everything else you publish. Start from the questions people ask, expose only what answers them, and make the tool descriptions good enough that a model gets them right without trial and error.