Skip to main content
Glama

What a compound can become, and through what (inferred, a hypothesis)

reach
Read-onlyIdempotent

Answers a route question: "can X become Y in the body" (give from_id and to_id) and "what can X become" (give only from_id). Both ids are compound node ids from search_nodes, so a question that names two compounds needs one search_nodes call for each first. It searches the reactions two public databases (Rhea, Human-GEM) record, up to depth steps (1 to 3, default 3), and returns the routes with the reactions and enzymes along each. Every route is assertion_class 'inferred': a hypothesis drawn from reference databases, never a measured or reported effect. Present it as known biochemical connectivity, never as an effect, a recommendation, or a claim that the body actually does this. For measured effects, use find_evidence. Common cofactors and currency species (water, ATP, protons and the like) are not used as intermediate steps, so a route never reads 'reaches everything through ATP'. A currency species given as from_id or to_id returns reachable: null with a coverage note, not a checked 0 routes. With from_id alone it lists up to limit routes (default 10, offset pages the rest); a page too large for one result is cut to fit, and truncated with next_offset says how to get the rest. When no route is found, the coverage field says which of three cases it is: reachability has not been built for this scope yet, so nothing was checked; it was checked and no route exists through the reactions loaded, which does not mean the body cannot make it; or the compound is a currency species and was never searched. The answer is in that one result; another tool does not check it again.

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": {
      "from_id": "<from_id>"
    },
    "name": "reach"
  }
}

Input Schema

NameRequiredDescriptionDefault
depthNoLongest route to consider, in reaction steps (1 to 3).
limitNoRoutes to return when to_id is omitted (1 to 50).
to_idNoA target compound: a compound node id from search_nodes. Omit to list everything from_id reaches.
offsetNoRoutes to skip when to_id is omitted, to page past limit.
from_idYesThe compound to start from: a compound node id from search_nodes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / depth / description
      Previous value: -"Longest route to consider, in reaction steps (1-3)."New value: +"Longest route to consider, in reaction steps (1 to 3)."
    • changedInput schema / properties / from_id / description
      Previous value: -"The compound to start from."New value: +"The compound to start from: a compound node id from search_nodes."
    • changedInput schema / properties / limit / default
      Previous value: -25New value: +10
    • changedInput schema / properties / limit / description
      Previous value: -"Rows to return when to_id is omitted."New value: +"Routes to return when to_id is omitted (1 to 50)."
    • addedInput schema / properties / offset / description
      Added value: +"Routes to skip when to_id is omitted, to page past limit."
    • changedInput schema / properties / to_id / description
      Previous value: -"A target compound. Omit to list everything from_id reaches."New value: +"A target compound: a compound node id from search_nodes. Omit to list everything from_id reaches."
  2. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +{}
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: every route is assertion_class 'inferred' and must never be presented as an effect, cofactor/currency species are excluded as intermediates, a currency species as endpoint returns reachable: null, and truncation is signalled by next_offset. The only thing not spelled out is roughly how large or expensive a depth-3 search is.

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

Conciseness3/5

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

Purpose is front-loaded in the first clause, which is good, but the rest is a single dense paragraph with a repetitive safety passage — the 'inferred, never a measured effect' idea is stated twice in near-identical terms. It remains readable and mostly earns its length, but it could be tightened considerably.

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?

With no output schema, the description still fully covers what comes back: routes with their reactions and enzymes, the assertion_class on every route, the coverage field's three distinct no-route cases, and pagination/truncation behaviour. Nothing an agent needs in order to call it or interpret a null result is missing.

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, but the description adds real meaning above the schema: the presence or absence of to_id switches between a targeted route query and a listing mode, and limit/offset only apply in the listing mode. That mode-switching semantics is not derivable from the field descriptions alone.

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 opening sentence names the specific resource (biochemical routes between compounds) and gives the two invocation modes by name: 'can X become Y' with from_id+to_id, and 'what can X become' with from_id only. It also names the sibling tools it depends on (search_nodes) and the one it is not (find_evidence), so an agent can distinguish it without opening the 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?

Explicit when-to-use for each mode, an explicit when-not ('For measured effects, use find_evidence'), and a prerequisite workflow spelled out: two named compounds require one search_nodes call each first. That is the full when/when-not/alternative set.

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.