Skip to main content
Glama
Sign In
reactome-mcp

reactome-mcp

by tc2fh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

find_pathways_for_entity

Find pathways in Reactome that contain a given physical entity. Optionally filter by species or expand to all forms of the entity.

Instructions

Find the lower-level pathways that contain a given physical entity.

The inverse of `list_pathway_events`: given a molecule/complex, which
pathways involve it?

Args:
    stable_id: PhysicalEntity stable id, e.g. "R-HSA-199420".
    species: Optional species name/taxId filter.
    all_forms: If True, also match every other form of the entity (e.g.
        phosphorylated/cleaved variants sharing a ReferenceEntity).

Returns:
    Dict `{count, pathways}` of Pathway records that contain the entity.

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": {
      "stable_id": "<stable_id>"
    },
    "name": "find_pathways_for_entity"
  }
}

Input Schema

NameRequiredDescriptionDefault
speciesNo
all_formsNo
stable_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the query nature ('Find...'), the return structure ('Dict {count, pathways} of Pathway records'), and the optional behavior of `all_forms` ('also match every other form'). It does not explicitly state read-only behavior, but the wording strongly implies a non-mutating search.

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 compact and well-structured. It opens with the core purpose in one sentence, then provides a clear Args/Returns breakdown. Every sentence adds value, and there is no redundant fluff or repetition of schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity (3 parameters, no output schema, no annotations), the description covers the essential context: purpose, relationship to a sibling tool, parameter meanings, and return format. It doesn't enumerate possible error conditions or elaborate on what constitutes a 'Pathway record,' but those are not critical for a query tool of this nature.

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?

Schema description coverage is 0%, so the description must compensate. It does so thoroughly: `stable_id` is given with an example ('R-HSA-199420'), `species` is explained as an optional name/taxId filter, and `all_forms` is defined with the behavioral effect ('match every other form of the entity'). This adds meaning well beyond the bare property titles.

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 clearly states the tool's function: 'Find the lower-level pathways that contain a given physical entity.' It uses a specific verb ('find'), a clear resource ('pathways'), and an explicit entity type ('physical entity'). It also distinguishes itself from the sibling tool `list_pathway_events` by calling itself the 'inverse' of that tool.

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 explicitly identifies when to use this tool: 'given a molecule/complex, which pathways involve it?' It also names the related alternative `list_pathway_events` and states the inverse relationship, giving the agent clear context for selecting this tool over its sibling.

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

Deploy Server

Other Tools