Being able to run the same association query from the target end or the disease end is what makes this useful in a conversation — "what else is BRCA1 implicated in" and "what should we look at for this disease" are the same call with a different argument. Unofficial, and a thin GraphQL wrapper, but the identifier handling saves the step that usually breaks this workflow.
An unofficial MCP server over the Open Targets platform, the resource that scores how strongly a gene is associated with a disease by integrating evidence from many sources. It handles the identifier translation that makes this awkward by hand: you search by a gene symbol or a disease name, and it gives you the Ensembl and EFO identifiers the association queries need.
- Therapeutic targets searched by gene symbol, name or description — `search_targets`
- Diseases searched by name, synonym or description — `search_diseases`
- Target-disease associations with evidence scores, queried from either end — pass a `targetId` to see a gene's diseases, or a `diseaseId` to see a disease's genes — `get_target_disease_associations`
- A disease's prioritised therapeutic targets as a ranked summary — `get_disease_targets_summary`
- Full records for one target or one disease — `get_target_details`, `get_disease_details`
- Resource templates for direct addressing: `opentargets://target/{ensemblId}`, `opentargets://disease/{efoId}`, `opentargets://drug/{chemblId}`, `opentargets://association/{targetId}/{diseaseId}`, `opentargets://search/{query}`
No account and no key — the Open Targets GraphQL API at `https://api.platform.opentargets.org/api/v4/graphql` needs no authentication. Build it yourself with `npm install` and `npm run build`, then point your client at `build/index.js`. Identifiers follow the platform's conventions: Ensembl gene IDs for targets, EFO IDs for diseases, ChEMBL IDs for drugs. Calls carry a 30s timeout.