Skip to main content
Glama

search_chembl_molecule

Read-only

Convert drug or compound names, synonyms, or structural strings into ChEMBL IDs, supporting exact matches or extraction from text.

Instructions

Resolve a DRUG / COMPOUND / MOLECULE (by name or structure) to a ChEMBL ID.

✅ Use this tool for drug, compound, or molecule names (e.g., "sorafenib", "imatinib", "aspirin", "Gleevec"). ⚠️ For biological targets (proteins, receptors, enzymes, genes such as EGFR, BRCA1, TP53), use search_chembl_target instead.

Resolution path is auto-selected from the query shape:

• NAME / BRAND / SYNONYM → deterministic SPARQL, EXACT (case-insensitive) match on the molecule's skos:altLabel synonyms (which include brand and trade names — "Gleevec" → CHEMBL941 IMATINIB). Not fuzzy/substring: fix typos before calling. No relevance ranking to second-guess.

• InChIKey / InChI → deterministic SPARQL, EXACT (case-SENSITIVE) match on the RDF-stored identifier. These are canonical (toolkit-independent), so exact match is correct, e.g. "BSYNRYMUTXBXSQ-UHFFFAOYSA-N" → CHEMBL25.

• SMILES → the ChEMBL REST chemistry engine (flexmatch), NOT exact match: a SMILES is written differently by each toolkit, so flexmatch normalizes the structure first, e.g. "CC(=O)Oc1ccccc1C(=O)O" → CHEMBL25.

Structure detection is conservative (multi-word input, or input without the "InChI=" prefix / InChIKey pattern / structural punctuation, is treated as a name), so a bare-chain SMILES like "CCO" is treated as a name.

The search string can be passed as any of: query (canonical), search, term, keyword, keywords, search_term, or name.

⚠️ mode='extract' — for a string that NAMES a drug rather than IS one. Exact matching (the default) cannot resolve a clinical-trial intervention string, a dosed/formulated product, or a multi-drug regimen, because none of those is a synonym of anything: "Ustekinumab 90 mg", "Diclofenac SR", "Ropivacaine 10% + Clonidine 1 µg/kg" all return 0 rows under 'exact'. mode='extract' instead finds every substance NAMED INSIDE the string, returning one result per distinct drug — so the combination above yields ROPIVACAINE and CLONIDINE. Nested synonyms collapse to the longest match ("Sofpironium Bromide Gel" → SOFPIRONIUM BROMIDE, not also BROMIDE). Use it as the RETRY when 'exact' returns nothing, not as the first call: it is a text-extraction heuristic, so treat a hit as a candidate to confirm, and note that it resolves a regimen to its COMPONENTS — it will never return "FOLFIRI" itself, only the drugs a string spells out.

RETURNS a dict {'total_count', 'has_more', 'results'}. total_count is rows RETURNED (capped by limit), not the full match count; has_more is true if more exist beyond this page. Each result has 'chembl_id' (e.g. "CHEMBL25") and 'name' (rdfs:label, may be None for some structure hits). Under mode='extract' each result additionally carries 'matched_span' (the text that matched) and 'match_type' ('exact' if the span is the whole query, else 'contained') — CHECK 'match_type' before trusting a hit. When a call returns no results, a 'note' key explains why and what to try next. On endpoint/HTTP failure this tool does NOT raise — it returns a dict with a single 'error' key instead; CHECK FOR 'error' BEFORE READING 'results'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo"exact" (default) matches the WHOLE string against a synonym; "extract" finds substances named INSIDE it. Defaults to "exact".exact
nameNo
termNo
limitNoMaximum number of results to return. Defaults to 20.
queryNoDrug/compound name, brand, synonym, or a structure string. Examples: "Aspirin", "Gleevec", "CC(=O)Oc1ccccc1C(=O)O", "BSYNRYMUTXBXSQ-UHFFFAOYSA-N".
searchNo
keywordNo
keywordsNo
search_termNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

Beyond annotations readOnlyHint=true and openWorldHint=true, the description thoroughly discloses matching semantics (deterministic exact vs. SMILES flexmatch), case sensitivity, conservative structure detection, and non-raising error behavior returning an 'error' key. It also explains the extract mode's heuristic nature and 'match_type' checking. This goes far beyond what annotations provide and contains 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.

Conciseness4/5

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

The description is long but dense and well-organized with bullet points, clear sections, and front-loaded purpose. Every major behavioral nuance (exact vs extract, error handling, return keys) earns its place, though a few points (e.g., the full list of alias parameters) are repeated. Slightly verbose for the tool's complexity but justified.

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?

Despite the output schema existing, the description adds critical operational context: return dict keys, total_count meaning, has_more semantics, matched_span/match_type under extract, the 'note' key for empty results, and the 'error' key on HTTP failure. It also addresses edge cases like bare-chain SMILES. The tool is complex, and the description covers all necessary decision paths.

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

Parameters5/5

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

Schema description coverage is only 33%, but the description compensates fully. It clarifies that any of seven alias parameters can carry the search string, explains mode='exact' vs 'extract' in detail with examples, and interprets the return shape tied to limit. It adds significant semantic meaning beyond the raw 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 opens with a clear verb+resource statement: 'Resolve a DRUG / COMPOUND / MOLECULE (by name or structure) to a ChEMBL ID.' It immediately distinguishes itself from sibling search_chembl_target by explicitly redirecting biological target queries. The scope is precise and matches the tool name.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance: use for drug/compound/molecule names, and for targets use search_chembl_target instead. It also details when to use mode='extract' as a retry for strings that name drugs rather than being drugs, and warns against using it as the first call. This is exemplary usage guidance.

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

Install Server

Other Tools

Latest Blog Posts

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/dbcls/togomcp'

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