Skip to main content
Glama

chembl-get-bioactivities

chembl_get_bioactivities
Read-onlyIdempotent

The flagship compound↔target bioactivity bridge: measurements for a molecule (target deconvolution / selectivity), a target (lead finding), or both together (how potently one compound hits one target). Supply at least one of molecule_chembl_id (from chembl_search_molecules) or target_chembl_id (from chembl_search_targets) — supplying both narrows to that compound–target pair, supplying neither is an error. Filter by standard_type (IC50/Ki/EC50/…), minimum potency pchembl_value_min, assay_type, and organism. Not every measurement has a derivable pchembl_value, so potency_view picks which side of that split you get: the default "potency_ranked" returns the measurements that have one, most potent first (ChEMBL sorts the rest first otherwise, which is why they are not merged), and "null_potency" returns exactly the measurements that have none. totalCount is the honest full match count across both views either way. Mixing measurement types (IC50 vs Ki) is a scientific error — set standard_type to compare like with like. A popular target carries tens of thousands of rows: results spill to a DataCanvas table (call chembl_dataframe_describe for its columns, then chembl_dataframe_query for honest aggregates across the staged set), while an inline preview answers the immediate question. Each view stages its own table (bioactivities / bioactivities_null_potency), so running both against one canvas_id lets a UNION ALL rebuild the full set. The staged table is capped at CHEMBL_MAX_SPILL_ROWS; when the cap is hit, truncated is true and the table is a bounded slice, not the complete view. The inline rows are always capped at limit, so compare that against totalCount before treating them as the whole answer. Spilling the rest requires CANVAS_PROVIDER_TYPE=duckdb; without it the inline preview is all there is.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum rows in the inline preview. Defaults to the server default (25). The full set still spills to the canvas.
organismNoRestrict to a target organism, e.g. "Homo sapiens" (case-insensitive exact match).
canvas_idNoOptional canvas ID from a prior call to reuse the same canvas. Each potency_view re-stages its own table, so a second query of the SAME view REPLACES (overwrites) its prior rows — it does not append — while the other view's table is left intact, which is what lets both coexist on one canvas. Omit to mint a fresh canvas.
assay_typeNoRestrict to an assay type code: "B" (binding), "F" (functional), "A" (ADMET), "T" (toxicity).
potency_viewNoWhich side of the pchembl_value presence split to retrieve. "potency_ranked" (default) returns the measurements that have a derivable pchembl_value, most potent first. "null_potency" returns exactly the measurements that have none — the rows the ranked view excludes, otherwise unreachable. The two partition the match set and stage to separate canvas tables.potency_ranked
standard_typeNoRestrict to one measurement type, e.g. "IC50", "Ki", "EC50". Set this to compare potencies validly.
target_chembl_idNoChEMBL target ID (from chembl_search_targets), e.g. "CHEMBL203". Supply this, molecule_chembl_id, or both — both narrows to that compound–target pair.
pchembl_value_minNoMinimum pchembl_value (−log10 molar potency), e.g. 7 keeps sub-100 nM activities. Only valid on the potency_ranked view — the null_potency rows have no pchembl_value to compare against.
molecule_chembl_idNoChEMBL molecule ID (from chembl_search_molecules), e.g. "CHEMBL941". Supply this, target_chembl_id, or both — both narrows to that compound–target pair.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when no measurements matched, or how to SQL the spilled set.
spilledNoTrue when the view exceeded the preview and was staged on the canvas.
canvas_idNoCanvas ID holding the staged table — pass to chembl_dataframe_describe to list its columns, then to chembl_dataframe_query to run SQL over them. Null when canvas is disabled or nothing spilled.
truncatedNoTrue when the CHEMBL_MAX_SPILL_ROWS cap was hit before the upstream view was exhausted — the staged table is a bounded slice, NOT the complete view, so aggregates over it are a sample. Narrow the filters to bring the view under the cap.
activitiesNoBioactivity rows for the selected potency_view — the inline preview, or the full view when it fit without spilling.
table_nameNoCanvas table name holding the staged rowset, and the FROM target for chembl_dataframe_query SQL — "bioactivities" for potency_ranked, "bioactivities_null_potency" for null_potency. Null when not spilled.
totalCountNoTotal matching measurements upstream — the honest full count spanning BOTH potency views, before any preview cap. The staged/preview rows are the selected view of this.
potency_viewNoWhich view these rows came from: "potency_ranked" = measurements with a derivable pchembl_value; "null_potency" = measurements with none. Re-call with the other value to reach the rest of totalCount.
appliedFiltersNoFilters as the server parsed them.
canvasDisabledNoTrue when CANVAS_PROVIDER_TYPE is not duckdb, so large sets could not spill — the inline rows are a capped preview, not the full set.
staged_row_countNoRows actually registered on the canvas table. Null when nothing spilled. Below the view total when truncated is true.

TDQS

A5/5.0
Behavior5/5

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

Annotations declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds substantial behavioral context: the potency_view split with exact semantics of each side, the truncation cap with 'truncated' flag, the behavior of totalCount across views, and the canvas staging behavior (overwrite vs. coexist). It even explains why rows are not merged. This is precisely the kind of context that lets an agent predict side effects and data shape without risking a wrong call.

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 long but every sentence carries information. It front-loads the core purpose, then systematically covers invocation, filtering, the two-view split, spill behavior, and tool integrations. There is no filler or repetition; each clause earns its place. The structured flow from 'what' to 'how' to 'edge cases' makes it easy for an agent to parse quickly.

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 (9 params, two views, spill logic, coordination with four sibling tools), the description is remarkably complete. It covers error conditions, partition semantics, truncation, canvas behavior, and cross-tool handoffs. The presence of an output schema covers return-value details, so the description appropriately focuses on invocation and behavioral nuances, leaving nothing ambiguous for a competent agent.

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?

Though schema coverage is 100%, the description vastly enriches parameter meaning. It explains pchembl_value_min semantics, the scientific rationale for setting standard_type ('compare like with like'), the exact partition defined by potency_view, and the behavior of canvas_id across views. It goes beyond the schema's field descriptions to teach the agent how the parameters interact (e.g., pchembl_value_min only valid on potency_ranked). This is high-value added semantics.

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 crisp purpose statement: 'flagship compound↔target bioactivity bridge' and immediately enumerates the three invocation modes (molecule-only, target-only, molecule+target) with their scientific use cases (deconvolution, lead finding, selectivity). This clearly distinguishes it from siblings like chembl_search_molecules or chembl_dataframe_query, and the verb 'get' plus resource 'bioactivities' makes the action unambiguous.

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 preconditions ('Supply at least one... supplying neither is an error'), explicit conditions for narrowing (both IDs), a warning against mixing measurement types, and clear direction on when to use companion tools (chembl_dataframe_describe/query for large result sets, and the condition for spilling needing duckdb). This goes far beyond generic guidance and gives an agent actionable decision rules.

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.