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.2/5 across 10 of 10 tools scored.
Tools cleanly separate into search (compounds, assays) and retrieval (details, structure, image, safety, xrefs, bioactivity, interactions, summary). The only mild overlap is bioactivity versus interactions, but their descriptions clarify that one focuses on assay outcomes and the other on drug-drug/food/chemical-target records.
All tools follow a consistent pubchem_<verb>_<object> pattern, with get_ for retrieval and search_ for discovery. Minor variations like pubchem_get_summary still fit the same convention clearly.
Ten tools is well-scoped for a PubChem client: search entry points, compound detail retrieval, structural representations, safety data, interaction data, and cross-reference lookups. Each tool earns its place without redundancy.
The surface covers the core PubChem workflows: finding compounds and assays, retrieving compound properties and structures, and exploring bioactivity, safety, interactions, and cross-references. Search results feed directly into retrieval tools, and paging is provided where needed, leaving no obvious dead ends.
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 | No | PubChem Compound ID. |
| error | No | Present when the call failed. Absent on success. |
| 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 | No | Zero-based index of the first assay returned. |
| results | No | 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 | No | Assays with "Active" outcome. |
| totalAssays | No | Total unique assays for this compound. |
| targetFilter | No | Target filter applied (gene ID and/or protein accession), when set. |
| filteredCount | No | Exact number of assays matching the outcome and target filters, across all pages. |
| inactiveCount | No | Assays with "Inactive" outcome. |
| outcomeFilter | No | Outcome filter applied: active, inactive, or all. |
| returnedCount | No | Assays returned on this page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it returns quantitative values and identifiers, but doesn't specify the exact response format (e.g., whether it returns a list of assays with nested target info) or pagination behavior beyond mentioning offset. The readOnlyHint and idempotentHint are consistent with the read-only nature of the tool, but the description doesn't elaborate on potential response size or data structure.
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 well-structured, with the core purpose stated first, then behavior details It avoids unnecessary verbosity while covering key aspects. The example question is helpful but could be seen as slightly redundant given the parameter descriptions, but it doesn't hurt.
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 fully covers what the tool does and how to use it, including filtering and pagination. It doesn't mention potential edge cases (e.g., compound with no assays) or response schema details, but the schema is provided separatelyholistically. The tool is from a set (search compounds etc.), and the description references them appropriately.
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?
All parameters are described with types, defaults, and constraints in the schema apparent in the prompt. The description adds semantic guidance for offset (zero-based, after filters), maxResults (paginate for more), and targetGeneId (how to obtain it). Some fields like targetAccession are described but could use more detail on format, but overall strong.
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 what the tool does: retrieves a compound's bioactivity profile including assays, outcomes, targets, and quantitative values. It gives concrete examples (NCBI Gene ID, UniProt accession, IC50/EC50/Ki) and a use-case question, making the purpose immediately understandable.
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 explains how to filter by outcome and target, and gives a specific query example ('is this compound active against target T?'). The schema further clarifies pagination (offset, maxResults) and how to resolve Gene IDs using related tools, providing complete usage guidance.
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 | No | 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". |
| error | No | Present when the call failed. Absent on success. |
| 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 | No | Number of atoms in the conformer. |
| bondCount | No | 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?
Annotations already convey read-only, idempotent, and open-world behavior; the description adds meaningful context by explaining the two output formats and the important caveat that large molecules, mixtures, and some salts may have no 3D coordinates. It does not cover error behavior or rate limits, but those are less critical given the read-only hint.
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 three-sentence description is tightly front-loaded, beginning with the core operation and data returned, then explaining format behavior and availability limits. Every sentence earns its place and there is no redundant restatement of schema details.
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 read-only retrieval tool with a rich output schema and complete parameter documentation, the description covers purpose, format choice, and a key failure-prone case. Truncation and safe-line details are already handled in the parameter schema, so nothing essential 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?
All six parameters are fully documented in the schema with defaults, enums, and truncation behavior, so the description is not required to compensate. The description briefly reinforces the format distinction and alternate conformer option but does not add substantial parameter semantics 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?
States a specific verb and resource: retrieving a compound's default 3D conformer with atomic coordinates and bonds for one CID. The format distinction (JSON vs raw SDF) further clarifies exactly what the tool returns, setting it apart from sibling compound detail and image tools.
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?
Gives clear use context, such as raw SDF for docking, rendering, or conformer tools, and warns that some compounds lack computed 3D coordinates. However, it does not explicitly name sibling alternatives or state when to prefer them, leaving routing decisions mostly implicit.
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 |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| 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 | No | Compound detail records. |
| truncated | No | True when this response is not the whole picture: a compound has further synonyms or descriptions past this page, or CIDs were skipped by the per-call fan-out limit. Per-compound totals are in compounds[].synonymsTotal / compounds[].descriptionsTotal; the skipped CIDs are in skippedCids. |
| 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 discloses important behaviors beyond the annotations: it accepts up to 100 CIDs, descriptions/classification are fetched only for the first 10 CIDs, synonyms are paged with offsets, and drug-likeness is computed with no extra latency. These details help the agent set expectations and avoid surprising limits.
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 sentences cover the core purpose, optional features, and a key constraint, all front-loaded. No filler or redundant wording.
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 output schema and detailed input schema, the description covers all major behavioral caveats (first-10 limit, pagination offsets, duplication collapsing). It is sufficiently complete for an agent to decide when and how to call 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 provides rich descriptions for all 10 parameters, including defaults, ranges, and pagination behavior, so the description adds little beyond summarizing the main property categories. The mention of 'XLogP, TPSA, etc.' aligns with the properties enum but does not add new meaning 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 explicitly states 'Get detailed compound information by CID' and enumerates the specific types of data returned (physicochemical properties, descriptions, synonyms, drug-likeness, classification). This clearly differentiates it from sibling tools like pubchem_get_summary, which presumably returns a brief overview, and pubchem_get_compound_image, which returns an image.
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 the tool is for comprehensive compound data, but it does not explicitly state when to prefer it over sibling tools such as pubchem_get_summary. It does direct users to resolve CIDs from names/SMILES via pubchem_search_compounds in the input schema, which is a useful cross-tool pointer. However, no explicit exclusions or alternative selection criteria are provided in the description text.
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 | No | PubChem Compound ID. |
| error | No | Present when the call failed. Absent on success. |
| width | No | Image width in pixels. |
| height | No | Image height in pixels. |
| mimeType | No | MIME type — always "image/png". |
| imageBase64 | No | 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, covering the safety and mutation profile. The description adds the output format 'PNG image' and explicitly states '2D structure diagram', which is useful behavioral context beyond the structured annotations. No contradiction.
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?
A single, tightly-written sentence with zero redundancy. The core action and output format are front-loaded, making it immediately actionable.
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: 2 parameters, both fully documented in schema. The description provides the purpose and output format, and annotations cover safety. Nothing an agent needs to call it correctly 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 description coverage is 100%. The cid parameter already includes resolution guidance (use pubchem_search_compounds) and the size parameter documents dimensions and default. The tool description adds nothing beyond the schema, 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?
States a specific verb ('Fetch'), a clear resource ('2D structure diagram (PNG image)'), and the required key ('by CID'). The 2D qualifier differentiates it from the sibling pubchem_get_compound_3d_structure, so an agent can distinguish it even without opening the schema.
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?
Does not explicitly mention alternative tools or when-not-to-use conditions. The purpose is self-evident for retrieving a 2D image, and sibling names suggest alternatives, but the description itself offers no explicit routing guidance. Score reflects implied usage only.
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 | No | PubChem Compound ID. |
| error | No | Present when the call failed. Absent on success. |
| 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 | No | Zero-based start position read within each requested kind. |
| paging | No | 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 | No | Interaction entries across the requested kinds. |
| truncated | No | True when at least one requested kind has source records remaining past this page. Which kinds, and how many records each holds, is in paging[].truncated / paging[].totalRecords. |
| 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 | No | Total interaction entries returned across all kinds. |
| requestedKinds | No | 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, and the description does not contradict them. It adds substantial behavioral context beyond those hints: entries carry their originating source, results are paged per kind, the source-record total and next offset are reported per page, and data coverage is uneven across compounds.
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 sentences with no filler: the first scopes the tool and sources, the second explains paging and per-entry source attribution, and the third manages expectations about data availability. The most identifying 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?
For a paginated multi-kind read tool with an output schema present, the description adequately covers what the agent needs: interaction scope, source attribution, paging mechanics with per-kind offsets, and data-coverage caveats. Return-field details are the output schema's job, so no further description is necessary.
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 the schema itself already explains cid resolution, the kinds enum values, offset semantics including the one-kind-per-call paging caveat, and maxEntries bounds. The description's paging sentence mildly reinforces offset behavior but adds no parameter meaning beyond what the schema already documents, so the baseline 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 opens with a specific verb and resource—'Get a compound's interaction data'—and then enumerates the exact interaction kinds and source databases (DrugBank, BindingDB, ChEMBL). It clearly communicates what the tool returns, but it never names or explicitly contrasts with siblings like pubchem_get_bioactivity, which overlaps with the chemical-target interaction portion.
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 use case is implied: retrieve interaction records for a compound. It adds useful expectation-setting context ('Richest for approved drugs; many compounds have no deposited interaction records'), but it gives no explicit when-not-to-use guidance or alternative tool names, leaving agents to infer when a sibling would be preferable.
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 |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| 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 | No | Safety results, one per requested CID (input order preserved). |
| withDataCount | No | CIDs with GHS safety data available. |
| requestedCount | No | CIDs requested. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent safety profile; the description adds that the data comes from PubChem depositors and includes source attribution, which is useful context beyond the annotations. It also clarifies the return contents per compound.
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, with the primary purpose front-loaded and the source-attribution note appended. Every sentence earns its place and there is no repetition of schema details.
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 read-only, single-parameter tool with an output schema and supportive annotations, the description covers selection and invocation adequately. It could be fuller about behavior when GHS data is missing for a CID, but that gap is minor.
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 documents the single cids parameter well, including range, constraints, and resolution guidance. The description only restates that input is by CID, so it adds no meaningful semantic 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?
Names a specific resource (GHS hazard classification and safety data), the key input (CIDs), and concrete outputs (signal word, H-codes, P-codes, pictograms), which is enough to distinguish it from sibling PubChem get-* tools.
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 purpose implies when to use it, but the description does not state when not to use it or name alternatives such as pubchem_get_compound_details or pubchem_get_summary. The schema adds a useful cross-reference to pubchem_search_compounds for resolving CIDs.
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 | No | PubChem Compound ID. |
| error | No | Present when the call failed. Absent on success. |
| xrefs | No | 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 | No | Zero-based index of the first ID returned within each type. |
| truncated | No | True when at least one requested type has IDs remaining past this page. Which types, and how many IDs each holds in total, is in xrefs[].truncated / xrefs[].totalAvailable. |
| 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?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the paging behavior (capped at maxPerType, total count reported, offset to read further) which the agent needs to know to correctly iterate results. It doesn't contradict any annotation. Doesn't describe return format, but output schema covers that. A 4 is fair because the description adds meaningful behavioral context 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?
Two sentences, front-loaded with the primary purpose, then a compact explanation of paging. No filler, every word 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?
With a 100% parameter schema coverage and a returned output schema, the description covers purpose, scope, and paging behavior. Nothing an agent needs in order to call it correctly 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 detailed per-parameter descriptions, including the semantics of xrefTypes enumerations Continued. The description adds the cross-type paging model ('Results are paged per type') which clarifies how maxPerType and offset interact across multiple requested types. This goes beyond the schema property descriptions. A 4 reflects that added meaning.
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 a specific verb ('Get external database cross-references'), names the resource ('a compound'), and enumerates the specific cross-reference types (PubMed citations, patent IDs, gene/protein associations, registry numbers, taxonomy IDs). This is unambiguous and distinguishes the tool from siblings like pubchem_get_compound_properties without needing to inspect the schema.
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 scopes when to use this tool ('external database cross-references') and notes the paging behavior for large result sets. It doesn't explicitly name alternative tools for non-xref data like 3D structures or synonyms, but the tool name and the clear focus imply the boundary. No explicit exclusion of alternatives, so a 4 rather than 5.
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 SummaryBGet 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 |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Recovery guidance when one or more identifiers were not found. |
| summaries | No | Summary results. |
| entityType | No | Entity type queried. |
| foundCount | No | Identifiers resolved to a summary. |
| requestedCount | No | Identifiers requested. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds 'Get descriptive summaries' and lists supported entities, which is consistent, but it does not describe potential failure modes, rate limits beyond batch size, or whether summaries are returned as a list or single object.
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 short sentences front-load the core purpose ('Get descriptive summaries for PubChem entities by ID') and then add key constraints. No filler or repetition beyond the schema, though the enumeration of entity types partly duplicates the enum property. Otherwise it is dense and easy to scan.
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 there is no output schema, the description doesn't explain what a summary contains (e.g., names, descriptions, cross-reference counts), and it doesn't mention return format. The batch limit and ID formats are present but largely duplicative of the input schema. A bit more on output shape would help agents set expectations.
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: entityType enum with descriptions, identifiers with per-type ID formats (AID, gene, UniProt, Tax ID) and min/max items. The description mostly repeats schema info ('Supports assays...', 'Up to 10 per call'), adding only the 'descriptive summaries' wording, so it offers minimal extra meaning 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 states the operation ('Get descriptive summaries'), the input kind ('by ID'), and enumerates the four supported entity types (assay, gene, protein, taxonomy). Although the schema enum already lists types, the description frames them in terms of the ID formats they accept, which helps an agent map the tool to the right use case immediately.
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 tells the agent what the tool does and that it accepts up to 10 IDs per call, which is already encoded in the schema's maxItems. It does not name sibling tools (like pubchem_get_bioactivity) or state when to prefer this summary tool over a search or retrieval sibling, leaving routing partly to inference.
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 | No | PubChem Assay IDs. |
| error | No | Present when the call failed. Absent on success. |
| 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 | No | 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 | No | Target identifier type used: genesymbol, proteinname, geneid, or proteinaccession. |
| totalFound | No | Total AIDs found for this target, across all pages. |
| targetQuery | No | Target identifier searched. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, and idempotent hints, so the safety profile is covered. The description adds genuinely useful behavioral context: pagination mechanics ('page past maxResults with offset'), that results are a 'page' of AIDs, and the open-world nature of results ('Popular targets may have thousands of assays'). These insights go beyond the structured 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?
Three sentences with zero waste. The first states the primary action, the second enumerates valid inputs with concrete examples, and the third describes output plus forward-routing. Every sentence earns its place 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?
For a 4-parameter tool with a full output schema, the description covers all necessary call information: inputs, pagination, and the natural next step via pubchem_get_summary. The only slight gap is not describing end-of-pagination behavior, but this is minor given the schema handles return semantics and the description covers the full user journey.
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 thorough descriptions on offset, maxResults, targetType, and targetQuery, including examples. The description reinforces the identifier types and pagination but adds little beyond what the schema already provides. Since the schema does the heavy lifting and the description is consistent with it, this lands at the baseline 3 for high schema coverage.
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 and resource: 'Find PubChem bioassays associated with a biological target', which clearly distinguishes this search tool from its siblings like pubchem_get_summary (retrieval) and pubchem_search_compounds (different resource). It also specifies the exact output (AIDs) and the accepted identifier types. This is fully non-tautological and specific enough to route an agent correctly without opening the schema.
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: use this when you have a biological target and need related assays, and it routes the agent to 'pubchem_get_summary' for further exploration. However, it doesn't explicitly state when NOT to use this tool (e.g., if you already have an AID, use get_summary directly) or contrast with pubchem_search_compounds. The sibling reference is helpful but could be more exclusionary.
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. |
| error | No | Present when the call failed. Absent on success. |
| 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 | No | Zero-based index of the first CID returned. |
| results | No | 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 | No | 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 readOnlyHint, openWorldHint, and idempotentHint. The description adds meaningful behavioral detail beyond those hints: results come as pages of CIDs, offset reaches matches past maxResults, and properties hydration avoids a secondary call. No contradiction with the annotations exists.
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 sentences with no filler: search modes first, then paging behavior, then hydration guidance. Every sentence earns its place and the most important scoping 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?
For a tool with 11 parameters and five search strategies, the description surveys all modes, batching, paging, and hydration. An output schema exists, so omitting detailed return-value documentation is acceptable; the combination of description, schema, and annotations is 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 carries the full parameter-level detail. The description still adds value by linking the properties parameter to avoiding a follow-up call, highlighting the 25-item batch limit, and naming Hill notation and 2D Tanimoto similarity to orient the agent.
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 a specific verb and resource ('Search PubChem for chemical compounds') and enumerates all search strategy variants: identifier, formula, substructure, superstructure, similarity. It clearly separates this from sibling tools like pubchem_get_compound_details and pubchem_search_assays.
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: use this to find compounds by structural or identifier-based criteria, and use the properties option to avoid a follow-up pubchem_get_compound_details call. It does not explicitly state when not to use it or name alternatives like pubchem_search_assays.
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.