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.2/5 across 10 of 10 tools scored.
Each tool has a clearly distinct purpose: compound info, structure, image, bioactivity, interactions, safety, cross-references, summaries for other entities, and searches. No overlap.
All tools follow the 'pubchem_verb_object' pattern with lowercase underscores. Verbs are consistently 'get' or 'search', and objects clearly differentiate resource types.
10 tools is well-scoped for a chemistry database server, covering essential retrieval and search operations without being excessive.
Core compound operations (details, structure, activity, safety, cross-references) and search are covered. Minor gaps like spectral data or direct patent display are acceptable; the set is robust.
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 |
| 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". |
| atomCount | Yes | Number of atoms in the conformer. |
| bondCount | Yes | Number of bonds in the conformer. |
| conformerId | No | Default (primary) conformer ID. Present when includeAlternateConformerIds is set. |
| 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?
The description adds behavioral details beyond annotations (readOnlyHint, idempotentHint, openWorldHint). It explains output formats (json for reasoning, sdf for passthrough) and that includeAlternateConformerIds adds an API call. It also notes the limitation about missing 3D coordinates.
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 concise sentences, each adding essential information: primary action, format behaviors, and limitations. No redundant or vague language. 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 tool's complexity (3 parameters, existing output schema) and the combination of schema and annotations, the description is complete. It covers purpose, usage constraints, format outcomes, and optional parameter effects. The agent has sufficient context 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?
While schema coverage is 100%, the description adds practical context: json returns parsed atoms/bonds, sdf returns raw SDF for passthrough, and includeAlternateConformerIds triggers an extra API call. This enriches the parameter 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 'Get a compound's default 3D conformer — atomic coordinates and bonds — for one CID.' This specific verb+resource combination distinguishes it from sibling tools like pubchem_get_compound_details or pubchem_get_compound_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 explains that not every compound has 3D coordinates (large molecules, mixtures, salts), guiding when not to use. It also mentions resolving CIDs from pubchem_search_compounds in the parameter description. However, it lacks explicit comparisons to other siblings for when to choose this tool.
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. | |
| 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 important behaviors beyond annotations: batching efficiency, limitations on descriptions and classification to first 10 CIDs, dedup and capping for maxDescriptions, and that descriptions are fetched individually. This fully informs the agent of operational constraints.
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 relatively concise and front-loaded, but the list of properties and options in parentheses makes it a bit dense. It could be slightly more streamlined without losing clarity, but it efficiently conveys the tool's capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, optional features, batching, dedup, and per-CID limits), the description covers all critical aspects. It explains what each option does, limitations, and performance trade-offs, making it complete for an agent to decide to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the default property set, how to resolve CIDs, and the per-CID cost for includeSynonyms. This contextual information helps the agent use parameters effectively.
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 that it gets detailed compound information by CID and lists many properties and options. However, it does not explicitly distinguish itself from sibling tools like pubchem_get_summary or pubchem_get_compound_xrefs, which could serve similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance, such as using pubchem_search_compounds to resolve CIDs and noting batching limits. However, it does not compare this tool to alternatives or specify when not to use it, leaving the agent to infer the best tool for different scenarios.
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent. Description adds that results are capped per type and total counts are reported, providing extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key info, no wasted words. Could be slightly more structured but efficient.
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 output schema exists and annotations cover safety/idempotency, the description provides adequate context about scope (xrefs with capped results and total counts).
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 has 100% coverage with detailed descriptions. The tool description lists the xref types but doesn't add significant 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?
Clearly states 'Get external database cross-references for a compound' with specific types listed, distinguishing it from sibling tools that provide details, bioactivity, etc.
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?
Implies use case for retrieving cross-references, and parameter descriptions mention resolving compound IDs from search; no explicit when-not-to-use or alternatives, but context with siblings makes it clear.
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. |
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 behavioral context: batching limits (up to 25 identifiers), supported identifier types, and the optional property hydration. These details complement the annotations without 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?
The description is only two sentences, no unnecessary words. It front-loads the core purpose and then adds the hydration note. Every sentence is informative and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, multiple search types, and an output schema), the description covers all main functionalities. It does not explain return values, but the presence of an output schema alleviates that need. It could mention that results are CIDs with optional properties, but this is implied by the hydration option.
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 descriptions for all 10 parameters. The description adds value by summarizing search types and highlighting the hydration option's benefit, which goes beyond the individual parameter descriptions. It also clarifies the 'formula' parameter expects Hill notation and the batching limit for identifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: search PubChem for compounds by identifier, formula, substructure, superstructure, or similarity. It distinguishes itself from sibling tools like pubchem_get_compound_details by explicitly mentioning the option to hydrate results 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 provides clear guidance on when to use the hydration option to avoid a separate details call. It lists the various search types and hints at their use cases. However, it does not explicitly state when not to use this tool (e.g., for bioactivity data) or compare it to sibling search tools, but the sibling list helps differentiate.
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.