pubchem-mcp-server
Server Details
Search PubChem compounds, properties, safety data, bioactivity, and cross-references.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/pubchem-mcp-server
- GitHub Stars
- 9
- Server Listing
- pubchem-mcp-server
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.
Tool Definition Quality
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.
Available Tools
10 toolspubchem_get_bioactivityGet BioactivityARead-onlyIdempotentInspect
Get 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. | |
| maxResults | No | Max assay results to return (1-100). Well-studied compounds have thousands of records. 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The maxResults cap that was applied. |
| cid | Yes | PubChem Compound ID. |
| shown | No | Assays returned after the maxResults cap. |
| notice | No | Recovery guidance when the filter yields no results or the compound has no bioactivity data. |
| results | Yes | Assay results matching the filter. |
| truncated | No | True when results were capped at maxResults — more matching assays exist. |
| 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 | Assays matching the outcome and target filters, before the maxResults cap. |
| inactiveCount | Yes | Assays with "Inactive" outcome. |
| outcomeFilter | Yes | Outcome filter applied: active, inactive, or all. |
| returnedCount | Yes | Assays returned after the maxResults cap. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe, idempotent read operations. The description adds context on the type of data returned and mentions that well-studied compounds have many records (in parameter desc), which is useful behavioral insight.
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 plus an example. Every sentence adds value with no unnecessary detail. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and annotations, the description adequately covers the tool's function and return data. It mentions filtering and the large number of records for well-studied compounds, which is helpful for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented there. The main description reinforces filtering logic (e.g., 'combine with outcomeFilter="active"') but doesn't add significant new meaning beyond what the schema provides, placing it at baseline.
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 a compound's bioactivity profile, listing specific data types (assays, outcomes, targets, quantitative values). While it doesn't explicitly differentiate from siblings like pubchem_get_compound_interactions, the focus on bioactivity assays is distinct enough.
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 filtering options and provides a concrete use case ('is this compound active against target T?'). It implies when to use filters but doesn't discuss when not to use this tool or alternatives, resulting in minor gaps.
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 StructureARead-onlyIdempotentInspect
Get a compound's default 3D conformer — atomic coordinates and bonds — for one CID. format="json" (default) returns parsed atoms and bonds the model can reason over directly; 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. Adds one extra API call. Default: false. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, openWorldHint, and idempotentHint. The description adds beyond this: the optional alternate conformer listing, atom/bond capping with disclosure, and format-specific behavior (includeRawSdf only applies to SDF). It does not contradict 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 three sentences, each serving a distinct purpose: primary action, format guidance, and caveat. No redundant words. Information is front-loaded: the first sentence conveys the core function. Excellent conciseness.
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 returns a complex 3D structure and an output schema exists, the description adequately covers the key behaviors: default conformer, format options, truncation details, and the existence of alternate conformers. No obvious gaps for an agent to invoke the tool correctly.
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 6 parameters have schema descriptions (100% coverage). The description adds value by explaining the semantic difference between JSON and SDF formats and the purpose of capping (atomCount/bondCount always report full totals). It does not repeat schema descriptions but enriches them.
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', the resource 'compound's default 3D conformer', and the scope 'for one CID'. It distinguishes between JSON and SDF formats. Sibling tools like 'pubchem_get_compound_details' and 'pubchem_get_compound_image' have different purposes, making this tool's unique role unambiguous.
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 when to use each format: JSON for reasoning and SDF for docking/rendering. It warns that not all compounds have 3D coordinates. While it doesn't explicitly contrast with siblings, the context signals and sibling names imply this is the only 3D structure tool. Slightly more explicit guidance on when to avoid or prefer alternatives would improve clarity.
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 DetailsARead-onlyIdempotentInspect
Get detailed compound information by CID. Returns physicochemical properties (molecular weight, SMILES, InChIKey, XLogP, TPSA, etc.), optionally with a textual description (pharmacology, mechanism, therapeutic use), all known synonyms, drug-likeness assessment (Lipinski/Veber rules), and/or pharmacological classification (FDA classes, MeSH classes, ATC codes). Efficiently batches up to 100 CIDs.
| Name | Required | Description | Default |
|---|---|---|---|
| cids | Yes | PubChem Compound IDs to fetch (1-100). Batched efficiently. 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 (1-100). PubChem lists hundreds for common drugs; capped to keep the response focused. Default: 20. | |
| includeSynonyms | No | Fetch all known names and synonyms (trade names, systematic names, registry numbers). One API call per CID — slower than the property batch for large CID lists. | |
| maxDescriptions | No | Max number of distinct description entries per compound (1-20). PubChem returns near-duplicate summaries from many depositors; we dedup and cap to keep responses focused. Default: 3. | |
| includeDescription | No | Include textual descriptions (pharmacology, mechanism, therapeutic use) attributed by source. Well-studied compounds have many overlapping summaries — capped via maxDescriptions. Fetched only for the first 10 CIDs in the batch; remaining CIDs return without descriptions. | |
| includeDrugLikeness | No | Compute drug-likeness assessment: Lipinski Rule of Five (MW, XLogP, HBD, HBA) and Veber rules (TPSA, rotatable bonds). No extra API calls — computed from properties. | |
| 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| compounds | Yes | Compound detail records. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond annotations: efficient batching, performance costs (synonyms slower than property batch), and limitations (descriptions/classification fetched only for first 10 CIDs). It also notes deduplication for descriptions. No contradiction with annotations (readOnlyHint, openWorldHint, idempotentHint).
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 dense paragraph but covers all essential information. It is front-loaded with the main purpose and uses concise language. Minor improvement could be structural bullet points, but overall it is well-organized for the agent.
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 8 parameters, output schema existence, and sibling tools, the description is fully complete. It explains each parameter's effect, defaults, limitations, and performance hints, leaving no ambiguity for the agent to invoke the tool correctly.
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%, but the description adds significant value: explains default properties, reasons for caps (maxSynonyms, maxDescriptions), performance impact (includeSynonyms), and computation source (includeDrugLikeness). Each parameter's purpose and behavior are clarified 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 action ('Get detailed compound information by CID') and specifies the returned data (physicochemical properties, descriptions, synonyms, drug-likeness, classification). It distinguishes from siblings by focusing on detailed compound data, unlike bioactivity or structure 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 description mentions efficient batching (up to 100 CIDs) and advises resolving names/SMILES using pubchem_search_compounds. It implies when to use this tool but does not explicitly compare to siblings or state when not to use it.
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 ImageARead-onlyIdempotentInspect
Fetch 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 |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description carries minimal burden. It confirms the non-mutating nature but adds no additional behavioral context (e.g., error handling, performance characteristics).
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, well-structured sentence that conveys all essential information without redundancy. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description does not need to cover return values. The tool has only two parameters with full schema coverage, and the description, though brief, is sufficient for an agent to understand basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to elaborate. The description itself adds no new meaning beyond what the schema already provides for both parameters (cid and size).
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 the action (Fetch), output format (PNG image), resource type (2D structure diagram), and required input (CID). It clearly distinguishes from siblings like pubchem_get_compound_3d_structure by specifying '2D'.
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 does not provide any guidance on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or conditions. The schema hints at resolving CID via pubchem_search_compounds, but this is not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubchem_get_compound_interactionsGet Compound InteractionsARead-onlyIdempotentInspect
Get 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. 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"]. | |
| maxEntries | No | Max entries per kind (1-50). Well-studied drugs have a long tail of interactions. Default: 10. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cid | Yes | PubChem Compound ID. |
| notice | No | Guidance when no interaction data was found for the requested kinds. |
| entries | Yes | Interaction entries across the requested kinds. |
| 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds context: each entry carries its source, and data coverage is uneven. 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?
Two sentences plus a brief caveat. All information is essential, front-loaded, and 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 presence of an output schema and rich annotations, the description fully covers what the tool does, its parameter semantics, data sources, and coverage limitations. An agent can confidently select and invoke it.
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 parameter descriptions. The description enriches the 'kinds' parameter by listing specific source databases (DrugBank, BindingDB, ChEMBL). It also reinforces the cid resolution hint from 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 tool retrieves a compound's interaction data, listing specific types (drug-drug, drug-food, target) and naming authoritative sources (DrugBank, BindingDB, ChEMBL). It distinguishes from siblings like pubchem_get_bioactivity by focusing on interactions rather than single bioassays.
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 notes that richness varies (richest for approved drugs, many have no records) and implicitly advises use for interaction queries. However, it does not explicitly compare with specific sibling tools or state when to avoid it.
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 SafetyARead-onlyIdempotentInspect
Get 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Cross-tool guidance when one or more CIDs have no GHS data, pointing to an alternative source. |
| results | Yes | Safety results, one per requested CID (input order preserved). |
| withDataCount | Yes | CIDs with GHS safety data available. |
| requestedCount | Yes | CIDs requested. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context about data sourcing from PubChem depositors and inclusion of source attribution, which goes beyond the annotations. However, it could further clarify variability or limitations in data completeness.
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, front-loaded with the core purpose and return data, followed by a brief source note. Every sentence adds value without redundancy, achieving maximum conciseness.
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 (single required parameter, no nested objects, output schema exists), the description fully covers what the tool does, what it returns, and data provenance. It is complete for an agent to understand invocation and result 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 input schema covers the single parameter 'cids' thoroughly, including constraints and a cross-reference to pubchem_search_compounds. With 100% schema coverage, the description does not need to add param semantics; baseline 3 is appropriate as the description adds no new information about the parameter beyond what is already in 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 tool retrieves GHS hazard classification and safety data by CID, listing specific return fields (signal word, pictograms, H-codes, P-codes). It distinguishes itself from sibling tools like pubchem_get_compound_details by focusing on safety data, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for safety data but does not explicitly state when to use this tool versus alternatives. It mentions resolving CIDs via pubchem_search_compounds, but lacks explicit when-not or comparative guidance against siblings like pubchem_get_bioactivity or pubchem_get_summary.
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-ReferencesARead-onlyIdempotentInspect
Get external database cross-references for a compound: PubMed citations, patent IDs, gene/protein associations, registry numbers, and taxonomy IDs. Results are capped per type with total counts reported.
| Name | Required | Description | Default |
|---|---|---|---|
| cid | Yes | PubChem Compound ID. Resolve from name/SMILES with pubchem_search_compounds. | |
| 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 (1-500). A compound may have thousands of PubMed references. Total count always reported. Default: 50. |
Output Schema
| 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 — hints to verify the CID. Absent when any cross-references were found. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds important behavioral context: results are capped per type and total counts are reported, which is beyond what annotations provide. No contradictions.
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 consists of two concise sentences that front-load the main action and immediately list example cross-reference types. Every sentence adds value with no superfluous 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?
With an output schema present and comprehensive annotations, the description covers the essential aspects: what data is returned, that it is capped, and that counts are reported. No critical information is missing for an AI agent to use the tool correctly.
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% and each parameter has a description. The tool description adds further meaning by clarifying xrefTypes (e.g., RegistryID as DSSTox/EPA, RN as CAS) and noting that maxPerType cap applies but total count always reported. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves external database cross-references for a compound, listing specific types like PubMed citations, patent IDs, and gene/protein associations. It distinguishes this from sibling tools that handle other compound information (e.g., details, bioactivity, structure).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving cross-references, but does not provide explicit when-not or alternative tool names. The listing of sibling tools and context of other compound-focused tools suggests appropriate use, but guidance could be stronger.
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 SummaryARead-onlyIdempotentInspect
Get 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] |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint true. The description adds minor behavioral context (max 10 per call, entity type formats) but does not discuss error handling, rate limits, or response structure beyond the implicit summary content.
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 precise language—every phrase serves a purpose. No redundancy or irrelevant 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?
Given the presence of an output schema and annotations, the description is nearly sufficient. It covers entity types, quantity limits, and ID hints. A small gap is the lack of mention that compounds are not supported (implied by the listed types), but overall informative enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds limited extra meaning. It mentions 'Up to 10 per call' and maps entity types to ID formats, but the schema already includes detailed descriptions for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Get' and resource 'descriptive summaries for PubChem entities by ID'. It enumerates four entity types (assays, genes, proteins, taxonomy) and sets a limit (10 per call), effectively distinguishing it from siblings focusing on compounds or other operations.
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 states the entity types supported but does not provide explicit guidance on when to choose this tool over siblings, like pubchem_get_compound_details or pubchem_search_assays. No 'when not to use' or alternative comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubchem_search_assaysSearch AssaysARead-onlyIdempotentInspect
Find PubChem bioassays associated with a biological target. Search by gene symbol (e.g. "EGFR"), protein name, NCBI Gene ID, or UniProt accession. Returns assay IDs (AIDs) which can be explored further with pubchem_get_summary.
| Name | Required | Description | Default |
|---|---|---|---|
| maxResults | No | Max AIDs to return (1-200). Popular targets may have thousands of assays. 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). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The maxResults cap that was applied. |
| aids | Yes | PubChem Assay IDs. |
| shown | No | AIDs returned after the maxResults cap. |
| notice | No | Recovery guidance when no assays matched — echoes the target and suggests alternative search types. Absent when assays were returned. |
| truncated | No | True when AIDs were capped at maxResults — more assays exist than returned. |
| targetType | Yes | Target identifier type used: genesymbol, proteinname, geneid, or proteinaccession. |
| totalFound | Yes | Total AIDs found before the maxResults cap. |
| targetQuery | Yes | Target identifier searched. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safe read-only behavior. Description adds behavioral context about result size ('Popular targets may have thousands of assays') and suggests follow-up. No contradictions.
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 front-loaded purpose, examples, and follow-up recommendation. Efficient but could be slightly more structured for scanning.
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?
Adequately describes a search tool with clear inputs, output type (AIDs), and next steps. No need to detail output schema since it exists separately.
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 covers 100% of parameters with descriptions. Description provides examples but adds limited new meaning beyond schema. Mild value in noting popular targets may produce many results.
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?
Clearly states the tool finds PubChem bioassays by biological target, using specific identifier types. Distinguishes from sibling tools like pubchem_search_compounds.
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?
Provides clear context on acceptable identifier types and intended use (searching by target). Implicitly guides use by saying results can be explored further with pubchem_get_summary, but no explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubchem_search_compoundsSearch CompoundsARead-onlyIdempotentInspect
Search 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. 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"). | |
| 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 (1-200). 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The maxResults cap that was applied. |
| shown | No | CIDs returned after the maxResults cap. |
| notice | No | Recovery guidance when no compounds matched — echoes search strategy and suggests how to broaden. Absent when results were returned. |
| results | Yes | Matching compounds. |
| truncated | No | True when CIDs were capped at maxResults — more matches exist than returned. |
| searchType | Yes | Search strategy used: identifier, formula, substructure, superstructure, or similarity. |
| totalFound | Yes | Total CIDs found before the maxResults cap. |
| unresolvedIdentifiers | No | Identifier-mode only: input identifiers that resolved to no CID. Omitted when every identifier resolved and for non-identifier searches. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, openWorld, idempotent), the description adds behavioral details: batching up to 25 identifiers, optional property hydration, and the variety of search strategies. This provides useful context for the agent's decision-making.
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, front-loading the core search capabilities and then adding a note about optional hydration to avoid a follow-up call. Every sentence adds value without 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 complexity (10 params, 1 required, enums, output schema exists), the description provides a solid overview. It could be more detailed on trade-offs between search types, but the schema covers parameter specifics adequately. The existence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal parameter-specific meaning beyond the schema (e.g., overview of search types). It does not compensate for low coverage, but coverage is high, so a score 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 specifies the tool's function: searching PubChem by multiple criteria (identifier, formula, substructure, superstructure, similarity) and optionally hydrating results. It distinguishes from sibling tools like pubchem_get_compound_details by mentioning the hydration feature to avoid a follow-up 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 explicitly states when to use this tool for searching and when to avoid a follow-up call by including properties. It implies alternatives such as pubchem_get_compound_details, giving clear guidance on usage context.
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.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.