Skip to main content
Glama

pubchem-mcp-server

by io.github.cyanheads

Get Compound Interactions

pubchem_get_compound_interactions
Read-onlyIdempotent

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. Results are paged per kind, with the source-record total and the next offset reported for each. Richest for approved drugs; many compounds have no deposited interaction records.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cidYesPubChem Compound ID. Resolve from name/SMILES with pubchem_search_compounds.
kindsNoInteraction kinds to fetch. "drug-drug" (interactions with other drugs), "drug-food" (dietary interactions), "target" (binding/activity against molecular targets). Default: ["drug-drug"].
offsetNoZero-based start position within each requested kind, counted in source records rather than returned entries. The same offset applies to every kind in the call, and the kinds advance at different rates — when paging past the first page, request one kind per call and pass that kind's nextOffset. Default: 0.
maxEntriesNoMax entries per kind per page (1-50). Well-studied drugs have a long tail of interactions; use offset to reach the ones past this page. Default: 10.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cidNoPubChem Compound ID.
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when a kind failed, when no interaction data was found, when the offset runs past every requested kind, or when further pages remain. Absent when this page is complete and every kind resolved.
offsetNoZero-based start position read within each requested kind.
pagingNoPer-kind page position, one entry per requested kind that was retrieved. A kind listed in failedKinds is absent — its position is unknown, not exhausted.
entriesNoInteraction entries across the requested kinds.
truncatedNoTrue when at least one requested kind has source records remaining past this page. Which kinds, and how many records each holds, is in paging[].truncated / paging[].totalRecords.
nextOffsetNoOffset to pass on the next call, reported when exactly one requested kind has records remaining. Omitted when none do, and when several do — those advance to different positions, so read paging[].nextOffset instead.
failedKindsNoInteraction kinds that could not be retrieved (comma-separated). The returned entries cover the kinds that succeeded; retry to re-attempt the failed ones.
returnedCountNoTotal interaction entries returned across all kinds.
requestedKindsNoInteraction kinds requested (comma-separated).

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description does not contradict them. It adds substantial behavioral context beyond those hints: entries carry their originating source, results are paged per kind, the source-record total and next offset are reported per page, and data coverage is uneven across compounds.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no filler: the first scopes the tool and sources, the second explains paging and per-entry source attribution, and the third manages expectations about data availability. The most identifying information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a paginated multi-kind read tool with an output schema present, the description adequately covers what the agent needs: interaction scope, source attribution, paging mechanics with per-kind offsets, and data-coverage caveats. Return-field details are the output schema's job, so no further description is necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema itself already explains cid resolution, the kinds enum values, offset semantics including the one-kind-per-call paging caveat, and maxEntries bounds. The description's paging sentence mildly reinforces offset behavior but adds no parameter meaning beyond what the schema already documents, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource—'Get a compound's interaction data'—and then enumerates the exact interaction kinds and source databases (DrugBank, BindingDB, ChEMBL). It clearly communicates what the tool returns, but it never names or explicitly contrasts with siblings like pubchem_get_bioactivity, which overlaps with the chemical-target interaction portion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The use case is implied: retrieve interaction records for a compound. It adds useful expectation-setting context ('Richest for approved drugs; many compounds have no deposited interaction records'), but it gives no explicit when-not-to-use guidance or alternative tool names, leaving agents to infer when a sibling would be preferable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All pubchem-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Tools cleanly separate into search (compounds, assays) and retrieval (details, structure, image, safety, xrefs, bioactivity, interactions, summary). The only mild overlap is bioactivity versus interactions, but their descriptions clarify that one focuses on assay outcomes and the other on drug-drug/food/chemical-target records.

Naming Consistency5/5

All tools follow a consistent pubchem_<verb>_<object> pattern, with get_ for retrieval and search_ for discovery. Minor variations like pubchem_get_summary still fit the same convention clearly.

Tool Count5/5

Ten tools is well-scoped for a PubChem client: search entry points, compound detail retrieval, structural representations, safety data, interaction data, and cross-reference lookups. Each tool earns its place without redundancy.

Completeness5/5

The surface covers the core PubChem workflows: finding compounds and assays, retrieving compound properties and structures, and exploring bioactivity, safety, interactions, and cross-references. Search results feed directly into retrieval tools, and paging is provided where needed, leaving no obvious dead ends.

Resources