Which integrations are available for this server?

Uses GraphQL queries to efficiently retrieve data from the Open Targets platform API Displays API version badges for the Open Targets platform integration

How do I use OpenTargets MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OpenTargets MCP Server search for targets related to breast cancer" 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.

OpenTargets MCP Server

by Augmented-Nature

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Logo

Unofficial Open Targets MCP Server 🧬

Unofficial Model Context Protocol server for accessing Open Targets platform data for gene-drug-disease associations research.

API

Developed by Augmented Nature

✅ Verified Features

All 6 tools working with live Open Targets API data:

🎯 Target Search - Gene symbols, names, descriptions (BRCA1, TP53, etc.)
🦠 Disease Search - Names, synonyms, descriptions (cancer, diabetes, etc.)
🔗 Target-Disease Associations - Evidence scores from 20+ databases
📊 Disease Target Summaries - Prioritized therapeutic targets
🧬 Target Details - Comprehensive gene/protein information
🎭 Disease Details - Complete disease profiles with ontologies

Related MCP server: OpenFDA

🚀 Quick Start

# Install and build
npm install
npm run build

# Run the server
node build/index.js

📋 MCP Client Configuration

Claude Desktop

{
  "mcpServers": {
    "opentargets-server": {
      "command": "node",
      "args": ["/path/to/opentargets-server/build/index.js"]
    }
  }
}

Other MCP Clients

node /path/to/opentargets-server/build/index.js

🛠️ Available Tools

🎯 `search_targets`

Search therapeutic targets by gene symbol, name, or description

{
  "name": "search_targets",
  "arguments": {
    "query": "BRCA1", // Gene symbol, name, or description
    "size": 10 // Optional: 1-500 results (default: 25)
  }
}

Example Results:

BRCA1 (ENSG00000012048) - BRCA1 DNA repair associated
BRCA2 (ENSG00000139618) - BRCA2 DNA repair associated
BRIP1 (ENSG00000136492) - BRCA1 interacting DNA helicase 1

🦠 `search_diseases`

Search diseases by name, synonym, or description

{
  "name": "search_diseases",
  "arguments": {
    "query": "breast cancer", // Disease name, synonym, or description
    "size": 10 // Optional: 1-500 results (default: 25)
  }
}

🔗 `get_target_disease_associations`

Get target-disease associations with evidence scores

{
  "name": "get_target_disease_associations",
  "arguments": {
    "targetId": "ENSG00000012048", // Target Ensembl ID
    "size": 10 // Optional: 1-500 results
  }
}

{
  "name": "get_target_disease_associations",
  "arguments": {
    "diseaseId": "EFO_0000305", // Disease EFO ID
    "size": 10 // Optional: 1-500 results
  }
}

📊 `get_disease_targets_summary`

Get prioritized targets associated with a disease

{
  "name": "get_disease_targets_summary",
  "arguments": {
    "diseaseId": "EFO_0000305", // Disease EFO ID (required)
    "size": 20 // Optional: 1-500 targets (default: 50)
  }
}

🧬 `get_target_details`

Get comprehensive target information

{
  "name": "get_target_details",
  "arguments": {
    "id": "ENSG00000012048" // Target Ensembl gene ID
  }
}

🎭 `get_disease_details`

Get comprehensive disease information

{
  "name": "get_disease_details",
  "arguments": {
    "id": "EFO_0000305" // Disease EFO ID
  }
}

📚 Resource Templates

Access Open Targets data through standardized URIs:

opentargets://target/{ensemblId} - Complete target information
opentargets://disease/{efoId} - Complete disease information
opentargets://drug/{chemblId} - Drug information
opentargets://association/{targetId}/{diseaseId} - Association evidence
opentargets://search/{query} - Search results

🧪 Real-World Examples

Cancer Research Workflow

# 1. Search for cancer-related targets
{"name": "search_targets", "arguments": {"query": "oncogene", "size": 10}}

# 2. Get detailed info for specific target
{"name": "get_target_details", "arguments": {"id": "ENSG00000012048"}}

# 3. Find all diseases associated with BRCA1
{"name": "get_target_disease_associations", "arguments": {"targetId": "ENSG00000012048"}}

