BioMCP: One Rust Binary and One Command Grammar Over Thirty Biomedical Sources
BioMCP: Biomedical Model Context Protocol
At a glance
- What is it?
- BioMCP wraps PubMed, ClinVar, ClinicalTrials.gov and roughly thirty other biomedical sources behind a single CLI grammar that doubles as an MCP server for coding agents. The install and query path is short; the interesting part is the grammar and the skill playbooks, not the source count.
- Who is it for?
- Adopt BioMCP if you already query PubMed, ClinVar or ClinicalTrials.gov by hand and want one grammar for all of them, or if you want an MCP server that gives an agent a bounded set of biomedical tools rather than raw HTTP access. Skip it if your work is bulk data retrieval, since the CLI is built around per-entity lookups and batches of at most ten get calls.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem BioMCP addresses: identifier and API churn across biomedical sources
Biomedical lookups fragment across providers that do not share identifiers or query syntax. A gene lives in MyGene.info, UniProt, Reactome, QuickGO, STRING, GTEx, the Human Protein Atlas, DGIdb, ClinGen, NIH Reporter and DisGeNET, and the README's own table lists each of those as a separate upstream behind the single gene entity. A variant is worse: MyVariant.info, ClinVar, gnomAD v4, CIViC, Cancer Genome Interpreter, OncoKB, cBioPortal, GWAS Catalog and AlphaGenome. The README frames the target audience as researchers, clinicians and agents who currently rebuild a workflow for each source. The claim is not that BioMCP holds better data. It holds the same public data and normalizes the access path, so a query written once reaches several providers and comes back deduplicated. The audience is narrow by design: people who already know which sources they trust and want to stop writing per-source glue.
How the grammar maps search, get and pivot onto one binary
The command surface is deliberately small. The README gives the full grammar as: search <entity> [filters] for discovery, skill list for the playbook catalog, discover <query> for concept resolution before entity selection, get <entity> <id> [sections] for focused detail, <entity> <helper> <id> for cross-entity pivots, enrich <GENE1,GENE2,...> for gene-set enrichment, batch <entity> <id1,id2,...> for parallel gets, and search all [slot filters] for counts-first orientation. The README also draws a line between gettable entities and search-only surfaces so that agents do not synthesize unsupported get commands, which is a real design decision: the tool refuses to pretend every provider supports detail retrieval. search article fans out across PubTator3 and Europe PMC, deduplicates PMID, PMCID and DOI identifiers, and can add a Semantic Scholar leg when filters support it. The article helpers (citations, references, recommendations, entities) turn one known paper into a citation graph. study commands are the outlier: they run locally over downloaded cBioPortal-style datasets for query, cohort, survival, compare and co-occurrence, with terminal, SVG and PNG chart output. Everything else is a thin, opinionated layer over live public APIs.
Getting it running: install paths, the health probe and the MCP wiring
The quick-start path is three commands. Install with uv tool install biomcp-cli, then run biomcp health --apis-only to check upstream reachability, then biomcp skill list to see the shipped worked examples. A first real query is biomcp search all --gene BRAF --disease melanoma, followed by biomcp get gene BRAF pathways hpa. There are four other install routes: the shell installer at https://biomcp.org/install.sh, Homebrew via brew tap genomoncology/biomcp and brew install biomcp, the GHCR image ghcr.io/genomoncology/biomcp, and make install from source. One warning is worth repeating verbatim from the README: install biomcp-cli, not biomcp, because the biomcp PyPI package is unrelated to this project. The Homebrew route depends on a separate genomoncology/homebrew-biomcp tap repository existing. For agent use, the MCP config is a stdio server with command biomcp and args ["serve"], registered in Codex with codex mcp add biomcp -- biomcp serve, or in Claude Code through /plugin marketplace add genomoncology/biomcp and /plugin install biomcp@biomcp. Shared deployments use biomcp serve-http --host 127.0.0.1 --port 8080, with clients connecting to http://127.0.0.1:8080/mcp and probe routes at GET /health, GET /readyz and GET /. Skills install into an agent directory with biomcp skill install ~/.claude --force.
Where the design gets uncomfortable: batch limits, API keys and source coverage
Several constraints are visible in the README and they shape what you can build. biomcp batch accepts up to 10 focused get calls in one command, so the tool is not a bulk retrieval engine; anything resembling a cohort-wide download belongs in the local study workflow over cBioPortal-style files, not in batch. Semantic Scholar is described as optional with authentication via S2_API_KEY, meaning that leg of article search silently narrows if the key is absent. The README's source table ends mid-sentence in the supplied material, so the article entity's provider list cannot be confirmed beyond PubMed, PubTator3, Europe PMC, PMC OA, NCBI ID Converter and the optional Semantic Scholar leg. The gettable versus search-only split also means some entities you can search are not entities you can fetch in detail, and an agent that ignores that distinction will emit commands the binary rejects. Finally, every non-study command depends on live upstream APIs, so latency and availability are inherited from providers BioMCP does not control. biomcp health --apis-only exists precisely because that dependency is real.
The alternative: calling each provider directly or writing your own tool layer
The obvious comparison is not another unified biomedical CLI, it is the status quo of hitting each provider's own API or website. That approach gives you the provider's full query surface, including filters BioMCP may not expose, and no intermediate abstraction to debug when a field is missing. The cost is that you maintain identifier reconciliation yourself: mapping a PMID to a PMCID to a DOI, deciding which of MyGene.info or UniProt is authoritative for a gene symbol, and re-learning each API's pagination. BioMCP's answer is the opposite trade: fewer knobs, one grammar, deduplication handled inside search article, and a fixed entity list. If your work is exploratory and cross-source, the grammar saves rework. If your work is deep and single-source, with complex filters or bulk exports, the provider API is the better tool and BioMCP sits in the way. The skill playbooks are the part with no direct equivalent in the status quo: biomcp skill list ships worked examples, and biomcp skill <slug> opens the matching workflow, which is closer to a documented procedure than to an API wrapper.
Maintenance, releases and what the MIT licence leaves you to decide
The project ships frequently. Recent tagged releases are v0.8.25 on 2026-07-08, v0.8.24 on 2026-06-24 and v0.8.23 on 2026-06-11, roughly a two-week cadence across that window, and the last push to main is dated 2026-09-10. That cadence has an operational consequence: pin a version if you deploy the binary or the GHCR image, because the command grammar and entity tables are the interface and they move. The repository is not archived. The licence is MIT, which is permissive; the practical implications for redistribution or bundling are for your own legal review, not something this article can settle. The upstream data sources are the larger maintenance surface. Each provider in the README's tables has its own terms and rate behaviour, and BioMCP's health command is the only built-in way to see whether they are answering. For source builds, the README names make lint, make test and make spec as the standard gates, with make release-gate adding the named full-feature proof. It explicitly states there is no supported make check command, and that make verify is opt-in live public-upstream confidence while make release-live-smoke is a compatibility alias.
What to verify before you depend on it
Run biomcp health --apis-only first and read the failures, not the successes. A provider that is unreachable from your network changes which entities are usable, and the README does not promise a fallback. Then run biomcp list gene and biomcp list variant and compare the output against the entity tables above, because the gettable versus search-only boundary is where agent-generated commands go wrong. If you plan to expose this to an agent, install the skills with biomcp skill install ~/.claude --force and read at least one playbook before writing your own prompts; the shipped examples encode the pivot chains the grammar was designed around. If you deploy the HTTP server rather than stdio, confirm what sits in front of GET /health and GET /readyz, since those routes exist for exactly that purpose. And set S2_API_KEY if you want the Semantic Scholar leg of article search, or accept the narrower result set.
Editorial conclusion
Adopt BioMCP if you already query PubMed, ClinVar or ClinicalTrials.gov by hand and want one grammar for all of them, or if you want an MCP server that gives an agent a bounded set of biomedical tools rather than raw HTTP access. Skip it if your work is bulk data retrieval, since the CLI is built around per-entity lookups and batches of at most ten get calls. Before committing, run biomcp health --apis-only to see which upstreams answer from your network, then biomcp skill list to check whether a shipped playbook matches your workflow; if no skill fits, you are writing the pivot chain yourself.
Community notes