Search PubChem compounds, properties, safety data, bioactivity, and cross-references.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 10 of 10 tools scored. Lowest: 3.7/5.
Each tool targets a distinct aspect of PubChem: compound details, structures, images, interactions, safety, bioactivity, cross-references, summaries, assay search, and compound search. No two tools overlap in purpose, making confusion unlikely.
All tools follow a consistent verb_noun pattern with a 'pubchem_' prefix: either 'pubchem_get_...' or 'pubchem_search_...'. This uniform naming makes the toolset predictable and easy to navigate.
With 10 tools, the server covers the core functionality for querying PubChem (compounds, assays, bioactivity, safety, etc.) without being overwhelming. The count is well-suited for a chemical database interface.
The toolset covers the essential operations for interacting with PubChem: searching compounds and assays, retrieving detailed information, structures, images, bioactivity, interactions, safety data, cross-references, and summaries. No obvious gaps for typical use cases.
pubchem_get_bioactivityGet BioactivityAGet a compound's bioactivity profile: which assays tested it, activity outcomes (Active/Inactive/Inconclusive), target identifiers (NCBI Gene ID, UniProt/GenBank accession), and quantitative values (IC50, EC50, Ki, etc.). Filter by outcome and/or a specific molecular target (NCBI Gene ID or protein accession) to focus the profile — e.g. "is this compound active against target T?".
| Name | Required | Description | Default |
|---|---|---|---|
| cid | Yes | PubChem Compound ID. Resolve from name/SMILES with pubchem_search_compounds. | |
| offset | No | Zero-based index of the first assay to return, applied after the outcome and target filters. Pass the nextOffset from a previous call to read the following page. Default: 0. | |
| maxResults | No | Max assay results to return per page (1-100). Well-studied compounds have thousands of records; use offset to reach the ones past this page. Default: 20. | |
| targetGeneId | No | Filter to assays against this NCBI Gene ID. Obtain Gene IDs from pubchem_search_assays or the targetGeneId field of an unfiltered result here. Combine with outcomeFilter="active" to answer "is this compound active against target T?". | |
| outcomeFilter | No | Filter by activity outcome. "active" shows only assays where the compound showed activity — most useful for understanding biological profile. Default: "all". | all |
| targetAccession | No | Filter to assays against this target protein accession (UniProt/GenBank), e.g. "P35354". Obtain accessions from pubchem_search_assays or the targetAccession field of an unfiltered result here. |
| Name | Required | Description |
|---|---|---|
| cap | No | The maxResults cap that was applied. |
| cid | Yes | PubChem Compound ID. |
| shown | No | Assays returned on this page. |
| notice | No | Recovery guidance when the filter yields no results or the compound has no bioactivity data. |
| offset | Yes | Zero-based index of the first assay returned. |
| results | Yes | Assay results matching the filter. |
| truncated | No | True when matching assays remain past this page. |
| nextOffset | No | Offset to pass on the next call to continue past this page. Omitted when no further assays match. |
| activeCount | Yes | Assays with "Active" outcome. |
| totalAssays | Yes | Total unique assays for this compound. |
| targetFilter | No | Target filter applied (gene ID and/or protein accession), when set. |
| filteredCount | Yes | Exact number of assays matching the outcome and target filters, across all pages. |
| inactiveCount | Yes | Assays with "Inactive" outcome. |
| outcomeFilter | Yes | Outcome filter applied: active, inactive, or all. |
| returnedCount | Yes | Assays returned on this page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds meaningful behavioral context by explaining the shape of results (active/inactive/inconclusive outcomes, target identifiers, quantitative values) and the ability to filter by outcome or target, enriching what the agent can expect beyond the structured 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?
The description is two sentences long, front-loaded with the primary purpose, then efficiently details the output scope and filtering use case. No filler or redundant repetition of schema information.
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 description covers the tool's purpose, output contents, and filtering example in a compact way. With an output schema present, it does not need to enumerate return structures; the combination of description, schema annotations, and output schema provides a complete picture for selecting and invoking 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?
Schema description coverage is 100%, so the input schema already fully documents all six parameters, including defaults, ranges, and how offset/maxResults page through results. The tool description reinforces the filter semantics ('Filter by outcome and/or a specific molecular target') but does not add syntax or format details beyond what the schema provides, so baseline 3 is appropriate.
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 opens with 'Get a compound's bioactivity profile' — a specific verb+resource that immediately identifies the tool's function. It enumerates what the profile contains (assays, activity outcomes, target identifiers, quantitative values) and the filtering options, which clearly distinguishes it from sibling tools like get_compound_details or get_compound_interactions.
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 gives clear context for when to use the tool — to retrieve bioactivity data and answer target-activity questions, illustrated by the example 'is this compound active against target T?'. It does not explicitly name alternatives or state when-not-to-use scenarios, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubchem_get_compound_3d_structureGet Compound 3D StructureAGet a compound's default 3D conformer — atomic coordinates and bonds — for one CID. format="json" (default) returns atoms and bonds parsed into structured fields; format="sdf" returns the raw V2000 SDF text for passthrough to docking, rendering, or conformer tools. Optionally lists alternate conformer IDs. Not every compound has computed 3D coordinates (large molecules, mixtures, and some salts do not).
| Name | Required | Description | Default |
|---|---|---|---|
| cid | Yes | PubChem Compound ID. Resolve from name/SMILES with pubchem_search_compounds. | |
| format | No | Output format. "json" (default) returns parsed atoms and bonds. "sdf" returns the raw V2000 SDF text for passthrough to other tools. | json |
| maxAtoms | No | Cap the atoms returned in the format="json" preview. atomCount always reports the full total; omitted rows are disclosed via the truncated/shownAtoms enrichment. Defaults to the first 200 atoms. | |
| maxBonds | No | Cap the bonds returned in the format="json" preview. bondCount always reports the full total; omitted rows are disclosed via the truncated/shownBonds enrichment. Defaults to the first 200 bonds. | |
| includeRawSdf | No | For format="sdf", return the complete raw V2000 SDF even when it exceeds the safe line cap. Default false: an SDF longer than 500 lines is line-capped with disclosure. No effect when format="json". | |
| includeAlternateConformerIds | No | List the IDs of additional computed conformers beyond the default. Slower than the default response. Default: false. |
| Name | Required | Description |
|---|---|---|
| cid | Yes | PubChem Compound ID. |
| sdf | No | Raw V2000 SDF text. Populated when format="sdf". |
| atoms | No | Parsed atoms. Populated when format="json". |
| bonds | No | Parsed bonds. Populated when format="json". |
| notice | No | Guidance naming which lists were capped and how to widen them. |
| atomCap | No | The atom cap applied (explicit maxAtoms or the safe default), when the atom list was capped. |
| bondCap | No | The bond cap applied (explicit maxBonds or the safe default), when the bond list was capped. |
| atomCount | Yes | Number of atoms in the conformer. |
| bondCount | Yes | Number of bonds in the conformer. |
| truncated | No | True when the atom list, bond list, or raw SDF was capped below its total. atomCount/bondCount always report the full totals. |
| shownAtoms | No | Atoms returned after the cap, when fewer than atomCount. Raise maxAtoms for more. |
| shownBonds | No | Bonds returned after the cap, when fewer than bondCount. Raise maxBonds for more. |
| conformerId | No | Default (primary) conformer ID. Present when includeAlternateConformerIds is set. |
| shownSdfLines | No | SDF lines returned when format="sdf" and the raw text was line-capped. Set includeRawSdf for the full record. |
| alternateConformerIds | No | Conformer IDs beyond the default. Present when includeAlternateConformerIds is set and alternates exist. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description discloses format-specific behavior (json vs sdf), the optional listing of alternate conformer IDs, and the limitation that some compounds lack 3D coordinates. This adds valuable context without contradicting 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?
The description is concise and front-loaded: the purpose sentence identifies the tool, followed by format specifics, optional feature, and a caveat in four clear sentences. Every sentence adds value with no redundancy.
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 complexity (6 parameters, output schema), the description covers the core purpose, format alternatives, and a key limitation (missing 3D coordinates for some compounds). It relies on the schema for parameter-level details, which is reasonable. Slightly more context about truncation or raw SDF behavior could improve it, but it is already quite 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?
The input schema already documents all six parameters with detailed descriptions (100% coverage), so the description bears little burden. It does mention the format values and alternate conformer IDs, but adds no new technical parameter details beyond what the schema provides. Baseline 3 is appropriate.
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 opens with a specific verb and resource: 'Get a compound's default 3D conformer — atomic coordinates and bonds — for one CID.' This clearly distinguishes it from sibling tools (e.g., details, image, safety) by focusing on 3D structural data for a single 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?
The description provides clear context on when to use the tool: for retrieving a compound's 3D structure, with format options for docking/rendering tools. It also notes that not every compound has computed 3D coordinates, setting expectations. However, it does not explicitly name alternative tools for different use cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubchem_get_compound_detailsGet Compound DetailsAGet detailed compound information by CID. Returns physicochemical properties (molecular weight, SMILES, InChIKey, XLogP, TPSA, etc.), optionally with a textual description (pharmacology, mechanism, therapeutic use), known synonyms, drug-likeness assessment (Lipinski/Veber rules), and/or pharmacological classification (FDA classes, MeSH classes, ATC codes). Accepts up to 100 CIDs per call.
| Name | Required | Description | Default |
|---|---|---|---|
| cids | Yes | PubChem Compound IDs to fetch (1-100). Resolve from names/SMILES with pubchem_search_compounds. | |
| properties | No | Properties to retrieve. Defaults to a core set: MolecularFormula, MolecularWeight, IUPACName, CanonicalSMILES, IsomericSMILES, InChIKey, XLogP, TPSA, HBondDonorCount, HBondAcceptorCount, RotatableBondCount, HeavyAtomCount, Charge, Complexity. | |
| maxSynonyms | No | Max synonyms returned per compound per page (1-100). PubChem lists hundreds for common drugs; use synonymOffset to reach the ones past this page. Default: 20. | |
| synonymOffset | No | Zero-based index of the first synonym to return within each compound's synonym list. The same offset is applied to every compound in the batch. Pass the nextSynonymOffset from a previous call to read the following page. Default: 0. | |
| includeSynonyms | No | Fetch known names and synonyms (trade names, systematic names, registry numbers), paged via synonymOffset/maxSynonyms. Fetched for every found CID in the batch. Slower for large CID lists. | |
| maxDescriptions | No | Max number of distinct description entries per compound per page (1-20). PubChem returns near-duplicate summaries from many depositors; duplicates are collapsed before this cap applies. Default: 3. | |
| descriptionOffset | No | Zero-based index of the first description to return within each compound's description list. The same offset is applied to every compound in the batch. Pass the nextDescriptionOffset from a previous call to read the following page. Default: 0. | |
| includeDescription | No | Include textual descriptions (pharmacology, mechanism, therapeutic use) attributed by source. Well-studied compounds have many overlapping summaries — paged via descriptionOffset/maxDescriptions. Fetched only for the first 10 CIDs in the batch; remaining CIDs return without descriptions and are listed in the response's skippedCids. | |
| includeDrugLikeness | No | Compute drug-likeness assessment: Lipinski Rule of Five (MW, XLogP, HBD, HBA) and Veber rules (TPSA, rotatable bonds). Computed from the returned properties, so it adds no latency. | |
| includeClassification | No | Include pharmacological classification: FDA Established Pharmacologic Classes, mechanisms of action, MeSH classes, and ATC codes. Fetched only for the first 10 CIDs in the batch; remaining CIDs return without classification and are listed in the response's skippedCids. |
| Name | Required | Description |
|---|---|---|
| notice | No | Recovery guidance covering the skipped CIDs, an offset that runs past every compound, and pages that remain. Absent when nothing was skipped or truncated. |
| compounds | Yes | Compound detail records. |
| skippedCids | No | CIDs found in PubChem whose descriptions and classification were NOT fetched because the batch exceeded the per-call fan-out limit. Their absence from a record means "not requested", not "PubChem has none" — re-request these CIDs in a follow-up call. Present only when CIDs were skipped. |
| enrichedCids | No | CIDs whose descriptions and classification were fetched. Present only when the batch exceeded the per-call fan-out limit and other CIDs were skipped. |
| synonymOffset | No | Zero-based index of the first synonym returned within each compound's list. Present when includeSynonyms is true. |
| descriptionOffset | No | Zero-based index of the first description returned within each compound's list. Present when includeDescription is true. |
| nextSynonymOffset | No | synonymOffset to pass on the next call to continue past this page. Omitted when no compound in the batch has further synonyms. |
| nextDescriptionOffset | No | descriptionOffset to pass on the next call to continue past this page. Omitted when no compound in the batch has further descriptions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnly/idempotent annotations by disclosing paging via synonymOffset/descriptionOffset, the 100-CID limit, the first-10-only restriction for descriptions/classification with skippedCids, and performance notes (slower for large CID lists, drug-likeness adds no latency). This is rich 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 three sentences: core purpose, optional enrichment features, and batch limit. It is front-loaded with the primary action and contains no filler or redundant 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?
The description covers the main purpose, optional data categories, and the 100-CID cap. It does not mention the first-10-only limitation for descriptions/classification (left to the schema) or explain return structure (output schema exists). For a tool this complex, slightly more in the description would improve completeness, but it is largely sufficient.
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?
With 100% schema description coverage, all 10 parameters already have defaults, ranges, and paging semantics documented. The main description does not add new parameter-level meaning; the mention of 'pharmacology, mechanism, therapeutic use' largely repeats what includeDescription already states. Baseline 3 is appropriate.
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 begins with 'Get detailed compound information by CID' and enumerates the specific data types returned (physicochemical properties, textual descriptions, synonyms, drug-likeness, classification). This makes it distinct from sibling tools like pubchem_get_compound_image or pubchem_get_summary.
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 you have CIDs and need detailed compound data, and it states a 100-CID batch limit. However, it does not explicitly contrast itself with sibling tools or mention when not to use it. The pointer to pubchem_search_compounds for name/SMILES resolution appears only in the schema's cids parameter, not in the main description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubchem_get_compound_imageGet Compound ImageAFetch a 2D structure diagram (PNG image) for a compound by CID.
| Name | Required | Description | Default |
|---|---|---|---|
| cid | Yes | PubChem Compound ID. Resolve from name/SMILES with pubchem_search_compounds. | |
| size | No | Image size: "small" (100x100) or "large" (300x300). Default: "large". | large |
| Name | Required | Description |
|---|---|---|
| cid | Yes | PubChem Compound ID. |
| width | Yes | Image width in pixels. |
| height | Yes | Image height in pixels. |
| mimeType | Yes | MIME type — always "image/png". |
| imageBase64 | Yes | Base64-encoded PNG image data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds that the output is a PNG image, which is useful but does not go beyond what the output schema likely conveys. No contradictions with 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?
The description is a single, front-loaded sentence that directly states the action and output. No wasted words; it is concise and appropriately structured.
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 simple 2D image fetch tool with two parameters, an output schema, and strong annotations, the description is complete. It identifies the resource and input, while the schema covers parameter details and the output schema covers return values. No significant missing context.
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 'size' having meaningful descriptions in the schema. The tool description itself does not add parameter semantics beyond the schema, so the baseline of 3 is appropriate.
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 fetches a 2D structure diagram (PNG image) for a compound by CID. It uses a specific verb ('Fetch') and resource ('2D structure diagram'), which distinguishes it from sibling tools like the 3D structure tool.
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 input schema parameter description for 'cid' provides practical guidance to resolve from name/SMILES with pubchem_search_compounds, which helps the agent obtain the required input. While it doesn't explicitly mention alternatives, the 2D vs 3D distinction is implicit and the resolution hint is valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubchem_get_compound_interactionsGet Compound InteractionsAGet a compound's interaction data: drug-drug interactions (DrugBank), drug-food interactions, and chemical-target interactions (binding/activity from BindingDB, ChEMBL, and others). Each entry carries its originating source. Results are paged per kind, with the source-record total and the next offset reported for each. Richest for approved drugs; many compounds have no deposited interaction records.
| Name | Required | Description | Default |
|---|---|---|---|
| cid | Yes | PubChem Compound ID. Resolve from name/SMILES with pubchem_search_compounds. | |
| kinds | No | Interaction kinds to fetch. "drug-drug" (interactions with other drugs), "drug-food" (dietary interactions), "target" (binding/activity against molecular targets). Default: ["drug-drug"]. | |
| offset | No | Zero-based start position within each requested kind, counted in source records rather than returned entries. The same offset applies to every kind in the call, and the kinds advance at different rates — when paging past the first page, request one kind per call and pass that kind's nextOffset. Default: 0. | |
| maxEntries | No | Max entries per kind per page (1-50). Well-studied drugs have a long tail of interactions; use offset to reach the ones past this page. Default: 10. |
| Name | Required | Description |
|---|---|---|
| cid | Yes | PubChem Compound ID. |
| notice | No | Guidance when a kind failed, when no interaction data was found, when the offset runs past every requested kind, or when further pages remain. Absent when this page is complete and every kind resolved. |
| offset | Yes | Zero-based start position read within each requested kind. |
| paging | Yes | Per-kind page position, one entry per requested kind that was retrieved. A kind listed in failedKinds is absent — its position is unknown, not exhausted. |
| entries | Yes | Interaction entries across the requested kinds. |
| nextOffset | No | Offset to pass on the next call, reported when exactly one requested kind has records remaining. Omitted when none do, and when several do — those advance to different positions, so read paging[].nextOffset instead. |
| failedKinds | No | Interaction kinds that could not be retrieved (comma-separated). The returned entries cover the kinds that succeeded; retry to re-attempt the failed ones. |
| returnedCount | Yes | Total interaction entries returned across all kinds. |
| requestedKinds | Yes | Interaction kinds requested (comma-separated). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context: pagination is 'paged per kind', returns 'source-record total and next offset', and discloses data availability limitations ('many compounds have no deposited interaction records'). This goes beyond the annotations and helps the agent understand pagination quirks and result sparsity.
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 three sentences, with the first sentence front-loading the core purpose and scope. The second sentence covers output and pagination details, while the third provides a useful caveat. Every sentence earns its place with 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?
Given the tool's complexity (multiple interaction kinds, pagination quirks) and the existence of an output schema, the description covers the essential operational behavior and the main caveat about data availability. It does not detail error handling or sorting, but those are not required, and the schema plus annotations handle parameter constraints and safety. The description is sufficiently complete for an agent to understand when and how to invoke 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 input schema is highly detailed (100% coverage) with descriptions for cid, kinds, offset, and maxEntries, including nuanced offset semantics. The description reinforces the pagination concept but does not materially add beyond the schema. Baseline 3 is appropriate because the schema carries the burden, and the description adds only a brief clarifying mention of per-kind pagination.
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 'Get' with the resource 'compound's interaction data' and enumerates the specific interaction kinds (drug-drug, drug-food, chemical-target). It distinguishes itself from sibling tools by mentioning the exact data sources (DrugBank, BindingDB, ChEMBL), making its scope unambiguous relative to other PubChem tools like get_bioactivity or get_safety.
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 when the tool is appropriate by describing interaction data and notes that it is 'richest for approved drugs', but it does not explicitly state alternatives or when not to use it. For example, it does not mention using pubchem_get_bioactivity for single-target activity data. Thus, usage guidance is present but implicit, lacking explicit exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubchem_get_compound_safetyGet Compound SafetyAGet GHS (Globally Harmonized System) hazard classification and safety data for one or more compounds by CID. Returns signal word, pictograms, hazard statements (H-codes), and precautionary statements (P-codes) per compound. Data sourced from PubChem depositors — source attribution included.
| Name | Required | Description | Default |
|---|---|---|---|
| cids | Yes | PubChem Compound IDs to fetch safety data for (1-25). Resolve from names/SMILES with pubchem_search_compounds. |
| Name | Required | Description |
|---|---|---|
| notice | No | Recovery guidance when one or more CIDs returned no GHS data, listing the unrecognized CIDs to verify separately from the CIDs that exist but carry no deposited classification. |
| results | Yes | Safety results, one per requested CID (input order preserved). |
| withDataCount | Yes | CIDs with GHS safety data available. |
| requestedCount | Yes | CIDs requested. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the bar for additional value is lower. The description still adds useful context by stating data is sourced from PubChem depositors and that source attribution is included, which helps the agent understand provenance and potential variability.
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?
Three concise sentences deliver the core function, the specific return content, and data sourcing without redundancy or digression. The structure front-loads the primary action and then elaborates efficiently.
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 this is a simple one-parameter read tool with full schema coverage, an output schema, and annotations covering safety, the description is complete. It covers purpose, return elements, and source provenance, plus the schema covers parameter details; no critical gaps remain.
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 fully covers the single parameter (cids) with type, constraints, and description. The description adds the hint to resolve from names/SMILES using pubchem_search_compounds, which goes beyond the schema and meaningfully aids the agent in constructing valid inputs.
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 retrieves GHS hazard classifications and safety data by CID, enumerating the return elements (signal word, pictograms, H-codes, P-codes). This is a specific verb-resource pairing that distinguishes it from sibling tools like pubchem_get_compound_details or pubchem_get_bioactivity.
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 primary use case is implied clearly: fetch safety data for compounds with CIDs. The parameter description adds a valuable directive to resolve names/SMILES via pubchem_search_compounds. However, it does not explicitly discuss when not to use this tool or compare it to alternatives, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubchem_get_compound_xrefsGet Compound Cross-ReferencesAGet external database cross-references for a compound: PubMed citations, patent IDs, gene/protein associations, registry numbers, and taxonomy IDs. Results are paged per type — capped at maxPerType with the total count reported; reach the IDs past a page with offset.
| Name | Required | Description | Default |
|---|---|---|---|
| cid | Yes | PubChem Compound ID. Resolve from name/SMILES with pubchem_search_compounds. | |
| offset | No | Zero-based index of the first ID to return within each xref type. The same offset is applied to every requested type. Pass the nextOffset from a previous call to read the following page. Default: 0. | |
| xrefTypes | Yes | Cross-reference types to retrieve. String IDs: RegistryID (DSSTox/EPA registry numbers), RN (CAS numbers), PatentID. Numeric IDs: PubMedID, GeneID (NCBI Gene), ProteinGI (legacy NCBI Protein GI), TaxonomyID. | |
| maxPerType | No | Max IDs to return per xref type per page (1-500). A compound may have thousands of PubMed references; use offset to reach the ones past this page. Total count always reported. Default: 50. |
| Name | Required | Description |
|---|---|---|
| cid | Yes | PubChem Compound ID. |
| xrefs | Yes | Cross-references grouped by type. |
| notice | No | Recovery guidance when every requested xref type returned zero IDs, when the offset runs past every type, or when further pages remain. Absent when this page is complete and non-empty. |
| offset | Yes | Zero-based index of the first ID returned within each type. |
| nextOffset | No | Offset to pass on the next call to continue past this page. Omitted when no requested type has further IDs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses paging behavior beyond annotations: 'Results are paged per type — capped at maxPerType with the total count reported; reach the IDs past a page with offset.' This adds meaningful context about how results are structured and accessed, complementing the readOnly/openWorld/idempotent hints.
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 concise sentences with high density. The first sentence states purpose and scope; the second explains paging. No redundant content, and the most important information is front-loaded.
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 complete schema with parameter descriptions, the existence of an output schema, and clear annotations, the description adequately covers pagination, types, and how to get more results. It is contextually complete for an AI agent to correctly select and invoke 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?
While the schema covers all parameters (100%), the description adds semantic context about pagination and offset behavior directly tied to `maxPerType` and `offset`. It explains the cap and how to navigate pages, going beyond the schema's basic descriptions.
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's function: 'Get external database cross-references for a compound' and enumerates specific types (PubMed citations, patent IDs, gene/protein associations, registry numbers, taxonomy IDs). This specific verb+resource combination distinguishes it from siblings like get_compound_details or get_bioactivity.
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 context (fetching xrefs) but does not explicitly mention alternatives or when-not-to-use. The schema for `cid` adds a helpful pointer to pubchem_search_compounds, but the main description lacks explicit sibling differentiation or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubchem_get_summaryGet Entity SummaryAGet descriptive summaries for PubChem entities by ID. Supports assays (AID), genes (Gene ID), proteins (UniProt accession), and taxonomy (Tax ID). Up to 10 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| entityType | Yes | Entity type. Determines ID format and returned fields. | |
| identifiers | Yes | Entity identifiers (1-10). Type depends on entityType: - assay: AID (number), e.g. [1000] - gene: Gene ID (number), e.g. [1956] - protein: UniProt accession (string), e.g. ["P00533"] - taxonomy: Tax ID (number), e.g. [9606] |
| Name | Required | Description |
|---|---|---|
| notice | No | Recovery guidance when one or more identifiers were not found. |
| summaries | Yes | Summary results. |
| entityType | Yes | Entity type queried. |
| foundCount | Yes | Identifiers resolved to a summary. |
| requestedCount | Yes | Identifiers requested. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavioral context: the batch limit of 10 and the scope of supported entity types. This is sufficient for a read-only, idempotent lookup 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?
Two concise, front-loaded sentences communicate the tool's purpose, supported types, and batch limit with zero wasted words. Every sentence earns its place.
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 simplicity, rich schema, output schema presence, and safety annotations, the description is nearly complete. It could optionally mention explicit use cases or alternatives, but the combination of description, schema, and annotations is adequate for correct 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 detailed descriptions of both entityType and identifiers, including examples for each entity type. The description reinforces that identifiers are by ID and supports up to 10, but does not add semantic meaning significantly 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 uses a specific verb ('Get') and resource ('descriptive summaries for PubChem entities by ID'), and clearly enumerates the supported entity types. This distinguishes it from sibling tools that focus on details, 3D structures, images, or interactions.
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 clearly implies when to use this tool: when you need summaries for entities identified by ID, supporting four types and up to 10 IDs. It does not explicitly name alternatives or exclusion criteria, but the context is clear enough for the agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubchem_search_assaysSearch AssaysAFind PubChem bioassays associated with a biological target. Search by gene symbol (e.g. "EGFR"), protein name, NCBI Gene ID, or UniProt accession. Returns a page of assay IDs (AIDs) — page past maxResults with offset — which can be explored further with pubchem_get_summary.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Zero-based index of the first AID to return. Pass the nextOffset from a previous call to read the following page. Default: 0. | |
| maxResults | No | Max AIDs to return per page (1-200). Popular targets may have thousands of assays; use offset to reach the ones past this page. Default: 50. | |
| targetType | Yes | Target identifier type. "genesymbol" and "proteinname" accept text names. "geneid" accepts NCBI Gene IDs. "proteinaccession" accepts UniProt accessions. | |
| targetQuery | Yes | Target identifier. Examples: "EGFR" (genesymbol), "Epidermal growth factor receptor" (proteinname), "1956" (geneid), "P00533" (proteinaccession). |
| Name | Required | Description |
|---|---|---|
| cap | No | The maxResults cap that was applied. |
| aids | Yes | PubChem Assay IDs. |
| shown | No | AIDs returned on this page. |
| notice | No | Recovery guidance when no assays matched, when the offset runs past the result set, or when further pages remain. Absent when this page is complete and non-empty. |
| offset | Yes | Zero-based index of the first AID returned. |
| truncated | No | True when matching AIDs remain past this page. |
| nextOffset | No | Offset to pass on the next call to continue past this page. Omitted when no further AIDs match. |
| targetType | Yes | Target identifier type used: genesymbol, proteinname, geneid, or proteinaccession. |
| totalFound | Yes | Total AIDs found for this target, across all pages. |
| targetQuery | Yes | Target identifier searched. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral detail: returns only a page of AIDs (not full data), pagination via offset/maxResults, and that popular targets may have many pages. This goes beyond the annotations without contradicting them.
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 purpose, each sentence earns its place: the first states the action and resource, the second covers search types, return format, pagination, and next steps. 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?
Given the rich schema (100% param coverage), annotations (read-only, idempotent, open-world), and presence of an output schema, the description is complete. It explains what the tool does, what inputs it accepts, what it returns, how to paginate, and how to continue exploration. Nothing critical is missing.
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 each of the 4 parameters having a detailed description, including examples for targetQuery and enum values for targetType. The description repeats some of this (e.g., the supported identifier types) but adds no new parameter-level information. Baseline 3 is appropriate because the schema fully carries the semantic burden.
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 starts with a specific verb+resource: "Find PubChem bioassays associated with a biological target." It clearly distinguishes this from sibling tools like pubchem_search_compounds by focusing on bioassays and target association. It also specifies the return type (a page of AIDs), removing ambiguity.
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 clear usage context: search by biological target (gene symbol, protein name, gene ID, UniProt) and paginate results. It references pubchem_get_summary as the next step for exploring AIDs, which gives practical guidance. However, it does not explicitly state when not to use this tool or compare with other search tools, so it misses a full exclusion case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubchem_search_compoundsSearch CompoundsASearch PubChem for chemical compounds by identifier (name, SMILES, or InChIKey, batched up to 25), molecular formula in Hill notation, substructure or superstructure containment, or 2D Tanimoto similarity. Returns a page of CIDs — reach matches past maxResults with offset. Optionally hydrate results with properties to avoid a follow-up pubchem_get_compound_details call.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Required for substructure/superstructure/similarity searches. A SMILES string (e.g. "CC(=O)O") or PubChem CID as a string (e.g. "2244"). | |
| offset | No | Zero-based index of the first CID to return. Pass the nextOffset from a previous call to read the following page. Identifier lookups resolve every match up front, so paging them is free; formula, substructure, superstructure, and similarity searches have to ask PubChem for offset + maxResults records to reach a page, so deep pages cost progressively more upstream — hence the 10000 ceiling. Default: 0. | |
| formula | No | Required for formula search. Molecular formula in Hill notation (e.g. "C6H12O6", "CaH2O2"). | |
| queryType | No | Required for structure/similarity searches. Format of the query: "smiles" or "cid". | |
| threshold | No | Similarity search only. Minimum Tanimoto similarity (70-100). 90+ for close analogs, 70-80 for scaffold hops. Default: 90. | |
| maxResults | No | Maximum CIDs to return per page (1-200). Use offset to reach matches past this page. Default: 20. | |
| properties | No | Optional: fetch these properties for each result, avoiding a follow-up details call. E.g. ["MolecularFormula", "MolecularWeight", "CanonicalSMILES"]. | |
| searchType | Yes | Search strategy. "identifier": name/SMILES/InChIKey lookup. "formula": molecular formula. "substructure": find compounds containing the query as a substructure. "superstructure": find compounds that are themselves substructures of the query. "similarity": 2D Tanimoto similarity to the query. | |
| identifiers | No | Required for identifier search. Array of identifiers to resolve (1-25). Examples: ["aspirin", "ibuprofen"] for name, ["CC(=O)OC1=CC=CC=C1C(=O)O"] for SMILES, ["BSYNRYMUTXBXSQ-UHFFFAOYSA-N"] for inchikey (27-char block format). | |
| identifierType | No | Required for identifier search. Type of chemical identifier: "name", "smiles", or "inchikey". | |
| allowOtherElements | No | Formula search only. When true, includes compounds with additional elements beyond the formula. |
| Name | Required | Description |
|---|---|---|
| cap | No | The maxResults cap that was applied. |
| shown | No | CIDs returned on this page. |
| notice | No | Recovery guidance when no compounds matched, when the offset runs past the matches observed, when identifiers failed to resolve, or when further pages remain. Absent when this page is complete and every identifier resolved. |
| offset | Yes | Zero-based index of the first CID returned. |
| results | Yes | Matching compounds. |
| truncated | No | True when matching CIDs remain past this page. |
| nextOffset | No | Offset to pass on the next call to continue past this page. Omitted when no further matches remain. |
| searchType | Yes | Search strategy used: identifier, formula, substructure, superstructure, or similarity. |
| totalFound | No | Exact number of matching CIDs across all pages. Omitted when a formula, substructure, superstructure, or similarity search saturated the records it requested — PubChem returns no match count for those, so totalFoundAtLeast reports a floor instead. |
| totalFoundAtLeast | No | Lower bound on matching CIDs, reported in place of totalFound when the exact count is unavailable. At least this many match, and the true total may be higher; page further with offset to observe more. |
| unresolvedIdentifiers | No | Identifier-mode only: input identifiers that resolved to no CID. Omitted when every identifier resolved and for non-identifier searches. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, and idempotent hints. The description adds valuable behavioral detail: batching up to 25 identifiers, pagination via offset, and optional property hydration. It also implies different paging costs for different search types, which is further elaborated in the schema, but the description itself provides meaningful transparency beyond the 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?
The description is exactly two sentences. The first sentence states scope and all search modes; the second addresses return format, pagination, and hydration. Every clause earns its place with no redundancy or fluff.
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 11 parameters, 5 search types, and an output schema, the description succinctly covers the core purpose, all search modes, result pagination, and the hydration option. The output schema handles return values, and the description mentions the most common follow-up action, making it complete for an agent to use 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 description coverage is 100%, and each parameter has detailed documentation. The description rephrases some of this (e.g., 'Hill notation', '2D Tanimoto similarity') but adds no significant extra meaning beyond the schema. The baseline of 3 is appropriate because the schema carries the heavy lifting.
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 'Search PubChem for chemical compounds' and enumerates all five search modes: identifier, formula, substructure, superstructure, and similarity. It also distinguishes itself from sibling get_* tools by mentioning optional hydration to avoid a follow-up details call.
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 clear context: it returns a page of CIDs and explains how offset works, and it suggests using properties to avoid a subsequent get_details call, implying when to use this tool versus a details lookup. It doesn't explicitly exclude other siblings, but the framing is sufficient for an agent to choose this over get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.