Provides tools for querying Crunchbase company and funding data (free tier limited; stub implementation requires real API key).
Click on "Install 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., "@Biomedical APIs MCP Server Search ClinicalTrials.gov for epilepsy trials starting in 2023"
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.
This Model Context Protocol (MCP) server exposes 14 tools to query free biomedical and pharmaceutical APIs—plus stubs for restricted/paid sources—enabling AI agents to access clinical trial data, drug information, molecular structures, adverse events, and research literature.
ClinicalTrials.gov → Search registered clinical trials worldwide
ChEMBL → Small molecules, bioactivity data, drug-like compounds
PubChem → Chemical compounds, molecular properties
OpenFDA → FDA adverse event reports (drug, device, food)
Europe PMC → Biomedical research articles and preprints
dbGaP → NIH genomic & clinical datasets (requires NIH credentials)
PhysioNet → Physiological signals (requires credentialed access)
MIMIC-IV → ICU records (PhysioNet credential + CITI training)
UK Biobank → Large-scale biomedical data (application required)
DrugBank → Structured drug data (academic/commercial license)
BindingDB → Protein-ligand binding affinities (bulk download)
OpenTrials → Merged trial data & sponsors (open access)
Crunchbase → Company & funding data (free tier limited)
Related MCP server: OpenFDA FastMCP Server
npm installCopy .env.example to .env and add optional API keys:
cp .env.example .envEdit .env:
OPENFDA_API_KEY=your_key_here # Optional: increases OpenFDA rate limits
CRUNCHBASE_API_KEY=your_key_here # Optional: enables Crunchbase free tiernpm run buildnpm run devnpm startMCP Inspector lets you test your server interactively:
npx @modelcontextprotocol/inspector node dist/server.jsOnce connected, you can:
List all 14 available tools
Test tool calls with custom inputs
View structured JSON responses
Debug errors and API rate limits
The server is pre-configured in .vscode/mcp.json:
{
"servers": {
"biomed-apis": {
"type": "stdio",
"command": "node",
"args": ["dist/server.js"]
}
}
}To connect:
Open this workspace in VS Code
Restart VS Code (if needed)
Open Copilot Chat and confirm the MCP server is listed
Ask: "Search ClinicalTrials.gov for epilepsy trials started in 2023"
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"biomed-apis": {
"command": "node",
"args": ["C:\\For Me\\Projects\\mcp with DBs\\dist\\server.js"]
}
}
}Restart Claude Desktop. The tools will appear in the MCP panel.
claude mcp add --transport stdio biomed-apis node "C:\\For Me\\Projects\\mcp with DBs\\dist\\server.js"{
"tool": "search_clinical_trials",
"input": {
"query": "epilepsy",
"filter": "AREA[StartDate]2020-01-01+TO+2023-12-31",
"pageSize": 5
}
}Returns: NCT IDs, titles, status, phases, conditions, interventions
{
"tool": "search_chembl_compounds",
"input": {
"query": "aspirin",
"limit": 5
}
}Returns: ChEMBL IDs, molecular formulas, weights, max clinical phase
{
"tool": "get_chembl_activities",
"input": {
"targetChemblId": "CHEMBL2",
"limit": 10
}
}Returns: Activity IDs, assay IDs, molecules, types (IC50, Ki, etc.), values, units
{
"tool": "get_pubchem_compound",
"input": {
"name": "glucose"
}
}Returns: CID, molecular formula, weight, IUPAC name, SMILES
{
"tool": "search_openfda_drug_events",
"input": {
"search": "patient.drug.medicinalproduct:\"metformin\"",
"limit": 10
}
}Returns: Receive dates, patient ages, reactions, drug names
{
"tool": "search_europepmc_articles",
"input": {
"query": "CRISPR gene editing",
"pageSize": 10
}
}Returns: Article IDs, sources, titles, authors, journals, publication years
{
"tool": "query_dbgap",
"input": {
"query": "GWAS cardiovascular disease"
}
}Returns: [dbGaP stub] Querying: "GWAS cardiovascular disease". Access requires NIH credentials & dbGaP approval.
Note: Stubs for dbGaP, PhysioNet, MIMIC-IV, UK Biobank, DrugBank, BindingDB, OpenTrials, and Crunchbase return informational messages. Replace the stub functions in
src/clients/restrictedStubs.tswith real implementations once you have credentials.
mcp-biomed-server/
├── src/
│ ├── server.ts # Main MCP server with all 14 tools
│ └── clients/
│ ├── clinicalTrialsClient.ts # ClinicalTrials.gov
│ ├── chemblClient.ts # ChEMBL
│ ├── pubchemClient.ts # PubChem
│ ├── openfdaClient.ts # OpenFDA
│ ├── europePmcClient.ts # Europe PMC
│ └── restrictedStubs.ts # Stubs for restricted APIs
├── dist/ # Compiled JavaScript (after build)
├── .vscode/
│ └── mcp.json # VS Code MCP config
├── .env.example # Environment variable template
├── package.json
├── tsconfig.json
└── README.mdCreate a client function in src/clients/ (or add to existing file)
Register the tool in src/server.ts:
server.registerTool(
'my_tool_name',
{
title: 'My Tool',
description: 'What it does',
inputSchema: { param: z.string().describe('Parameter description') },
outputSchema: { result: z.string() }
},
async ({ param }) => {
const result = await myClientFunction(param);
return {
content: [{ type: 'text', text: JSON.stringify({ result }) }],
structuredContent: { result }
};
}
);Rebuild: npm run build
Use npm run dev for live TypeScript execution via tsx
Server logs errors to stderr (visible in MCP Inspector or client logs)
Check rate limits if APIs return HTTP 429
API | Rate Limit | Notes |
ClinicalTrials.gov | ~1000 req/day | No key required; public access |
ChEMBL | Unknown (generous) | No key; community-supported |
PubChem | ~5 req/sec | No key; use delays for bulk requests |
OpenFDA | 240 req/min (1000/day without key) | API key increases to 240 req/min |
Europe PMC | Unknown (generous) | No key; rate-limited |
Tips:
Use pageSize/limit parameters to control result counts
Add exponential backoff for HTTP 429 errors
Consider caching responses for repeated queries
MIT (adjust as needed for your project)
Fork the repository
Create a feature branch (git checkout -b feature/new-api)
Add your client in src/clients/
Register tools in src/server.ts
Test with MCP Inspector
Submit a pull request
npm install # Reinstall dependencies
npm run build # Rebuild after changesEnsure .vscode/mcp.json exists
Rebuild: npm run build
Restart VS Code
Check VS Code's MCP output panel for errors
Add delays between requests
Use optional API keys (OpenFDA, Crunchbase)
Reduce pageSize/limit parameters
This is expected! Restricted APIs require credentials
Replace functions in src/clients/restrictedStubs.ts with real implementations
Test all 14 tools with MCP Inspector
Connect to VS Code Copilot and try example queries
Replace stubs with real API implementations (if you have access)
Add rate limiting and caching for production use
Extend with more APIs: BindingDB real download, OpenTrials integration, etc.
Built with 💙 using Model Context Protocol
Retrieve bioactivity data from ChEMBL by target or assay ID
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results | |
| assayChemblId | No | Assay ChEMBL ID | |
| targetChemblId | No | Target ChEMBL ID (e.g., CHEMBL2) |
| Name | Required | Description |
|---|---|---|
| activities | Yes |
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 does not mention read-only nature, rate limits, error handling, or what happens when no results are found. The description is minimal and adds little beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, which is concise and front-loaded with the core action. However, it sacrifices completeness for brevity. It does not contain unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description need not explain return values. However, with 3 optional parameters, the description does not mention that at least one filter (target or assay ID) is likely needed, nor does it explain the default limit. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description adds context by naming 'bioactivity data' but does not elaborate on parameter details (e.g., limit default, requirement for at least one ID). Baseline 3 is appropriate since the schema covers the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and resource 'bioactivity data from ChEMBL', and specifies the two filtering methods (by target or assay ID). It distinguishes from sibling tools like 'search_chembl_compounds' which likely search for compounds, not activities. However, it could be more precise about what 'bioactivity data' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Sibling tools include other database query tools (e.g., query_bindingdb, query_drugbank) that may overlap in functionality, but no exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve compound properties from PubChem by name
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Compound name (e.g., aspirin, glucose) |
| Name | Required | Description |
|---|---|---|
| compounds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
As no annotations are provided, the description carries full burden. It states 'retrieve compound properties', which implies a read-only operation, but provides no additional behavioral details such as authentication, rate limits, error handling (e.g., if compound not found), or whether it returns exact matches only. The description is minimal and adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence—concise but unstructured. It lacks front-loading of key information and uses no visual formatting. Every word is necessary, but the structure is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, no annotations, output schema exists), the description is adequate but not complete. It does not specify whether searches are case-sensitive, if multiple matches are returned, or any limitations. An agent might need additional context for robust usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as the only parameter 'name' has a clear description with examples. The tool description does not add any further semantic meaning beyond what the schema already provides. According to the rubric, with high coverage, baseline is 3, and the description does not exceed that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve', the resource 'compound properties from PubChem', and the method 'by name'. It is specific and understandable, but does not differentiate from sibling tools like 'get_chembl_activities' or 'query_drugbank', which also retrieve compound data from other sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description simply states what it does, leaving the agent without context for choosing among the many similar sibling tools (e.g., search_chembl_compounds, query_drugbank).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
BindingDB measured binding affinities (bulk download available)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | BindingDB query |
| Name | Required | Description |
|---|---|---|
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only mentions bulk download availability but does not disclose other behavioral traits such as rate limits, authentication needs, or the nature of results (e.g., size, format).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure. It is front-loaded with the core purpose, yet every sentence should earn its place; here, the information is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema (not shown), the description should explain what the query returns and how it behaves. It fails to provide enough context for an agent to confidently use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100% with one parameter, but the description adds no meaningful detail beyond the schema's 'BindingDB query'. It does not explain the expected query syntax, format, or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (BindingDB) and the type of data (measured binding affinities), and mentions a key feature (bulk download available). This distinguishes it from sibling tools like query_crunchbase or query_drugbank, though the verb 'query' is implicit from the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or comparisons to other query tools among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crunchbase company & funding data (free tier limited)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Crunchbase query |
| Name | Required | Description |
|---|---|---|
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'free tier limited', hinting at usage constraints, but fails to describe what happens when the limit is reached, authentication needs, or other side effects. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, only one sentence. While front-loaded, it sacrifices detail that would be valuable given the lack of annotations and the presence of an output schema. It is not overly long but could include more useful information without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values do not need explanation. However, the description omits context such as query syntax, rate limits (beyond 'free tier'), or how to interpret results. For a simple tool with one parameter, the missing details leave the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described as 'Crunchbase query'. The description adds no further meaning beyond the schema description. Baseline score of 3 is appropriate as the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for querying Crunchbase company and funding data. The verb 'query' and resource 'Crunchbase' are specific. Sibling tools are other database queries, so this distinguishes itself by its subject matter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the many sibling tools (e.g., query_drugbank, query_mimic). The only hint is 'free tier limited', which implies a limitation but not a use case or alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NIH dbGaP genomic/clinical datasets (requires credentials)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | dbGaP search query |
| Name | Required | Description |
|---|---|---|
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses credential requirement but omits other behavioral traits like read-only/destructive nature, rate limits, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief (one sentence) but lacks depth; it does not earn its place as it provides minimal useful information. Conciseness should not come at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 param, output schema exists), the description is too minimal. It fails to explain authentication process, result format, or how to construct queries, leaving agents underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'query' with a basic description. The tool description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource (NIH dbGaP genomic/clinical datasets) and implies a query action, but does not explicitly say 'search' or 'retrieve'. It lacks differentiation from sibling query tools like query_ukbiobank.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., query_ukbiobank, query_mimic). Only mentions credential requirement, which is a prerequisite but not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DrugBank structured drug data (requires license)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | DrugBank query |
| Name | Required | Description |
|---|---|---|
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden but only mentions license requirement. No disclosure of error behavior, rate limits, or what happens on invalid queries. The stub nature is implied but not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence that front-loads purpose. However, it is too terse and could include more structure without adding excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one param, no annotations, output schema exists), the description could still add prerequisites, expected output shape, or licensing requirements. Currently incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'query' parameter described as 'DrugBank query' in the schema. The description adds no further semantics beyond this, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries DrugBank for structured drug data and notes it requires a license. The name and description distinguish it from sibling tools like get_chembl_activities or query_bindingdb, though it does not specify the type of structured data returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Given multiple sibling drug databases, explicit context for selection is missing. The description merely states 'requires license' without explaining implications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MIMIC-IV ICU records (requires PhysioNet credential)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | MIMIC query |
| Name | Required | Description |
|---|---|---|
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description is the sole source. It only reveals the credential requirement. Other behaviors like read-only nature, error handling, rate limits, or pagination are not disclosed. The output schema exists but description adds no extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence and no wasted words. However, it may be too terse, but conciseness is high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of MIMIC-IV and lack of annotations, the description is incomplete. It misses query syntax, examples, output explanation, and limitations. Even with an output schema, the description should provide more context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter with description). The description adds 'MIMIC query' which is vague and does not clarify format (e.g., SQL, natural language). Baseline 3 as schema covers the parameter, but no additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the target data (MIMIC-IV ICU records) and a prerequisite (PhysioNet credential). The verb 'query' is implied. It distinguishes from sibling tools like query_physionet by specifying the specific database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. While the credential requirement is mentioned, there is no comparison to sibling tools such as query_physionet or query_drugbank.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OpenTrials merged trial data & sponsors (open access)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | OpenTrials query |
| Name | Required | Description |
|---|---|---|
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only notes 'open access'. It fails to mention that the tool is read-only, rate limits, or what happens with empty results. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, but at the cost of clarity. It is effectively a single phrase, which is too brief to be helpful. A good description is concise but still informative; this one is under-specific.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of one required parameter and the presence of an output schema, the description is incomplete. It does not explain the scope of the query, the nature of results, or how it differs from other trial-related tools like search_clinical_trials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the 'query' parameter with description 'OpenTrials query', but the tool description adds no further meaning. No examples, format hints, or constraints are provided, offering no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'OpenTrials merged trial data & sponsors (open access)' is vague about the tool's action; it reads like a description of the data source rather than a tool purpose. The verb 'query' is implied by the name but not stated. It does not distinguish from sibling tools like query_drugbank or query_dbgap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of use cases, prerequisites, or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PhysioNet physiological signal datasets (requires credentials)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | PhysioNet search query |
| Name | Required | Description |
|---|---|---|
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral traits. It only notes the credential requirement, omitting details about side effects, rate limits, or the meaning of 'stub'. The description does not mention the stub nature implied by the title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. Every word contributes to identifying the resource and a key constraint. It is well front-loaded given the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having only one parameter and an output schema, the description lacks context about what the query returns, how results are structured, or any special behaviors. The credential note is helpful but insufficient for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single 'query' parameter, describing it as a 'PhysioNet search query'. The description adds no further semantic detail about query format or usage, so it meets the baseline but does not add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as querying PhysioNet for physiological signal datasets, which distinguishes it from sibling tools for other databases. However, it merely restates the resource type without a specific verb beyond what the name implies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (credentials) but provides no explicit guidance on when to use this tool over alternatives. Usage is implied from the tool name and context, but there are no when-not-to or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UK Biobank large-scale biomedical data (requires application)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | UK Biobank query |
| Name | Required | Description |
|---|---|---|
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'requires application,' indicating an access barrier, but fails to disclose other behaviors such as expected response format, rate limits, or whether it supports complex queries. Significant gaps for a tool with zero annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but under-specified. The single sentence does not earn its place as it lacks critical details needed for correct usage. Conciseness is positive but here it sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not provided in input) and likely complex access controls, the description is incomplete. It does not explain what happens after query execution, how to handle access, or any return value semantics. Sibling tools with more detailed descriptions set a higher bar.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (1 parameter fully described). Baseline 3 applies. The description adds no additional meaning beyond the schema field 'UK Biobank query'—no hints on query syntax or required structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it queries UK Biobank large-scale biomedical data, which is the main purpose. However, it is vague about the type of queries (e.g., API, SQL) and does not distinguish from sibling tools similarly querying other databases. The phrase 'requires application' hints at access but does not clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like query_drugbank or search_clinical_trials. The description implies an access requirement but does not specify prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ChEMBL for small molecules by name or SMILES
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results | |
| query | Yes | Molecule name or SMILES string |
| Name | Required | Description |
|---|---|---|
| compounds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the basic function, missing important behavioral traits like authentication needs, rate limits, or behavior when no results found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded. No unnecessary words; every part serves the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return values don't need explanation. However, lacks information on handling multiple matches, pagination, or result interpretation. Adequate for a simple search but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds marginal value by mentioning 'by name or SMILES' which aligns with the query parameter, but does not provide additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Search', resource 'ChEMBL for small molecules', and query types 'by name or SMILES'. It distinguishes from siblings like get_chembl_activities which retrieves activities for a specific compound.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for searching molecules by name or SMILES, but no explicit guidance on when to use this tool vs alternatives like get_pubchem_compound or query_bindingdb. Sibling list shows many data sources without differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ClinicalTrials.gov for registered trials by keyword or advanced filter
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Free-text keyword search | |
| filter | No | Advanced filter (e.g., AREA[StartDate]2020-01-01+TO+2023-12-31) | |
| pageSize | No | Number of results (max 100) |
| Name | Required | Description |
|---|---|---|
| trials | Yes |
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. It only mentions 'search', which implies a read operation, but lacks details on pagination, rate limits, result limits, or whether it supports sorting. The presence of an output schema helps but is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. It is concise but could benefit from slightly more structure to separate the two search methods. Still, it is appropriately sized for a simple search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (3 optional params, no required, 100% schema coverage, output schema exists), the description is minimally complete. However, it misses behavioral context like pagination and result limits that would help an agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add extra meaning beyond what the schema already provides—it merely restates that search is by keyword or filter. No additional parameter constraints or usage hints are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'Search' and the specific resource 'ClinicalTrials.gov for registered trials'. It also mentions two modes: keyword or advanced filter. This explicitly distinguishes it from sibling tools that query other databases like ChemBL, PubChem, or DrugBank.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for searching clinical trials, but does not explicitly state when to use this tool over alternatives. No 'when-not' or specific context is provided, leaving the agent to infer based on the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Europe PMC for biomedical literature by keyword
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g., "cancer immunotherapy") | |
| pageSize | No | Number of results |
| Name | Required | Description |
|---|---|---|
| articles | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It implies a read-only operation by stating 'Search ... by keyword' but gives no details about result format, pagination limits, rate limits, or any side effects. The pageSize parameter hints at pagination, but that's from the schema, not the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, incomplete sentence that is front-loaded with the key action and resource. It is efficient but could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description need not explain return values. However, with many sibling tools, the lack of usage guidance and missing advanced query syntax details (e.g., boolean operators) leave it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description is not under pressure. The description mentions 'by keyword', aligning with the query parameter, but adds no additional meaning over the schema. The pageSize parameter is not described, but its schema includes a default and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search'), the resource ('Europe PMC'), and the content type ('biomedical literature'). It distinguishes the tool by name but lacks explicit differentiation from sibling tools like search_clinical_trials or search_chembl_compounds, which also search biomedical databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use Europe PMC over alternative databases (e.g., for clinical trials or compound data). There are no prerequisites, context, or exclusions mentioned, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FDA adverse event reports by drug name or other criteria
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results | |
| search | No | Search query (e.g., patient.drug.medicinalproduct:"aspirin") |
| Name | Required | Description |
|---|---|---|
| events | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should fully disclose behavioral traits. It only states the basic function, omitting details like rate limits, data source (openFDA), query syntax expectations, or pagination behavior. This is insufficient for a tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the core purpose. It is front-loaded and wastes no words, though it could benefit from slight expansion for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with two parameters and an output schema, the description is minimally adequate. It lacks context about the query syntax, API sources, and result limitations, but the presence of an output schema reduces the burden for return value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters having descriptions. The tool description adds little beyond the schema (e.g., 'by drug name' hints at search usage). Baseline 3 is appropriate; the description does not significantly enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Search', the resource 'FDA adverse event reports', and the criteria 'by drug name or other criteria'. It clearly differentiates from siblings like search_clinical_trials or search_chembl_compounds by specifying the exact data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching adverse events, but provides no explicit guidance on when to use this tool versus alternatives (e.g., for clinical trials use search_clinical_trials). No when-not or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_chembl_activitiesget_pubchem_compoundquery_bindingdbquery_crunchbasequery_dbgapquery_drugbankquery_mimicquery_opentrialsquery_physionetquery_ukbiobanksearch_chembl_compoundssearch_clinical_trialssearch_europepmc_articlessearch_openfda_drug_eventsScored across 14 tools
Each tool targets a distinct biomedical database or data type, with descriptions clearly differentiating their sources and functions. There is no overlapping purpose among the 14 tools.
Tool names follow a consistent verb_noun pattern: 'get_' for direct retrieval, 'query_' for credentialed databases, and 'search_' for keyword queries. The prefixes are used consistently across the set.
With 14 tools covering diverse biomedical data sources (compounds, activities, trials, literature, adverse events, clinical datasets), the count is well-scoped for the server's purpose without being excessive or thin.
The tool set covers major biomedical data domains, including compounds, bioactivities, trials, literature, and clinical datasets. Minor gaps exist (e.g., protein data, gene expression), but core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI clients to biomedical data and tools.
US healthcare data for AI agents: CMS, FDA adverse events, CDC, NPPES NPI. Keyless, real samples.
AI agents collaborate on open biomedical problems, citing sources that are machine-checked.
Supplement safety for AI agents. 1,500+ rules, NIH+FDA data, quality grading A-D.
