Biomedical compound and drug intelligence — PubChem compound data (formula, SMILES, structure), OpenFDA drug labels & adverse events, and ChEMBL bioactivity & target data. Built for pharma research and biotech agents.
Scored across 3 tools
Each tool queries a distinct public database (PubChem, OpenFDA, ChEMBL) and returns clearly non-overlapping data types: chemical properties, label/safety info, and target/bioactivity. Despite the shared drug/compound domain, the descriptions leave no ambiguity about which tool to use.
All tool names follow the exact pattern 'get_' + descriptive noun phrase (compound_data, drug_info, drug_targets), making the naming scheme highly predictable and consistent.
With only three tools, the server is minimal yet well-scoped for its purpose of retrieving drug/compound information from multiple sources. Each tool adds a distinct value and the count is within the ideal range for a focused server.
The server covers three major aspects of drug information: chemical identifiers, regulatory/safety data, and target/bioactivity. However, there is no search/discovery tool to locate drugs by query, and additional areas like clinical trials or pricing are missing. Still, the core lifecycle of drug data lookup is adequately covered.
Get drug/compound data from PubChem (NIH). Returns CID, IUPAC name, molecular formula, molecular weight, canonical SMILES, InChI, description, and synonyms.
| Name | Required | Description | Default |
|---|---|---|---|
| cid | No | PubChem CID number (alternative to name) | |
| name | No | Drug or compound name (e.g. aspirin, caffeine, ibuprofen) | aspirin |
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 states the data source (PubChem) and the returned fields, but gives no behavioral context such as read-only nature, authentication requirements, rate limits, error conditions, or behavior on invalid input. It lacks caveats that would help the agent understand execution 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 a single sentence that front-loads the action and resource, then lists the return fields in a compact, scannable manner. Every element is informative with no wasted words.
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?
For a tool with 2 simple optional parameters and no output schema, the description covers the key context: data source, return fields, and query inputs via schema. It lacks usage guidance vs. siblings, but otherwise provides sufficient information for invocation and interpretation of results.
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 'cid' and 'name' clearly described in the schema. The description does not add further semantics beyond listing return fields, which indirectly indicates that the parameters are query inputs. Baseline 3 is appropriate since the schema handles parameter documentation.
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 uses a specific verb 'Get' and identifies the resource 'drug/compound data from PubChem (NIH)', then enumerates the return fields (CID, IUPAC name, etc.). This clearly states what the tool does and distinguishes it from sibling tools that target drug info or drug targets.
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 when one needs compound data with the listed fields, but it does not explicitly state when to use this tool over get_drug_info or get_drug_targets, nor does it mention exclusions or alternatives. Guidance is only inferred from the return field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get drug label, safety info, adverse events, or recall data from OpenFDA. Returns brand names, generic name, indications, warnings, dosage, interactions.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Drug name (e.g. metformin, aspirin, lisinopril) | metformin |
| type | No | label (default), adverse_events, or recalls | label |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It lists return fields, but the list appears specific to the default 'label' type and may not apply to adverse_events or recalls, creating an overgeneralization. It also does not mention error behavior, limitations, or that output varies by type.
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?
Two sentences, front-loaded with the primary action and scope, followed by a concise list of return fields. No filler or unnecessary repetition.
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?
The tool is simple with no required parameters and full schema coverage, and the description provides a purpose and return-field list, which is helpful given no output schema. However, it lacks clarity on how return fields vary by type and provides no usage guidance, so it is only 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 baseline is 3. The description adds the OpenFDA context and mentions data categories, but it does not add meaning beyond the schema's parameter descriptions for name and type.
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 gets drug label, safety info, adverse events, or recall data from OpenFDA, which is a specific resource and scope. It does not explicitly differentiate from sibling tools like get_compound_data or get_drug_targets, but the OpenFDA source and data categories provide reasonable clarity.
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 given on when to use this tool versus alternatives. It does not mention when to choose get_drug_info over get_compound_data or get_drug_targets, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get drug target and bioactivity data from ChEMBL (EMBL-EBI). Returns ChEMBL ID, max clinical phase, molecule type, molecular properties, and indication class.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Drug or compound name (e.g. ibuprofen, atorvastatin) | ibuprofen |
| type | No | molecule (default) or activity | molecule |
| chembl_id | No | ChEMBL ID for activity lookup (e.g. CHEMBL521) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses what data is returned (ChEMBL ID, clinical phase, etc.), which is useful. However, with no annotations, it does not disclose potential variations in behavior (e.g., how the 'type' parameter changes results), auth requirements, or whether results are singular or list-based. Moderate transparency for a read-only tool.
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 one concise sentence, front-loads the main action, and includes the most relevant return information. No redundant or filler content.
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 having no output schema and no annotations, the description does not explain how the optional parameters affect the request or what to expect when using 'type=activity'. It lists return fields but leaves important behavioral context (e.g., required vs optional inputs, mode differences) unaddressed. The tool is simple, but the description is incomplete for an agent to use it effectively in all valid configurations.
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 already provides 100% description coverage for all three parameters, so the description adds little beyond the schema. It does not clarify parameter dependencies or how 'type' interacts with 'name'/'chembl_id', but the schema descriptions are adequate, warranting the baseline 3.
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 it gets drug target and bioactivity data from ChEMBL, using a specific verb and resource. It lists return fields, but it does not explicitly distinguish itself from sibling tools like get_compound_data or get_drug_info, so it falls short of a 5.
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. It does not mention scenarios, exclusions, or sibling tool differentiators. The description is purely declarative with no usage context.
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.
get_compound_dataget_drug_infoget_drug_targets
Add one secure layer between your agents and this server.