Skip to main content
Glama

Reactions a compound or protein takes part in (inferred)

get_reactions
Read-onlyIdempotent

Lists the biochemical reactions from Rhea and Human-GEM that a compound is a substrate or product of, or that a protein (enzyme) catalyses or transports, by node id from search_nodes. It lists reactions and does not answer a route question: for "can X become Y" or "what can X become", use reach. Every row is assertion_class 'inferred': a reaction two public databases record, not a result anyone measured in a person. Present these as known biochemistry, never as an effect a compound has, and never as a recommendation. For effects, use find_evidence. Returns total and up to limit reactions (default 10), each with its equation, its participants by side, id and label, the first five enzymes with catalyst_count for all of them, and its source; offset pages the rest, and the default is enough to answer. A page too large for one result is cut to fit, and truncated with next_offset says how to get the rest. A compound flagged is_hub (water, ATP, protons and the like) returns its reaction count only, because it takes part in nearly every reaction. Coverage is one Rhea release and one Human-GEM release; a participant that is not a node in this graph is listed with a null id, and only human enzymes that are nodes are listed. An empty result means no reaction in those releases names this node. That is a complete answer and does not show the body has none.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "node_id": "<node_id>"
    },
    "name": "get_reactions"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoReactions to return (1 to 50). Each carries its participants and enzymes; the default is enough to answer.
offsetNoReactions to skip, to page past limit.
node_idYesA node id in the form PREFIX:local, e.g. CHEBI:16919 (creatine). Get it from the id field of a search_nodes hit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / limit / default
      Previous value: -25New value: +10
    • addedInput schema / properties / limit / description
      Added value: +"Reactions to return (1 to 50). Each carries its participants and enzymes; the default is enough to answer."
    • changedInput schema / properties / node_id / description
      Previous value: -"A node id from search_nodes, e.g. CHEBI:16919 (creatine)."New value: +"A node id in the form PREFIX:local, e.g. CHEBI:16919 (creatine). Get it from the id field of a search_nodes hit."
    • addedInput schema / properties / offset / description
      Added value: +"Reactions to skip, to page past limit."
  2. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +{}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent, but the description adds substantial context beyond them: every row is assertion_class 'inferred' from two public databases, hub compounds (water, ATP) return only a reaction count, oversized pages are truncated with next_offset, non-node participants get null ids, and coverage is pinned to one Rhea and one Human-GEM release. It also warns how the output must be framed (known biochemistry, not an effect or recommendation), which is real behavioral guidance.

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?

Purpose and the reach/find_evidence routing are front-loaded, and nearly every clause carries information. It is dense and long with some run-on sentences, and repeats the 'default is enough to answer' point already in the schema, so it is efficient but not tight.

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?

Covers everything an agent needs for a 3-parameter read tool with no output schema: return shape (equation, participants by side, first five enzymes with catalyst_count, source, total), pagination, truncation, hub-node special case, coverage limits, null ids, and the meaning of an empty result.

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 the baseline is 3; the description goes further by explaining that limit defaults to 10 and suffices, that offset pages the rest, and that truncation yields next_offset. It does not add format detail for node_id beyond the schema's PREFIX:local example, so it is not a 5.

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?

States a specific verb and resource ('Lists the biochemical reactions... that a compound is a substrate or product of, or that a protein catalyses or transports') and names its inputs and scope. It also distinguishes itself from siblings reach and find_evidence, so an agent can select it without opening a schema.

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?

Explicitly says what it does NOT do ('does not answer a route question') and routes those cases to reach, and routes effect questions to find_evidence. When-to-use, when-not, and the alternatives are all named.

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.