Seven rules for MCP tools that an AI assistant cannot misread
An MCP server is an API whose reader is a language model. The model reads your tool list, picks a tool, and repeats what comes back to a person. It does not read your docs, it does not ask follow-up questions, and it fills every gap with a guess. We built the MCP server for supp.fit, a database of

An MCP server is an API whose reader is a language model. The model reads your tool list, picks a tool, and repeats what comes back to a person. It does not read your docs, it does not ask follow-up questions, and it fills every gap with a guess.
We built the MCP server for supp.fit, a database of supplement evidence from randomized controlled trials. The data is easy to misread in ways that matter: doses in different units, labels that could not be matched, intake logs with missing days. Here are the rules we ended up with. They hold for any MCP server, not only for health data.
Our API has more than forty endpoints. The MCP server exposes thirteen tools.
A model chooses a tool from its name and its description. When two tools differ by one word, it picks one at random. So we merged endpoints into tools that each answer one kind of question: search a supplement, get one supplement, get its study protocols, get the studies behind one benefit, get one study, search products, get one product, and six tools for the person's own data.
Rule: one tool per question a user asks, not one tool per route.
Two of our fields can be empty for opposite reasons.
In the data, both look like "nothing". A model will happily say "this product contains nothing" or "you skipped 12 days". So the tool description says it in words:
When has_confirmed_label is false there is no panel, and that means the match could not be confirmed. It does NOT mean the product has no ingredients. Never tell a reader a product contains nothing. Enter fullscreen mode Exit fullscreen mode Rule: for every field that can be empty, write one sentence that says what the emptiness means.
Dose data comes in IU, mg, capsules and millilitres. A model sees numbers and adds them. It also converts IU into milligrams with a guess.
Our descriptions say: each amount keeps its own unit; do not add amounts across units or items; do not convert IU into a mass. The consumption tool returns figures grouped per item and per unit, so there is nothing safe to add.
Rule: if a sum or a conversion would be wrong, say so in the description and shape the response so that the wrong sum is hard to make.
Study groups took a daily dose. Product labels print a dose per serving. Neither is a recommendation.
The tool returns both, with the median, the middle half and the most common band, and the description calls them "printed and studied amounts, not a recommended dose". The model can now answer "what did the trials use?" without turning it into advice.
Rule: name the source of every number in the field name and in the description.
Every tool is read-only, and the server has no write path to the database. The server keeps no secret of its own either. It passes on the token the client was issued, and the API decides what that token may read.
This is a security property, but it also helps the model. With no write tools in the list, it never offers to "add this to your stack".
Rule: if a server cannot change anything, it should not list a tool that sounds as if it can.
Every tool needs a signed-in account, even the ones that read public evidence. The reason: an assistant mixes both halves in one answer ("what do the studies say, and what am I taking?"). One rule for every tool can be tested. A rule per tool is something someone forgets.
Rule: scope by owner of the data, and keep one auth rule for all tools.
Full paper text is licensed, so no tool returns it. The study tool returns the title, year, participant count, our summary and the PubMed link. The model can name the paper and the reader can check it.
Rule: give the model enough to cite, and a link for the person to verify.
The server speaks Streamable HTTP and is stateless: no session id, no event stream. A client needs only the endpoint and follows the OAuth 2.1 sign-in:
{ "mcpServers": { "supp-fit": { "type": "http", "url": "https://mcp.supp.fit/mcp" } } } Enter fullscreen mode Exit fullscreen mode Summary Rule Why Fewer tools than endpoints The model picks by name and description Say what absence means Empty fields get read as "none" Forbid wrong arithmetic Models add numbers across units Name the source of every number Studied amounts are not advice Read-only, and say it No tool that sounds like a write Scope by owner of the data Share evidence without personal data Summary plus link Cite without copying licensed text The server and its full tool list are described at mcp.supp.fit. The evidence it reads is the same as on supp.fit.
For information only, not medical advice.