Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@genefoundry search for BRCA1 variant details in gnomAD"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A thin FastMCP 3.x aggregator that federates the GeneFoundry *-link MCP fleet behind a
single Streamable-HTTP endpoint. A host adds one server — genefoundry — and gets every
biomedical backend with collision-free <namespace>_<tool> naming and search-based discovery.
Research use only. Not clinical decision support. Do not use for diagnosis, treatment, triage, or patient management.
An MCP host that mounted all 21 backends directly would face a wall of several hundred tools — more than a model can reason over, and a guarantee of name collisions. The router collapses that into one endpoint and replaces the flat catalog with a search surface, so a model finds the right tool by intent instead of by scrolling.
It is a client to each backend and a server to hosts: it namespaces and shapes the surface, but never rewrites a backend's data. The caller's token is never forwarded upstream.
Related MCP server: BioMCP
The fleet is hosted — no install required:
claude mcp add --transport http genefoundry https://genefoundry.org/mcpHealth check: genefoundry.org/health.
To run your own against the live fleet (Python 3.12+, uv):
uv sync --group dev
cp .env.example .env # set GF_*_URL backend URLs and GF_AUTH_MODE
uv run genefoundry-router run --host 127.0.0.1 --port 8000
curl -s localhost:8000/health | python -m json.toolAn offline fake fleet (make dev-fleet + make run-dev, or one-shot make test-e2e) runs
the real router against impersonated backends over real Streamable-HTTP — no Docker, no
network.
The router does not surface the federated catalog flat. A model sees three things:
Tool | Purpose |
| Relevance search over the entire federated catalog |
| Invoke a hit by its |
pinned entry points | Each backend's front-door tool, always visible — declared per-backend as |
search_tools(query="splicing prediction") # → spliceai_predict_splicing (+ schema)
call_tool(name="spliceai_predict_splicing", arguments={...})Pinning makes each domain's canonical tool reachable deterministically rather than by relevance luck. See How discovery works — including the two traps that bite MCP clients.
22 backends, 285 tools, each surfaced namespaced — e.g. gnomad_search_genes.
Namespace | Domain | Data source | Tools | Repo |
| Literature & entity annotation | 35 | ||
| Variant / gene / population frequency | 22 | ||
| Rare disease ontology & associations | 19 | ||
| Gene–disease curation | 17 | ||
| Phenotype ontology & associations | 17 | ||
| Variant-effect assay scores | 15 | ||
| Protein function | 15 | ||
| Pharmacogenomics / gene-drug guidelines | 13 | ||
| Gene–disease literature | 13 | ||
| Mouse phenotype & models | 13 | ||
| Disease ontology / cross-references | 13 | ||
| Gene–disease curation | 12 | ||
| Protein tolerance landscapes | 11 | ||
| Protein–protein interaction networks | 10 | ||
| Tissue expression | 9 | ||
| Gene nomenclature | 9 | ||
| Diagnostic gene panels & curation | 9 | ||
| Variant ACMG PVS1 | 7 | ||
| Splicing prediction | 7 | ||
| Variant annotation / consequence | 7 | ||
| Variant clinical significance | 6 | ||
| Variant literature | 6 |
The router serves no data of its own; each backend owns its sources, licences and citation guidance, and the router mirrors their disclaimers.
What it does own is integrity of the tool surface. A backend can serve a clean tool at
review time and later change its definition — the channel for a rug pull. The router
fingerprints every normalized tool definition and diffs the live fleet against a reviewed,
packaged baseline (genefoundry_router/data/fleet-baseline.json), enforced at startup and
on a schedule. See Deployment → drift detection.
Configuration & authentication — every GF_* variable, the OAuth/JWT resource-server modes, and the startup guards.
Deployment — container release, digest pinning, rollback, and drift detection.
How discovery works — the search surface, entry-point pinning, and how discoverability is measured.
Design spec — the architecture and why it is shaped this way.
Fleet standards — Tool-Naming · Response-Envelope · MCP-Behaviour · Tool-Surface-Budget · Tool-Schema-Documentation · Container-Hardening · Versioning · README.
See AGENTS.md for engineering conventions. make ci-local is the
definition-of-done gate: format, lint, line budget, README standard, mypy, and tests.
MIT © Bernt Popp. Each federated backend carries the licence and citation terms of its upstream data source; see that backend's repository.
This server cannot be deployed
Auditable MCP server for PubMed, Europe PMC, ClinicalTrials.gov, and bioRxiv/medRxiv queries
Unified gateway exposing 150+ tools across all NexGenData MCP servers via one endpoint.
Bioinformatics MCP for genomic variant interpretation, gene-disease evidence and literature.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.