# 4. Get top targets for breast cancer
{"name": "get_disease_targets_summary", "arguments": {"diseaseId": "EFO_0000305", "size": 20}}

Drug Discovery Pipeline

# 1. Search for Alzheimer's disease
{"name": "search_diseases", "arguments": {"query": "Alzheimer", "size": 5}}

# 2. Get disease details
{"name": "get_disease_details", "arguments": {"id": "EFO_0000249"}}

# 3. Find prioritized therapeutic targets
{"name": "get_disease_targets_summary", "arguments": {"diseaseId": "EFO_0000249", "size": 30}}

🔬 Data Sources & Standards

Open Targets integrates 20+ databases:

ChEMBL - Drug & compound data
Ensembl - Gene & protein annotations
EFO - Experimental Factor Ontology
ClinVar - Clinical variant data
GWAS Catalog - Genome-wide association studies
UniProt - Protein sequences & functions
Reactome - Biological pathways
And many more...

Standardized Identifiers:

Targets: Ensembl gene IDs (e.g., ENSG00000012048)
Diseases: EFO IDs (e.g., EFO_0000305)
Drugs: ChEMBL IDs (e.g., CHEMBL1234)

🏗️ Architecture

TypeScript implementation with robust type safety
GraphQL queries for efficient data retrieval
MCP Protocol compliant JSON-RPC communication
Error Handling with comprehensive validation
Production Ready with 30s timeouts and proper logging

📊 API Information

Base URL: https://api.platform.opentargets.org/api/v4/graphql
Version: Open Targets v25.0.1
Rate Limits: Generous for research use
Authentication: None required
Format: GraphQL queries, JSON responses

🤝 Contributing

This server is developed and maintained by Augmented Nature. For enhancements:

Fork the repository
Make your changes
Submit a pull request

Support

For issues with:

MCP Server: Check the server logs and error outputs
Open Targets API: Visit platform.opentargets.org
GraphQL Queries: Use the Open Targets GraphQL browser

Citation

If you use this project in your research or publications, please cite it as follows:

author = {Moudather Chelbi},
title = {OpenTargets MCP Server},
year = {2025},
howpublished = {https://github.com/Augmented-Nature/OpenTargets-MCP-Server},
note = {Accessed: 2025-06-29}

Available Tools

6 tools

get_disease_detailsC

Get comprehensive disease information

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Disease EFO ID

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states it 'gets' information, implying a read-only operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what 'comprehensive' entails (e.g., format, depth). This leaves significant gaps for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It is appropriately sized for a simple tool, though it could be more front-loaded with key details like the required EFO ID.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'comprehensive disease information' includes (e.g., fields, structure), nor does it address behavioral aspects like permissions or limitations, leaving the agent with insufficient context for reliable use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with the single parameter 'id' documented as 'Disease EFO ID'. The description adds no additional parameter semantics beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('comprehensive disease information'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'search_diseases' or 'get_disease_targets_summary' beyond the general scope of disease information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an EFO ID), exclusions, or comparisons to siblings like 'search_diseases' for broader queries or 'get_disease_targets_summary' for target-related details.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_disease_targets_summaryC

Get overview of all targets associated with a disease

ParametersJSON Schema

Name	Required	Description
`diseaseId`	Yes	Disease EFO ID
`minScore`	No	Minimum association score (0-1)
`size`	No	Number of targets to return (1-500, default: 50)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't indicate whether this is a read-only operation, what format the 'overview' returns, whether there are rate limits, or authentication requirements. The description doesn't contradict annotations (none exist), but provides inadequate behavioral context for a tool with 3 parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a tool with 3 parameters and gets straight to the point. Every word earns its place in conveying the essential function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what an 'overview' contains versus detailed associations, doesn't mention return format or structure, and provides no context about the data source or limitations. The agent lacks critical information to use this tool effectively despite the good parameter documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all parameters are documented in the input schema. The description adds no additional parameter semantics beyond what's already in the schema - it doesn't explain what 'overview' means in relation to the minScore or size parameters, or provide context about disease EFO IDs. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'overview of all targets associated with a disease', making the purpose immediately understandable. It distinguishes this from sibling tools like get_disease_details or get_target_details by focusing on target-disease associations rather than individual entity details. However, it doesn't specify what constitutes an 'overview' versus the more detailed get_target_disease_associations tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like get_target_disease_associations and search_targets available, there's no indication whether this tool provides summarized data, filtered results, or serves a different purpose. The agent must infer usage from the tool name and parameter set alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_target_detailsC

Get comprehensive target information

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Target Ensembl gene ID

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' information, implying a read-only operation, but doesn't clarify aspects like whether it requires authentication, has rate limits, returns structured data, or handles errors. The description adds minimal behavioral context beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action, making it easy to parse. However, it could be more structured by explicitly mentioning the parameter or differentiating from siblings, but it earns high marks for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a read operation with one parameter) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'comprehensive information' includes, how results are formatted, or error handling, leaving gaps for the agent to navigate without sufficient context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the 'id' parameter documented as 'Target Ensembl gene ID'. The description adds no additional meaning about parameters, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get comprehensive target information' states a clear verb ('Get') and resource ('target information'), but it's vague about what constitutes 'comprehensive' and doesn't distinguish this tool from siblings like 'get_target_disease_associations' or 'search_targets'. It provides a basic purpose but lacks specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no guidance on when to use this tool versus alternatives. Given siblings like 'search_targets' (likely for broader queries) and 'get_target_disease_associations' (for related data), there's no indication that this tool is for detailed information on a specific target by ID, leaving the agent to infer usage from the parameter schema alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_target_disease_associationsC

