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.
Add one secure layer between your agents and this server.
Each tool targets a distinct data source and aspect: PubChem for chemical compound data, OpenFDA for regulatory and safety info, and ChEMBL for target and bioactivity data. There is no overlap in their purposes, making selection unambiguous.
All tools follow a consistent get_<object>_<data_type> pattern: get_compound_data, get_drug_info, get_drug_targets. The verb is always 'get' and the uses snake_case throughout, creating a predictable and uniform naming scheme.
With only 3 tools, the server is compact but covers three major drug-related databases. While a few more tools might round out the domain, the current count is reasonable and each tool earns its place.
The server covers chemical data, regulatory/safety information, and target/bioactivity data, providing a solid core for drug information retrieval. It lacks some common operations like search or batch retrieval, but for the stated purpose of getting specific data, the coverage is strong.