Catalyst evidence graph

Find a compound, outcome or protein

search_nodes

Read-onlyIdempotent

Looks up the node id for a compound, protein, organism or outcome by name or synonym (for example "CoQ10", "caffeine", "CYP1A2", "sleep"). Use it to get the id that get_findings, get_finding, get_relations, get_reactions and reach take; for a question about what a substance does, call find_evidence instead, which needs no id. Returns up to 10 hits, each with id, label, type and the number of findings; hits with findings come first, so the first hit with findings above 0 is usually the one to use. An enzyme or transporter has type protein. It says nothing about a node beyond its id and how many findings it has. If with_findings is 0 the graph holds no findings for the name; the hits may still be the right node for get_relations, get_reactions or reach.

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": {
      "query": "<query>"
    },
    "name": "search_nodes"
  }
}

Input Schema

Name	Required	Description	Default
`query`	Yes	A name, synonym or short phrase, e.g. "CoQ10" or "vitamin D". One substance per call.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

changedInput schema / properties / query / description

Previous value: -"A name, synonym or phrase."New value: +"A name, synonym or short phrase, e.g. \"CoQ10\" or \"vitamin D\". One substance per call."

Changed1 schema field changedOct 4, 2026
- addedInput schema / additionalProperties
```
Added value: +{}
```
First observedOct 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already establish that this is a read-only, idempotent, non-destructive lookup. The description adds information that the annotations do not: that there are at most 10 hits, that they are ordered with finding-bearing hits first, that the first hit with findings above 0 is usually the one to use, and that an enzyme or transporter is reported as type protein. It also sets a clear limit on what the tool reveals, stating that it says nothing about a node beyond its id and finding count.

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 purpose and the main alternative appear in the first two sentences, so the important routing information comes first. The remaining sentences about result ordering and the zero-findings case are useful, though dense; the clause about what the tool does not say about a node could be folded more tightly into the ordering discussion.

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?

Although there is no output schema, the description fully explains the return shape (up to 10 hits with id, label, type and finding count), the ordering rule and the interpretation caveat. For a single-parameter lookup tool, nothing an agent needs in order to call it correctly is missing.

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

Parameters3/5

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

With one parameter at 100% schema coverage, the schema already defines the query's length constraints and gives examples such as "CoQ10" and "vitamin D". The description reinforces the intent to search by name or synonym and provides additional examples, but adds no new syntax or format constraints beyond the structured field.

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 gives a concrete verb and resource: it looks up the node id for a compound, protein, organism or outcome by name or synonym, with examples. It explicitly separates itself from find_evidence, which answers a different question, so an agent can choose between them without opening either 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?

The description states when to use this tool (to obtain the id that get_findings, get_finding, get_relations, get_reactions and reach consume) and names an alternative for a different question type (find_evidence, which needs no id). It also handles the zero-findings case, warning that hits may still be the right node for relation or reaction lookups.

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.