Get target-disease associations with evidence scores

ParametersJSON Schema

Name	Required	Description
`targetId`	No	Target Ensembl gene ID
`diseaseId`	No	Disease EFO ID
`minScore`	No	Minimum association score (0-1)
`size`	No	Number of results to return (1-500, default: 25)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'evidence scores' but doesn't explain what these scores represent, how they are calculated, or any limitations like rate limits, permissions, or data freshness. For a tool with 4 parameters and no annotations, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's function without any unnecessary words. It is front-loaded with the core action and resource, making it easy to parse and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects like what the evidence scores mean, how results are structured, or any error conditions. This leaves critical gaps for an AI agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each parameter well-documented in the input schema (e.g., 'Target Ensembl gene ID', 'Minimum association score (0-1)'). The description adds no additional meaning beyond the schema, such as explaining relationships between parameters or typical use cases, so it meets the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'target-disease associations with evidence scores', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_disease_targets_summary' or 'search_targets', which might also retrieve similar data, so it misses the top score for sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'get_disease_targets_summary' or 'search_targets'. It lacks any context about prerequisites, such as needing specific IDs, or exclusions, leaving the agent to infer usage based on parameter names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_diseasesC

Search for diseases by name, synonym, or description

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query (disease name, synonym, description)
`size`	No	Number of results to return (1-500, default: 25)
`format`	No	Output format (default: json)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It mentions search functionality but doesn't disclose behavioral traits such as pagination, rate limits, authentication needs, or what the search returns (e.g., list of IDs, full details). This leaves significant gaps for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the search returns (e.g., partial matches, relevance scoring), behavioral aspects, or how it differs from siblings, leaving the agent with insufficient context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters (query, size, format) with details like defaults and constraints. The description adds minimal value by listing search fields (name, synonym, description), but this is largely redundant with the schema's query description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'search' and the resource 'diseases', specifying it can search by name, synonym, or description. However, it doesn't explicitly differentiate from sibling tools like 'search_targets' or 'get_disease_details', which would require a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'search_targets' or 'get_disease_details'. It lacks context about use cases, prerequisites, or exclusions, offering only a basic functional statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_targetsC

