Catalyst evidence graph

Findings about a node, with their evidence strength

get_findings

Read-onlyIdempotent

Lists the curated study findings for one node by id, from search_nodes: for a compound, organism or material, what it has been shown to affect; for an outcome, which compounds have been studied against it. Use it to browse a node by id. For a question in words, such as "does X help Y", find_evidence answers in one call and needs no id. summary has one row per thing the node has findings about, counted over all its findings and not only the rows returned. The default number of findings, strongest first, is enough to answer. There is no offset: to see a different slice, pass about (an id from summary, or words such as "sleep") or evidence_strength. Each finding carries its evidence strength, one of five named levels from strong to insufficient (strong, moderate, limited, very_limited, insufficient), the verbatim sentence it was drawn from, the paper, the population and dose, and a permalink. An evidence strength says how well the evidence supports the finding and is not a recommendation; give it with the claim, and link the permalink. An empty list means no findings are recorded for that node, a complete answer that does not show the compound does nothing; empty_means says why.

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_findings"
  }
}

Input Schema

Name	Required	Description	Default
`about`	No	Optional: only findings about this, as an id from summary (e.g. CAT:outcome/sleep-onset-latency) or words in its name (e.g. "sleep").
`limit`	No	Findings to return, strongest evidence first (1 to 50). The default is enough to answer.
`detail`	No	brief (default) returns each finding with its claim, evidence strength, design, population, dose, quote, paper, permalink and a citation to quote as it stands. full adds every other recorded field and is longer; use it only when the person asks for all fields.	brief
`node_id`	Yes	A node id in the form PREFIX:local, e.g. CHEBI:16919 (creatine). Get it from the id field of a search_nodes hit.
`evidence_strength`	No	Optional floor: only findings at this evidence strength or stronger, from strong down to insufficient.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 5, 2026

changedInput schema / properties / detail / description

Previous value: -"brief (default): each finding with its claim, evidence strength, design, population, dose, quote, paper, permalink and a ready-to-quote citation. full: every recorded field."New value: +"brief (default) returns each finding with its claim, evidence strength, design, population, dose, quote, paper, permalink and a citation to quote as it stands. full adds every other recorded field and is longer; use it only when the person asks for all fields."

changedInput schema / properties / evidence_strength / description

Previous value: -"Optional floor: return only findings with at least this evidence strength."New value: +"Optional floor: only findings at this evidence strength or stronger, from strong down to insufficient."

changedInput schema / properties / limit / default
```
Previous value: -20New value: +10
```

changedInput schema / properties / limit / description

Previous value: -"Findings to return, strongest evidence first."New value: +"Findings to return, strongest evidence first (1 to 50). 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."

Changed1 schema field changedOct 4, 2026

addedInput schema / properties / detail

Added value: +{
+  "default": "brief",
+  "description": "brief (default): each finding with its claim, evidence strength, design, population, dose, quote, paper, permalink and a ready-to-quote citation. full: every recorded field.",
+  "enum": [
+    "brief",
+    "full"
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 4, 2026

addedInput schema / properties / about

Added value: +{
+  "description": "Optional: only findings about this, as an id from summary (e.g. CAT:outcome/sleep-onset-latency) or words in its name (e.g. \"sleep\").",
+  "maxLength": 80,
+  "minLength": 2,
+  "type": "string"
+}

Changed3 schema fields changedOct 4, 2026

addedInput schema / additionalProperties
```
Added value: +{}
```

addedInput schema / properties / evidence_strength

Added value: +{
+  "description": "Optional floor: return only findings with at least this evidence strength.",
+  "enum": [
+    "strong",
+    "moderate",
+    "limited",
+    "very_limited",
+    "insufficient"
+  ],
+  "type": "string"
+}

changedInput schema / properties / limit / description

Previous value: -"Findings to return, strongest grade first."New value: +"Findings to return, strongest evidence first."

First observedOct 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: no offset exists, the default is strongest-first and usually sufficient, each row carries quote/paper/population/dose/permalink, and an empty list is a meaningful complete answer rather than a null signal. It also warns that evidence strength is not a recommendation and should be given with the claim, which is behavioral guidance an agent cannot infer from annotations.

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 content is front-loaded with purpose and tool routing before return shape and caveats, and nearly every sentence carries decision-relevant information. It runs long and repeats the summary/row-count point in a slightly compressed way, but there is no filler.

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?

There is no output schema, so the description must describe returns, and it does: per-finding fields, the five named strength levels, and the empty-result meaning including an empty_means field. For a five-parameter read tool with a subtle empty-vs-absent semantics, nothing an agent needs to answer correctly 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 baseline is 3, but the description adds real meaning: it explains why 'about' accepts either a summary id or free words, frames 'evidence_strength' as a floor used to pick a different slice in lieu of offset, and clarifies that 'summary' counts over all findings rather than returned rows. The only gap is it does not elaborate on 'detail' beyond what the schema already states.

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 names a specific verb and resource ('Lists the curated study findings for one node by id') and immediately clarifies directionality for both node types (compound/organism/material vs outcome). It also explicitly contrasts itself with find_evidence, so an agent can distinguish it from siblings without opening any 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?

It gives explicit routing: use this tool to browse a node by id, use find_evidence for a question in words that 'needs no id'. It also explains the substitution pattern when the default slice is insufficient ('There is no offset: to see a different slice, pass about ... or evidence_strength'), which is genuine when-to-use guidance rather than a restatement.

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

All Catalyst evidence graph tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.