Skip to main content
Glama

chembl-get-drug-info

chembl_get_drug_info
Read-onlyIdempotent

Pharmacology for a drug (molecule): mechanism(s) of action, the molecular target(s) it acts on, action type (inhibitor / agonist / …), first-approval year, and clinical indications with the max phase reached for each. Supply molecule_chembl_id (from chembl_search_molecules). Distinct from the openfda server's label/adverse-event view — this is the curated mechanism-and-indication record. A mechanism's target_chembl_id chains into chembl_get_bioactivities for compounds hitting the same target. Each list carries its own retrieval state: an empty mechanisms or indications array means the molecule has none recorded only when the matching mechanisms_status / indications_status is "complete" — "failed" means the upstream request was rejected and the array says nothing about the molecule, and "truncated" means the page cap bounded the list at fewer rows than the matching *_total_count.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
molecule_chembl_idYesChEMBL molecule ID (from chembl_search_molecules), e.g. "CHEMBL939" for gefitinib.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoDisclosure of anything the two lists do not say for themselves: a list whose upstream fetch failed (so its emptiness means nothing), a list the page cap bounded, or — only when both lists came back complete and empty — that the molecule may be a research compound rather than a drug.
max_phaseNoMax clinical phase across indications: 4 = marketed. Null when unknown.
pref_nameNoPreferred drug name, e.g. "GEFITINIB". Null when unnamed.
mechanismsNoMechanisms of action. Empty is authoritative only when mechanisms_status is "complete".
indicationsNoClinical indications. Empty is authoritative only when indications_status is "complete".
first_approvalNoYear of first approval, e.g. 2003. Null when unapproved or unknown.
mechanisms_statusNoRetrieval state of the mechanism list. "complete" = every row ChEMBL records is present, so an empty array is a fact about the molecule. "truncated" = the single-request page cap bounded the list, so the array is a prefix of mechanisms_total_count rows. "failed" = the upstream request was rejected, so the empty array is unknown data, NOT evidence that none exist — re-call chembl_get_drug_info to retry.
indications_statusNoRetrieval state of the indication list. "complete" = every row ChEMBL records is present, so an empty array is a fact about the molecule. "truncated" = the single-request page cap bounded the list, so the array is a prefix of indications_total_count rows. "failed" = the upstream request was rejected, so the empty array is unknown data, NOT evidence that none exist — re-call chembl_get_drug_info to retry.
molecule_chembl_idNoThe ChEMBL molecule ID queried.
mechanisms_total_countNoTotal mechanism rows ChEMBL holds for this molecule (upstream page_meta.total_count). Exceeds the returned array length exactly when the status is "truncated". Null when the fetch failed — the count is unknown, never 0.
indications_total_countNoTotal indication rows ChEMBL holds for this molecule (upstream page_meta.total_count). Exceeds the returned array length exactly when the status is "truncated". Null when the fetch failed — the count is unknown, never 0.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description goes far beyond them by explaining the retrieval-state semantics: an empty mechanisms/indications array is meaningful only when the corresponding status is 'complete', while 'failed' and 'truncated' have distinct interpretations. This prevents the agent from misreading empty arrays as definitive absence of data—a critical behavioral nuance not captured by annotations. It also notes the chaining to bioactivities, adding functional 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 dense yet efficient: it front-loads the core output, then covers input source, distinction from an alternative server, chaining to a sibling tool, and finally the crucial status semantics. Every sentence carries essential information—no filler. The structure is logical and well-organized, making it easy for an agent to parse despite its length.

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, the presence of an output schema, and the annotations, the description covers all critical aspects an agent needs: what data is returned, where the input comes from, how it differs from an alternative view, how to chain to related tools, and how to correctly interpret empty results via the status fields. It addresses a likely pitfall (interpreting empty arrays) and leaves no obvious gaps for correct invocation.

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% and the single parameter already has a detailed description ('ChEMBL molecule ID (from chembl_search_molecules), e.g. "CHEMBL939" for gefitinib.'). The tool description reiterates the source and adds an example, reinforcing the parameter's origin. Since the schema alone is nearly sufficient, the description adds marginal but useful value (source tool and concrete example), so a 4 is appropriate above the baseline of 3.

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 opens with a clear verb and resource: 'Pharmacology for a drug (molecule)' followed by a specific list of what it returns (mechanisms, targets, action type, first-approval year, indications with max phase). It explicitly names the input ('Supply molecule_chembl_id') and distinguishes itself from the openfda server's label/adverse-event view, making it easy to differentiate from siblings like chembl_get_bioactivities or chembl_get_assay.

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 strong contextual guidance: it states the input comes from chembl_search_molecules and differentiates this tool from the openfda server's view, indicating an alternative. It also chains to chembl_get_bioactivities via target_chembl_id, suggesting when to use that related tool. However, it does not explicitly state 'when not to use' this tool beyond the openfda distinction, and it lacks a crisp 'use this when you need curated pharmacology' statement, leaving some inference to the agent.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool targets a distinct resource or action: search for molecules and targets, fetch bioactivities, assays, and drug info, plus two dedicated dataframe helpers for analysis. There is no functional overlap—even the two dataframe tools are clearly separated as describe vs query. Agents can easily select the right tool for each step in a workflow.

Naming Consistency5/5

All tools follow a consistent chembl_verb_noun pattern using snake_case (e.g., chembl_search_molecules, chembl_get_bioactivities, chembl_dataframe_query). The naming is uniform and predictable, with the verb always preceding the object. Minor deviation like dataframe_describe vs chembl_get_* still fits the same prefix and style, making it highly consistent.

Tool Count5/5

With 7 tools, the server is well-scoped for its domain of compound-target bioactivity discovery and analysis. Each tool serves a clear purpose without redundancy, covering search, retrieval, provenance, pharmacology, and data manipulation. This is a textbook example of a focused toolset where every tool earns its place.

Completeness5/5

The tool surface covers the full read-only lifecycle: discover compounds and targets, fetch bioactivity measurements, drill into assay provenance, retrieve drug pharmacology, and perform aggregate analysis via SQL. All major workflows (target deconvolution, lead finding, selectivity assessment, and comparative ranking) are supported without dead ends. The only possible gap is write operations, but they are clearly out of scope for a reference database.