pubchem-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.0
Disambiguation5/5
Every tool has a clearly distinct purpose, from searching compounds to retrieving specific details, images, 3D structures, cross-references, safety data, bioactivity, interactions, assays, and summaries. There is no overlap.
Naming Consistency5/5
All tool names follow a consistent 'pubchem_[verb]_[noun]' pattern with snake_case, using 'get' or 'search' as verbs. This makes the naming predictable and easy to understand.
Tool Count5/5
With 10 tools, the server is well-scoped for a chemical compound database. Each tool covers a necessary aspect of querying PubChem, and the count is appropriate—not too few to be insufficient and not too many to be overwhelming.
Completeness4/5
The tool set covers the major functionalities for retrieving PubChem data, including searching, details, images, 3D, cross-references, safety, bioactivity, interactions, assays, and summaries. However, there is no direct tool for spectral data or patent retrieval, though cross-references include patents. A minor gap but overall comprehensive.
Average 4.3/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 55 commits in the last 12 weeks
- Last stable release on July 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint. The description adds that the output is a PNG image, providing useful context beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 12 words, front-loaded with action, no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complete schema, annotations, and presence of output schema, the description is sufficient for a simple image retrieval tool. Everything needed is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 add new meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a 2D structure diagram (PNG image) by CID, with a specific verb and resource. It distinguishes from siblings like pubchem_get_compound_3d_structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for 2D images, but does not explicitly state when to use or when not to use, nor does it mention alternatives directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, and idempotent behavior. The description adds useful context: returns specific safety data fields, source attribution, and resolves by CID. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding distinct value: action and scope, return data specifics, and data provenance. No wasted words, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential aspects: tool purpose, return fields, source, and via schema the parameter limits and workflow. With comprehensive annotations and output schema present, no gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a detailed description for the 'cids' parameter including limit and resolution hint. The main description adds no further parameter meaning beyond 'by CID', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves GHS hazard classification and safety data by CID, listing specific return fields (signal word, pictograms, H-codes, P-codes). This clearly identifies the unique safety data niche among sibling tools like get_compound_details or get_bioactivity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The parameter description suggests a workflow (resolve names/SMILES with pubchem_search_compounds) but does not contrast with other data retrieval tools or give exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context: that not every compound has 3D coordinates, mentions the format options (json vs sdf), and that includeAlternateConformerIds is slower. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states core purpose, second explains format behavior, third adds a key limitation and optional feature. Each sentence is necessary and front-loaded. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and an output schema, the description covers the main behavioral aspects: purpose, format choices, and a limitation. It doesn't detail truncation (maxAtoms/maxBonds) or includeRawSdf, but these are in the schema. Output schema exists, so return values are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description restates the format default and the optional alt conformer IDs but does not add significant new meaning beyond the schema. The schema already describes all parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'compound's default 3D conformer' with atomic coordinates and bonds for one CID. It differentiates from sibling tools like pubchem_get_compound_image and pubchem_get_compound_details by specifying 3D structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for one CID and suggests alternatives like looking up CIDs via pubchem_search_compounds. It mentions optional features like alternate conformer IDs but does not explicitly state when not to use this tool versus siblings, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds paging behavior details (capped results, total count reported, offset across types) that go beyond annotations, providing useful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first defines purpose, second explains paging. No redundant words, efficient and front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, existing output schema), the description covers key behaviors (paging, pagination across types, total count). It does not discuss edge cases (e.g., missing xref types), but the openWorldHint annotation covers data incompleteness. Overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 value by explaining pagination mechanics (capped maxPerType, offset applied to each type) and summarizing cross-reference types, which complements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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' and lists specific types (PubMed, patents, genes, etc.), distinguishing it from sibling tools like pubchem_get_compound_details or pubchem_get_bioactivity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains paging behavior (maxPerType, offset, total count) but does not explicitly state when to use this tool versus alternatives like pubchem_search_compounds or other getters. Usage is implied but not contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context such as batch limit (up to 10) and that it returns descriptive summaries. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the core purpose, second lists supported types and the batch limit. Every word is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema existing and schema fully describing parameters, the description is complete for a batch summary tool. It could briefly mention typical use cases (e.g., 'Use for quick overviews') but is sufficient as is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no new meaning beyond what the schema already provides for parameters. The description repeats entity type and ID format information that is fully documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches descriptive summaries for PubChem entities by ID, listing four specific entity types (assays, genes, proteins, taxonomy). This distinguishes it from sibling tools like pubchem_search_compounds and pubchem_get_compound_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies supported entity types, ID formats, and a batch limit of 10. However, it does not explicitly state when to use this tool versus more specific tools like pubchem_get_compound_details for compounds, though the distinction is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, so the description's behavioral disclosure is minimal. It adds that results are a page of AIDs and describes pagination, which is useful but not required beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. Key information is front-loaded: purpose, search methods, return type, pagination, and follow-up tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given presence of output schema, the description covers search scope, pagination, and next steps. It is complete for a search tool with no missing gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 value by explaining the purpose of the return (AIDs), how pagination works (page past maxResults with offset), and the relationship between targetType and targetQuery examples. This enhances understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it finds PubChem bioassays associated with biological targets, listing specific search types (gene symbol, protein name, NCBI Gene ID, UniProt accession). This distinguishes it 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains pagination using offset and maxResults, and suggests exploring results further with pubchem_get_summary. Does not explicitly provide when-not or alternatives, but context is sufficient for a search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, openWorld, and idempotent hints. The description adds useful behavioral context: paging behavior (offset usage, cost implications for deep pages) and optional hydration. No contradictions with annotations. Lacks mention of rate limits or auth, but these are implied by readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core function and search types, no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 11 parameters and 5 search types, the description covers all major aspects: search strategies, paging, and hydration. The output schema exists to detail return format. A minor gap is the lack of explanation of the 10,000 offset ceiling, but that is in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds meaning by explaining the batching limit for identifiers, the threshold range for similarity, and the hydration option, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool searches PubChem for chemical compounds using five distinct strategies (identifier, formula, substructure, superstructure, similarity) and explicitly mentions the return of CIDs with optional hydration. This clearly differentiates it from sibling tools like pubchem_get_compound_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises when to use hydration to avoid a follow-up call, and enumerates the search types, guiding selection. However, it does not explicitly exclude use cases for other siblings (e.g., when to use pubchem_search_assays instead), leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, and idempotent hints. The description adds critical behavioral details: caps on descriptions/classification (first 10 CIDs only), pagination via offsets, and default property sets. This goes beyond annotation coverage 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3-4 sentences) and front-loaded: first sentence states the core purpose, followed by bullet-like lists of return types. Every sentence earns its place; no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, nested pagination, first-10-only constraints), the description completely covers key behaviors: input limits, default properties, pagination for synonyms/descriptions, and the skippedCids fallback. The presence of an output schema is noted but not needed to detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 10 parameters have schemas with descriptions, achieving 100% coverage. The description adds value by explaining defaults (e.g., property set, synonym offset behavior), performance impacts (slow for large synonym lists), and pagination mechanics. This meaningfully extends beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves detailed compound information by CID, listing specific data types (physicochemical properties, textual description, synonyms, drug-likeness, pharmacological classification). It distinguishes itself from sibling tools like pubchem_search_compounds (which resolves names to CIDs) and 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the CID input limit (100 per call) and directs users to pubchem_search_compounds for name/SMILES resolution. It implicitly communicates usage context (when you have CIDs) but does not explicitly contrast with sibling tools like pubchem_get_summary for simpler needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral details beyond annotations: paging per kind, source-record total and next offset reported, and that each entry carries its source. It also notes the variability in data richness, all while remaining consistent with the readOnlyHint, openWorldHint, and idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with five sentences covering purpose, interaction kinds, paging, and data richness. The most important information is front-loaded. No redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, output schema present), the description adequately explains paging behavior, data sources, and variability in results. The mention of output structure (source-record total, next offset) complements the output schema. No critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds overall context about paging behavior but does not elaborate on parameter specifics beyond what the schema already provides (e.g., format of offset). No significant added value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool retrieves compound interaction data including drug-drug, drug-food, and target interactions, with sources listed. It distinguishes itself from sibling tools like get_compound_details or get_bioactivity by focusing solely on interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when the tool is most useful (richest for approved drugs) and notes that many compounds have no records, implying limited applicability. However, it does not explicitly state when to use alternatives or exclude certain scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations: it explains pagination (offset, maxResults) and the effect of filters on the result set. Annotations already indicate read-only and idempotent, which the description does not contradict. There is no destructive behavior, and the description adds useful context about what data is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences. The first sentence defines the tool's purpose and outputs, and the second explains filtering with an example. Every word adds value; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, rich annotations (readOnly, openWorld, idempotent), and an output schema (implied by context signals), the description is complete. It covers the primary functionality, filtering, pagination, and a use case. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 value by explaining the purpose of filtering (e.g., 'focus the profile'), suggesting how to obtain the cid (using pubchem_search_compounds), and providing an example query. This goes beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'bioactivity profile', specifying what data is returned: assays, outcomes, target identifiers, quantitative values. It distinguishes from sibling tools like pubchem_get_compound_details by focusing on bioactivity rather than general properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete example ('is this compound active against target T?') and explains how to use filters to focus results. While it doesn't explicitly compare to sibling tools, the example gives clear guidance on when to use filtering. A slight improvement would be mentioning when this tool is preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pubchem-mcp-server MCP server](https://glama.ai/mcp/servers/cyanheads/pubchem-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/cyanheads/pubchem-mcp-server)

Score Badge

Copy to your README.md:

[![pubchem-mcp-server MCP server](https://glama.ai/mcp/servers/cyanheads/pubchem-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/cyanheads/pubchem-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cyanheads/pubchem-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server