MCP for scientific data: what a good bio server looks like

The protocol itself is not complicated. Servers offer three things: resources (context and data), prompts (templated workflows), and tools (functions the model can execute). The current specification is dated 25 November 2025.

What makes biology a hard case is not volume. It is that a wrong answer is often indistinguishable from a right one. If a sequence retrieval returns 15 records when the correct count is 266, nothing about the response looks broken. The agent proceeds, the phylogeny gets built, and the error surfaces downstream as a date that is off by ninety years. We wrote about that failure class in more detail in identifier hell and ontology mapping.

This is why the useful design question is not “how do I expose my API to a model.” It is “how do I make it impossible for the model to be confidently wrong about what it just received.” Everything below follows from that.

The field agrees this matters. Julio Saez-Rodriguez of EMBL-EBI framed the appeal directly in December 2025: letting models query trusted sources such as EMBL-EBI databases reduces hallucination and makes answers more reproducible. The open problems he names are security and sustainability of hosted servers, and community agreement on metadata standards.

These are ordered roughly by how often we see them missed. The first two are about discovery, the middle four about honesty in the response, and the last two about restraint.

Expand

Most of the value sits in the rules about what the server tells you, not what it fetches.

Scope it, and say what you exclude

The best single paragraph in any bio MCP server we use is the one in the PubMed server that says, in effect: this indexes biomedical and life sciences literature, it does not contain physics, mathematics or computer science, use arXiv for those. That paragraph costs nothing and prevents a whole category of empty searches, because the agent stops before it starts.

Scope statements are also how you avoid being the wrong tool in a crowded client. An agent with ten servers connected picks by reading descriptions. Make yours easy to rule out.

Name tools after questions

A tool called search_by_eligibility or analyze_endpoints tells an agent what it is for. One called query_v2 does not, and the agent will guess. This sounds trivial and is the single highest-leverage naming decision you will make, because tool selection happens before any documentation gets read.

Return what you did, not just what you found

This is the rule we would put first if we were writing it again. Here is a real example from building this post. Searching PubMed for a paper by exact title returned zero results:

query: "Obstacles to the reuse of study metadata in ClinicalTrials.gov[Title]"
→ 0 results

The paper exists. What saved the search was that the server also returned the query it had actually executed, and the fragment AND to the[Author]made the problem obvious instantly: the phrase had been parsed into field tags, and “to the” had become an author name. Rephrasing found the paper in one call.

Without that echoed query, the only available conclusion was “this paper is not in PubMed,” which was false. Echo the resolved query, the filters applied, the total count, and the database version. It costs a few bytes and it converts silent wrong answers into visible ones.

Keep each call to a few filters

Anthropic’s VirBench work found agent retrieval accuracy degrading noticeably past three or four simultaneous filters (Luebbert, 2026). That is a design constraint, not a model complaint. Prefer several composable tools over one tool with twelve optional parameters, and stage the work: filter first, fetch second. The same work found that a deterministic retrieval layer lifted every tested agent above 90% accuracy and largely collapsed the difference between models, which is the strongest available argument that this layer is worth building carefully.

Version every answer

Stamp the registry release, build, or snapshot date into the response body. Not the README. Reproducibility has to be a property of the payload, because the payload is the only thing that survives into the transcript an agent reasons over three steps later.

Fail loudly and specifically

No matches, malformed query, rate limit, and upstream timeout are four different situations. To a model receiving [] they are one situation. Distinguish them, return the reason, and suggest the next action. A good error is a tool call the agent does not have to waste.

Ship a tool-selection guide

Server-level instructions are cheap and they change how well the whole server gets used. The bio servers we get most value from open with a short guide naming which tool to use first, which to escalate to, and a two-step or three-step workflow for the common question. It reads like documentation and it functions like a policy.

Keep instructions out of the payload

The specification is explicit that descriptions of tool behaviour should be treated as untrusted unless they come from a trusted server. That principle points somewhere uncomfortable: text your server puts in a result is data, and well-behaved clients treat it as data rather than as instructions.

We see servers embed licensing and attribution requirements in every response payload. The underlying need is legitimate; attribution genuinely matters. But repeating a compliance directive inside each result puts it in exactly the channel the specification says is untrusted, where it competes for attention with the user’s actual request. Server instructions and resource metadata are the right home for it. That way a client can surface the requirement once, deliberately, instead of the model re-encountering it on every call.

Almost everything above shows up in the shape of a single tool definition. Here is the difference concretely.

Expand

Both reach the same database. Only one lets an agent notice it asked the wrong question.

You often do not need to build. A useful amount of biology is already reachable over MCP, from academic projects and community efforts. This is our reading of the current landscape rather than an exhaustive registry.

Two patterns in that table are worth stealing outright. Open Targets exposing schema introspection as a tool means the agent can learn the query shape at runtime rather than working from a frozen assumption. And the bioRxiv server stating what it cannot do is the cheapest reliability feature in the whole list.

The direction of travel is clear. MCPmed argues that bioinformatics web servers are built for humans and that this human-centric design limits machine readability for language models and research agents (Flotho et al., 2026). BioinfoMCP makes the complementary point that converting hundreds of tools by hand is unsustainable, and automates it (Widjaja et al., 2025). Both are worth reading before you write a line of your own server.

The rules above are not abstract for us. In a custom build with Gubra, a preclinical biotech serving 15 of the top 20 pharma companies worldwide, we built a service that augments in vivo results with clinical evidence: it extracts measurements from clinical trials, PubMed and a company’s in-house records, scores compound similarity by target and mechanism, and lines an internal compound’s animal effect size up against compounds that reached the clinic to predict a likely outcome. On a retrospective set of 37 drugs across 10 diseases it correctly flagged 84.21% of failures. We expose that pipeline to Hydra as an MCP server, so the whole workflow is callable as a set of typed tools rather than wired in as bespoke code. The full case study has the method and the numbers.

Building it as a server rather than an integration is what made the eight rules above concrete. Three of them did real work here, and they are the three we would defend hardest.

That second row is the honest one. Strict schema resolution throws away real signal along with the noise, and the results show it. A false “this will fail” costs a programme you might have run; a false “this will succeed” costs a Phase 2 or 3. For this use case we take that trade deliberately, and we would rather publish the sensitivity number than bury it.

The general lesson is the one worth carrying into your own build. The interesting decisions in a scientific MCP server are not about transport or framework. They are about what you refuse to return.

• Identifier hell: why ontology mapping is the real bottleneck
• How to validate agentic AI in bioinformatics
• 10 ways to use Claude for scientific work
• Will AI replace bioinformaticians?