Search for therapeutic targets by gene symbol, name, or description

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query (gene symbol, name, description)
`size`	No	Number of results to return (1-500, default: 25)
`format`	No	Output format (default: json)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the search functionality but lacks critical details: whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior, or what the response structure looks like. For a search tool with zero annotation coverage, this is inadequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every element contributing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is insufficient for a search tool with three parameters. It doesn't explain return values, error conditions, or behavioral constraints, leaving significant gaps in understanding how to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema fully documents all three parameters. The description mentions the searchable fields (gene symbol, name, description) which aligns with the 'query' parameter but doesn't add meaningful semantics beyond what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: searching for therapeutic targets using specific search criteria (gene symbol, name, or description). It uses a specific verb ('search') and resource ('therapeutic targets'), but doesn't explicitly differentiate from sibling tools like 'search_diseases' or 'get_target_details', which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'search_diseases' or 'get_target_details'. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based solely on the tool name and parameters.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesAug 15, 2025
- First observedget_disease_details
- First observedget_disease_targets_summary
- First observedget_target_details
- First observedget_target_disease_associations
- First observedsearch_diseases
- First observedsearch_targets

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: two are for retrieving details (disease and target), two for retrieving associations/summaries (target-disease and disease-targets), and two for searching (diseases and targets). There is no overlap in functionality, making it easy for an agent to select the right tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with 'get_' or 'search_' prefixes, followed by descriptive nouns (e.g., get_disease_details, search_targets). The naming is uniform and predictable across all six tools.

Tool Count5/5

With 6 tools, this server is well-scoped for its purpose of querying disease and target data in the OpenTargets domain. Each tool serves a specific, non-redundant function, and the count is appropriate for covering core operations without being overwhelming.

Completeness4/5

The tool set provides comprehensive coverage for querying and retrieving disease and target information, including details, associations, and search capabilities. A minor gap is the lack of update or creation tools, but this is reasonable for a read-only data query server focused on biomedical research.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Opentargets A
io.github.pipeworx-io
Open Targets MCP — disease/target/drug knowledge graph.
Biology & Medicine Knowledge & Memory
382
Studex MCP ServerOAuth
io.github.itshivams
Model Context Protocol server for Studex tools, notifications, and profile integrations
Developer Tools
1
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Gnomad B
io.github.pipeworx-io
Broad Institute gnomAD genomic variant database (GraphQL)
Bioinformatics Biology & Medicine
362

Related MCP Servers

Reactome MCP Server
Biology & Medicine Research & Data
Augmented-Nature
F
license
A
quality
D
maintenance
Model Context Protocol server for accessing Reactome pathway and systems biology data.
Updated 9 months ago (2025-12-21 10:08 UTC)
8
12
-
OpenFDA
Search Research & Data Biology & Medicine
ythalorossy
A
license
A
quality
D
maintenance
A Model Context Protocol (MCP) server for querying drug information from the OpenFDA API. Features Retrieve drug label information by brand name Retrieve drug information by generic (active ingredient) name Get all brand versions of a generic drug Get adverse event (side effect) reports for a drug
Updated 5 months ago (2026-04-06 17:40 UTC)
7
37
4
MIT
biothings-mcp
Bioinformatics Biology & Medicine
longevity-genie
A
license
A
quality
F
maintenance
Provides a Model Context Protocol server for accessing and querying biomedical data from BioThings services, including gene, variant, chemical, and taxon annotations.
Updated 10 months ago (2025-11-03 20:05 UTC)
19
34
MIT
mcp-omics
Bioinformatics Biology & Medicine Research & Data
colbyford
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables retrieval of -omics data from sources like PDB, ChEMBL, UniProt, PubChem, and HUGO.
Updated a year ago (2025-07-13 01:22 UTC)
5
GPL 3.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Augmented-Nature/OpenTargets-MCP-Server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Unofficial Open Targets MCP Server 🧬

✅ Verified Features

🚀 Quick Start

📋 MCP Client Configuration

Claude Desktop

Other MCP Clients

🛠️ Available Tools

🎯 search_targets

🦠 search_diseases

🔗 get_target_disease_associations

📊 get_disease_targets_summary

🧬 get_target_details

🎭 get_disease_details

📚 Resource Templates

🧪 Real-World Examples

Cancer Research Workflow

Drug Discovery Pipeline

🔬 Data Sources & Standards

🏗️ Architecture

📊 API Information

🤝 Contributing

Support

Citation

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

🎯 `search_targets`

🦠 `search_diseases`

🔗 `get_target_disease_associations`

📊 `get_disease_targets_summary`

🧬 `get_target_details`

🎭 `get_disease_details`