reactome-mcp

Official

by reactome

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.4.0
Disambiguation2/5
Multiple tools have unclear boundaries: reactome_get_pathway, reactome_query, and reactome_get_entity all return object details; reactome_pathways_for_entity, reactome_search_pathways_of, and reactome_mapping_pathways overlap heavily; reactome_participants and reactome_participating_physical_entities cover similar ground. Descriptions help somewhat but an agent would struggle to select the right tool.
Naming Consistency4/5
Almost all tools use a consistent reactome_verb_noun snake_case pattern (analyze, get, export, search), and the prefix is uniform. A few noun-phrase names like reactome_entity_component_of and reactome_analysis_found_entities break the pattern, but the convention is largely predictable.
Tool Count1/5
With 56 tools, the surface is extremely large. Many tools are variants (seven search tools, six export tools) that could be consolidated or parameterized, making the server overwhelming and hard to navigate. This far exceeds typical well-scoped MCP servers.
Completeness5/5
The tools cover the full read-only Reactome domain: pathway analysis, entity lookup, hierarchy navigation, exports, interactions, Cypher queries, and metadata. There are no obvious dead ends for common biological query tasks, and all major access patterns are represented.
Average 3.4/5 across 56 of 56 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full behavioral disclosure burden. It does not mention whether this is a read-only lookup, what happens for unmapped identifiers, whether it returns multiple pathways, or any other behavioral traits. This is a notable omission.
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?
The description is a single concise sentence, but it is under-specified. It is not verbose, yet it lacks necessary detail to fully guide an agent. It earns its place as a clear statement of purpose but leaves out important usage and behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a sparse description, the tool is not adequately described for an agent to understand return values, failure modes, or how it fits with siblings. Given the tool's moderate complexity and the large sibling set, the description is incomplete.
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?
Schema coverage is 100% with both parameters (resource and identifier) documented descriptively. The description itself adds no new semantic information beyond the schema, but the schema already handles parameter meaning adequately, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Map') and resource ('an external identifier to Reactome pathways'), which is clear and differentiates from sibling tools like reactome_mapping_reactions (reactions) and reactome_pathways_for_entity (likely Reactome entities). However, it does not explicitly mention alternatives, so it doesn't fully distinguish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools like reactome_pathways_for_entity, reactome_interactor_pathways, and reactome_analyze_identifier, the lack of usage context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states the action without detailing output format, download mechanism, required permissions, or side effects. Minimal behavioral disclosure beyond the one-liner.
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?
Single sentence, no fluff. Front-loaded with action. Lacks extra info but is compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain report contents, output format, and prerequisites. It only provides the basic purpose, leaving questions about what the report contains and how to obtain the file.
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?
Schema covers 100% of parameters with descriptions and defaults, so the schema does the heavy lifting. The description adds no parameter-specific insight beyond what's in the schema, hence baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Generate'), resource ('PDF report'), and subject ('analysis result'). It distinguishes from CSV/JSON exports by mentioning PDF, but does not explicitly differentiate from sibling 'reactome_export_pdf', leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context for when to use this tool versus alternatives. It doesn't mention that it exports analysis reports specifically, nor does it point to CSV/JSON variants for data-oriented outputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'curated interactions' and 'summary', but doesn't explain what the summary contains, whether pagination applies, or any output format. This is a significant gap for a look-up tool.
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?
One concise sentence with no redundancy, front-loaded with the core action. It is efficient, though it borders on under-specification; the single sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity one might argue minimal text is enough, but with no output schema or annotations, the description doesn't clarify what a 'summary' returns. Sibling tools offer many similarly named summaries, so more context is needed to be complete.
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?
The single parameter 'accession' is already fully described in the schema as 'Protein accession' with 100% coverage. The description adds no extra parameter semantics, which matches the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('summary of curated interactions for a protein'). It is clear but does not explicitly distinguish it from sibling tools like reactome_static_interactors or reactome_psicquic_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many interactor-related siblings. The description implies use for curated interaction summaries but doesn't state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Get a summary', which implies a read operation but does not mention return format, pagination, potential errors, limitations, or relationship to other interactor tools. The brevity leaves the agent to guess what a 'summary' contains and how it is delivered.
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 description is a single sentence with no redundancy or filler. It is appropriately sized for a simple 2-parameter tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool, it lacks an output schema and any description of what the summary contains or how it might differ from sibling tools like 'reactome_psicquic_details'. The description is minimal but leaves significant gaps for an agent to understand the tool's role and expected results.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds no semantic information beyond the schema: 'resource' and 'accession' are already described with examples. The phrase 'from a PSICQUIC resource' repeats the parameter description without enriching understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a summary of protein-protein interactions from a PSICQUIC resource' uses a specific verb ('Get') and identifies the resource type (PSICQUIC) and domain (protein-protein interactions). It distinguishes from siblings like 'reactome_psicquic_details' by emphasizing 'summary', though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description gives no context about which scenarios favor a summary over details, static interactors, or other related tools. Sibling names indicate related functionality, but explicit recommendations or exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Search the Reactome knowledgebase.' It does not mention result clustering, pagination, default row count, return format, or any other behavioral traits, which is a significant gap for a search tool with multiple adjustable parameters.
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 a single, front-loaded sentence that clearly states the tool's purpose without any filler. It is appropriately concise for a generic search operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and no output schema or annotations, yet the description is minimal. It does not explain what the search results look like, how pagination works, what the clustering option does, or when to use this tool instead of more specialized search siblings. This leaves significant gaps for an agent to understand the tool's full context.
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?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level meaning, but the schema already documents all seven parameters (query, rows, types, cluster, species, keywords, compartments), so the agent has sufficient information without additional description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: searching the Reactome knowledgebase for multiple entity types (pathways, reactions, proteins, genes, compounds, and other entities). It uses a specific verb and resource, but it does not explicitly distinguish itself from sibling search tools like reactome_search_paginated, reactome_search_suggest, or reactome_search_facets, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many search-related siblings. There is no mention of alternatives, exclusions, or preferred scenarios, leaving the agent to infer appropriate usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 for behavioral disclosure. It only states the tool 'finds' pathways, but does not mention read-only semantics, return format, pagination, or any limitations. The description is too thin to convey meaningful behavioral context.
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 a single, clear sentence that immediately states the tool's purpose. There is no redundant or filler content, making it appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and lacking annotations, the description is incomplete for a tool with four parameters and several close siblings. It does not explain return values, the distinction between direct and indirect containment, or how include_interactors changes behavior, making it hard for an agent to use correctly without additional context.
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?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides. It only references the database ID without elaborating on species, direct_only, or include_interactors, which is acceptable since the schema descriptions are present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds pathways containing a specific entity by database ID, which is specific and informative. However, it does not differentiate from closely related siblings like reactome_pathways_for_entity or reactome_diagram_pathways_for_entity, so it loses a point for missing sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple overlapping siblings, the agent is left without clear selection criteria, so this is essentially missing usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action but omits details such as whether the data is limited to a species, how many interactions are returned, or whether any filters apply.
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 a single sentence that immediately states the tool's purpose without fluff. It adequately covers a simple one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain return structure. It does not, leaving the agent uninformed about the response format or content beyond 'interactions'. Given the low complexity, more detail is expected.
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?
The schema provides 100% parameter coverage, documenting 'accession' as a Protein accession (e.g., UniProt ID). The description does not add extra meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and a specific resource ('curated protein-protein interactions from Reactome's static interactor database'). It is distinguishable from siblings by its focus on the static interactor database, though it doesn't explicitly contrast with other interactor tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like reactome_psicquic_summary or reactome_interactor_summary. There is no mention of use cases, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without describing the response format (e.g., file download vs. URL), authentication requirements, rate limits, or whether the export is a read-only operation. It adds minimal information beyond the tool name.
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?
The description is a single sentence with no wasted words, but it's repetitive with the tool name and lacks any structural context. It is appropriately concise for a simple tool but offers no additional value beyond what the name conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must compensate. It fails to explain what 'complete analysis result' entails, how the JSON is returned, or how it relates to other export and analysis result tools. Given the low complexity, more context should have been provided.
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?
Schema coverage is 100% with descriptions for both 'token' and 'compressed'. The description 'Export complete analysis result as JSON' adds no meaning beyond the schema; it doesn't clarify token requirements or the effect of the compressed flag. Baseline 3 is appropriate because the schema already documents the parameters.
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 uses a specific verb 'Export' with a clear resource 'analysis result' and specifies format 'JSON', which distinguishes it from sibling export tools like reactome_export_analysis_csv and reactome_export_diagram.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. Sibling tools such as reactome_export_analysis_csv and reactome_get_analysis_result exist, but the description doesn't mention them or provide any context for choosing this particular export format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'export an image' and does not mention side effects, read-only nature, error handling, or any constraints. This is a significant gap for a tool with no safety annotations.
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 a single, concise sentence with no fluff or redundancy. It is front-loaded with the verb and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description is too minimal. It does not explain what the output looks like (e.g., binary data, URL), does not differentiate from many sibling export tools, and provides no usage context. This leaves the agent with insufficient information.
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?
Schema description coverage is 100%, so the baseline is 3. The description does not add any extra meaning to the parameters beyond what the schema already provides (e.g., id, format, quality). It neither contradicts nor enhances the schema.
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 states a specific verb ('export'), a specific resource ('reaction diagram'), and the output type ('image'). This clearly distinguishes it from sibling tools like reactome_export_sbgn or reactome_export_pdf, which target different formats or entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as reactome_export_diagram or reactome_export_sbgn. The description lacks any mention of appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure. It only states the general purpose and examples ('complexes, sets'), but does not mention whether results are transitive, what output format to expect, or any edge cases. This is a significant gap for a read tool without an output schema.
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 a single, front-loaded sentence that efficiently communicates the tool's core behavior without unnecessary words. It earns its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description is adequate but minimal. It lacks context on what the output might look like (no output schema) and how it differs from similar siblings. Given the tool's low complexity and full schema coverage, a score of 3 is fair—it is acceptable but leaves room for improvement.
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?
The schema provides 100% coverage for the single parameter 'id' with the description 'Entity stable ID or database ID'. The tool description adds no additional parameter semantics, just restates the entity relationship. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 larger structures (complexes, sets) that contain this entity as a component.' It uses a specific verb and resource, making the purpose obvious. However, it does not explicitly differentiate from the sibling tool 'reactome_complexes_containing', which appears to overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'reactome_complexes_containing' or 'reactome_pathways_for_entity'. With many sibling tools, the description should clarify the intended use case or distinguish it from other containment queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it returns 'detailed information' without describing the response structure, error handling for invalid IDs, or whether the operation is read-only. It does not contradict any annotations (there are none), but it reveals very little beyond the basic action.
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 description is a single, focused sentence with no waste, clearly front-loading the action and resource. It is appropriately sized for a simple retrieval tool, though it could have included a brief note about return format without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, so the description must explain expected return values, but it only says 'detailed information'—vague and unhelpful for an agent attempting to invoke or interpret results. It also doesn't mention behavior for missing entities or pagination. The absence of such details makes it incomplete for a tool with zero structured context beyond the schema.
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?
The schema describes the 'id' parameter well, including a format example (R-HSA-123456) and the fact it can be a database ID, giving 100% schema coverage. The description merely restates 'by its Reactome ID' and adds no extra detail beyond the schema, so it meets the baseline for high coverage without enhancing it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get detailed information about a physical entity' by its Reactome ID, specifying the verb, resource type, and lookup method with helpful examples (protein, complex, compound). However, it does not explicitly differentiate from sibling tools like reactome_get_pathway, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving entity details when you have a Reactome ID, which is a clear context. However, it does not provide explicit guidance on when to choose this over related tools such as reactome_participants or reactome_entity_component_of, and no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 merely restates the tool's action without disclosing any behavioral details, such as required input formats, output structure, pagination, or potential errors. This adds no value beyond the name.
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 description is a single, clear sentence with no wasted words. It is well-structured and front-loaded, making it easy to parse, though slightly minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is too thin. It doesn't explain what 'detailed' means, what the response contains, or any prerequisites like available PSICQUIC resources. It leaves the agent without enough context to fully understand the tool's capabilities.
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?
The input schema covers 100% of parameter descriptions, so the baseline is 3. The description does not add any extra semantics about the parameters, but it doesn't need to given the schema's thoroughness.
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 uses a specific verb 'Get' and identifies the resource as 'detailed protein-protein interactions from a PSICQUIC resource'. The word 'detailed' contrasts with the sibling tool 'reactome_psicquic_summary', clearly differentiating the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as reactome_psicquic_summary or static_interactors. The description only states what it does, not the context in which it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states a read-like operation but does not mention whether it is read-only, what the response structure looks like, pagination, potential errors, or any side effects. This is a significant gap for a tool with no annotation support.
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 a single, concise sentence that is front-loaded with the main verb and object. Every word contributes to the purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain what the distribution looks like or how to interpret the result. It only says 'distribution of pathway sizes (binned)' without specifying the return format, binning behavior, or how 'TOTAL' resource affects output. This is minimal and leaves significant gaps.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions; it does not clarify how parameters interact or provide examples. The schema already explains each parameter, so the description does not need to repeat it.
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 a specific action ('Get') and resource ('distribution of pathway sizes (binned)') derived from an analysis result. It effectively distinguishes this tool from siblings like reactome_top_pathways or reactome_filter_analysis_pathways by focusing on binned size distribution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or contextual scenarios. The description does not mention that it requires an analysis result token or how it fits into a broader analysis workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It only states the high-level outcome and does not disclose return format, pagination behavior, read-only nature, or any error/edge-case behavior.
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 a single, front-loaded sentence that communicates the core function with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the tool returns and how pagination or species comparison works. It gives only the basic purpose and omits expected output structure and behavioral details.
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?
Schema covers 100% of parameters with clear descriptions for species, page, and page_size. The description adds context that the comparison is always against Homo sapiens pathways, but does not provide extra parameter-level detail beyond the schema.
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 operation: compare Homo sapiens pathways against another species to identify orthologous pathways. It clearly states the subject, action, and intended outcome, and this distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like reactome_orthology, or what prerequisites exist (e.g., required species format or comparison direction). The usage context must be inferred from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of disclosing behavioral traits. It does not mention how the PDF is returned (e.g., file download, base64), any file size limitations, authentication needs, or side effects. The lack of any such details for a tool with zero annotation coverage is a significant gap.
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 a single concise sentence that is front-loaded with the action and resource. No wasted words, and it earnestly conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description omits what the agent can expect in return (e.g., a PDF file, download URL, or binary content). With no output schema, this missing information is essential for correct invocation and handling of results.
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?
The only parameter 'id' is already fully described in the schema as 'Pathway or reaction stable ID' (100% coverage). The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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 action (export), the resource (pathway or reaction documentation), and the format (PDF). This distinguishes it from sibling export tools like reactome_export_diagram (diagram format) and reactome_export_sbml (SBML format).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling export tools (diagram, reaction, SBGN, SBML, etc.), the description fails to explain when PDF documentation is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. It only says 'filter' and gives no details about side effects, return value, authorization needs, or whether it modifies the original analysis result. This is a significant gap for a tool that takes a token and pathways list.
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 a single sentence, front-loaded with the verb, and contains no fluff. It is concise and efficiently communicates the core action, though it omits contextual details better suited to other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, no annotations, and four parameters, the description is too sparse. It does not explain what an 'analysis result' is, what the output format will be, or how filtering affects the analysis. Sibling tools provide no clarifying context, leaving the agent without enough information to invoke the tool correctly.
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?
The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds no extra meaning beyond what the schema already provides, neither clarifying token semantics nor the interplay between p_value, resource, and pathways.
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: filtering an analysis result to only include specific pathways. The verb 'filter' is specific, and the resource 'analysis result' is explicit, distinguishing it from sibling tools like reactome_get_analysis_result or reactome_top_pathways.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or workflow context. It simply states the action without indicating how it relates to other analysis tools or when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It fails to mention what the mapping produces (e.g., a list of reaction IDs, a mapping table), what inputs are needed, or any side effects or prerequisites.
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?
A single sentence, directly stating the action and target with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params) and schema covers inputs, but there is no output schema and the description does not explain return values or expected behavior. Given many sibling tools and no annotations, the description is insufficient for a complete understanding.
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?
The input schema describes both parameters with clear examples ('resource' with database names, 'identifier' as external identifier), achieving 100% coverage. The tool description adds no additional parameter meaning, so the baseline score of 3 applies.
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 action ('Map') and the target ('Reactome reactions'), making the tool's purpose unambiguous. It distinguishes itself from the sibling 'reactome_mapping_pathways' by specifying reactions rather than pathways.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool compared to alternatives, such as reactome_mapping_pathways or reactome_pathways_for_entity. No explicit use cases or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full behavioral burden, yet it only describes the semantic scope and not operational details such as return format, pagination, or whether nested complexes are traversed. The examples add context but do not disclose limitations or behaviors.
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 a single focused sentence that conveys the tool's purpose with useful examples and no redundant filler. It is appropriately front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-like tool the description is fairly complete, but the absence of annotations and output schema leaves the agent without information about the response structure or possible limitations. It is adequate for basic selection but not rich enough to fully support invocation.
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?
The input schema already provides complete coverage for the single id parameter, describing it as an entity stable ID or database ID. The description adds only the context that the ID refers to a physical entity, which is marginal beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all other forms of a physical entity, with helpful examples (modified forms, compartments, complexes). It does not explicitly differentiate from sibling tools like reactome_complexes_containing, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when alternate forms of an entity are needed—but provides no explicit guidance on when to prefer it over related tools or when not to use it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It says only 'Export analysis results as CSV files,' which does not clarify whether the operation is read-only, returns a download or inline content, or has any side effects. No details on output format, file size limits, or error behavior are given. This is insufficient for a tool with no annotations.
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 one concise sentence, front-loaded with the action and resource. It contains no filler or redundancy, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers all parameter details, and the description confirms the output format. However, there is no output schema, no annotations, and no explanation of how the CSV is returned (e.g., file download, string). The tool is minimally invocable with the schema, but lacks contextual depth for an agent to fully understand expectations.
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?
The input schema provides 100% coverage of parameter descriptions, including the enum for 'type' and the default for 'resource'. Since the schema already explains each parameter, the description adds no extra semantic value. The baseline of 3 is appropriate given complete schema coverage.
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 action ('Export') and the resource ('analysis results as CSV files'). It distinguishes this tool from sibling export tools like export_sbgn, export_sbml, and export_json by specifying CSV format. The verb and resource are specific and immediately understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., JSON export or analysis result viewers). There is no mention of prerequisites, context, or exclusions. The description merely states what it does, leaving the agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only says 'Get detailed information' without disclosing what 'detailed' includes, the return format, whether any special permissions are required, or any side effects. For a fetch operation, this is a notable gap in setting expectations.
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 a single sentence with a clear verb-object structure. It is front-loaded with the action and resource, contains no redundant phrases, and is appropriately sized for a tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description does not need to be lengthy. However, the phrase 'detailed information' is vague—it does not specify whether the response includes full pathway structure, participants, or just metadata. Given the context of many siblings, a bit more detail would improve completeness, but it is adequate for a basic fetch.
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?
The schema describes the sole parameter 'id' with full coverage (100%), specifying format and examples. The tool description only repeats 'Reactome ID', adding no additional meaning. According to the rubric, the baseline is 3 when schema coverage is high, and there is no extra information to raise it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), a resource ('pathway or reaction'), and the identifier type ('Reactome ID'). It distinguishes from many sibling tools that focus on analysis, export, or querying, but it does not explicitly contrast with close relatives like reactome_get_entity, which could cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: when you need detailed information about a specific pathway/reaction given an ID. However, it provides no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. This is acceptable but not as strong as an explicit recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states that the tool finds pathways based on interactors, but it does not disclose whether this is read-only, what the response format is, how empty results are handled, or any edge cases. The behavioral transparency is limited to the basic query intent.
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 a single, front-loaded sentence that communicates the tool's core purpose without any filler. It is appropriately sized for the tool's simplicity and earns its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema, no annotations), and the description states the primary function. However, it omits details about the return value (e.g., pathway identifiers, names, or metadata) and behavior for proteins with no interactors. This is adequate for selection but not fully complete for understanding expected output.
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?
The input schema has 100% description coverage for the single 'accession' parameter ('Protein accession'). The description adds minimal extra meaning beyond the schema, just clarifying that the protein is the starting point for interactor lookup. Baseline 3 is appropriate because the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find') and names a clear resource (Reactome pathways) scoped by the concept of protein interactors. This distinguishes it from sibling tools like reactome_pathways_for_entity, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need pathways associated with a protein's interactors) but does not explicitly state alternatives, exclusions, or prerequisites. There is no 'Use this when...' guidance, so it relies on the user inferring appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description fails to disclose any behavioral details beyond the action of retrieving. It does not mention return format, potential errors, authentication needs, or whether the operation is read-only. The description is too sparse to provide meaningful behavioral transparency.
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 a single, front-loaded sentence with no redundant words. It communicates the core purpose efficiently and earns its place without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema with full descriptions and no output schema, the description provides a minimal but viable understanding of what the tool does. It tells the agent it returns orthologous events/entities for a species, but omits details about output format or common pitfalls. This is adequate for selection and invocation, but not rich.
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?
Schema description coverage is 100%, with both 'id' and 'species' adequately described in the schema. The description adds no additional parameter semantics, but the schema already covers parameter meaning, so a baseline score of 3 is appropriate.
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 'Get orthologous events or entities in a different species' uses a specific verb ('Get') and identifies a clear resource ('orthologous events or entities') with a scope ('in a different species'). This uniquely distinguishes it from sibling tools like reactome_compare_species or reactome_get_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It only implies its use when orthologs across species are needed, but does not name alternatives or exclusion criteria. No context such as 'use this instead of X' is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only mentions 'lower-level pathways', which hints at a hierarchy but does not disclose behavior such as whether the operation is read-only, how not-found entities are handled, or what the response structure is. The effect of the 'all_forms' parameter is also not described.
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 a single sentence that gets straight to the point, with the verb and resource front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter query tool, the description is minimally sufficient but lacks crucial context: no output schema, no annotations, and no clear differentiation from the many related Reactome tools. The ambiguous term 'lower-level pathways' would benefit from clarification.
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?
The input schema already provides descriptions for both parameters (entity ID and all_forms). The description adds minor context by listing example entity types, but it does not clarify the meaning of 'all_forms' beyond the schema, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Find) and resource (lower-level pathways) that contain a specific entity. It is specific about the input type (protein, gene, compound) but does not distinguish itself from sibling tools like reactome_mapping_pathways or reactome_pathway_ancestors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (when you have a known entity and want pathways that contain it), but it does not explicitly state when to use this tool over alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions 'Returns detailed information' but does not describe the response format, error behavior, or any side effects; being a query tool it is implicitly read-only, but that is not explicit.
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?
Two concise sentences, front-loaded with the action and resource. No redundant filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage this is minimally viable, but the absence of an output schema and lack of any detail about the 'attribute' parameter or return structure leaves some completeness gaps.
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?
Schema coverage is 100% with descriptions for both parameters, so a baseline of 3 applies. The description reinforces the role of 'id' via 'by its identifier' but adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query'), a resource ('Reactome database object'), and a scoping mechanism ('by its identifier'). It clearly states the tool's function, though it does not explicitly differentiate from the similarly generic sibling reactome_get_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Query any Reactome database object by its identifier' implies when to use it (when you have an ID and want object details), but there is no explicit guidance on when not to use it or how it compares to alternative tools like reactome_get_entity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility for behavioral disclosure. It only states the search action and scope but does not disclose output format, pagination, how interactors are handled, limitations, or any authentication or data requirements. This is a significant gap for a tool with no structured behavioral metadata.
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 a single, concise sentence with no filler or redundant information. It is front-loaded with the action and resource, making it quick to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of the tool (three parameters, no output schema, no annotations), the description is sufficient for basic understanding but lacks deeper context about query behavior, return format, or edge cases. The schema provides parameter names and types, but the overall contextual package is thin.
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?
The input schema provides complete descriptions for all three parameters (100% coverage), so the schema already does the heavy lifting. The description adds no additional parameter context, but per the baseline rule, schema coverage high yields a passing score.
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 uses a specific action ('Search for') and a specific resource ('entities within a specific pathway diagram'), clearly distinguishing it from sibling search tools like reactome_search or reactome_search_paginated. The scope is explicit and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative search tools, nor are any prerequisites or exclusions mentioned. The description simply states what it does without contextualizing its use case or contrasting it with available alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavioral traits. It only states 'Get the identifiers' without mentioning output format, pagination, resource filtering behavior, or any side effects. The read-only nature is implied by 'Get' but not explicitly stated, and no other behavioral details are given.
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 a single, concise sentence that immediately states the action and target. It contains no filler or repetition, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with fully described parameters, the description is minimally viable but lacks some context: it does not explain the return format, specify that it is read-only, or provide guidance on when to use this versus related tools. Given no output schema and no annotations, the description could benefit from a bit more detail, but it is not severely incomplete.
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?
The schema descriptions fully cover all three parameters (token, pathway, resource) with clear meanings, achieving 100% schema description coverage. The tool description itself adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 uses a specific verb 'Get' and resource 'identifiers that were found in a specific pathway from an analysis result', clearly distinguishing this from the sibling tool reactome_analysis_not_found (which presumably returns not-found identifiers). The wording is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it requires an analysis token and a specific pathway, and is for retrieving found identifiers. However, it does not explicitly state when to use this tool versus alternatives like reactome_analysis_not_found, nor does it provide any exclusions or prerequisite conditions beyond the implied need for a prior analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description bears the full burden of disclosing behavioral traits. The one-line description mentions only the basic purpose and does not disclose pagination behavior, token requirements, error handling, or the fact that results may be paginated via the page and page_size parameters. This is a significant transparency gap for a tool that accesses analysis data.
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 a single concise sentence that is front-loaded with the verb and object. It contains no unnecessary words and effectively communicates the tool's core function. This is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple interface (3 params, no output schema) and a clear description, so it is mostly complete. However, the description lacks contextual details such as the requirement of a prior analysis, the meaning of 'could not be mapped,' and the complementary relationship with found_entities. Given the sibling tools and the absence of annotations, a slightly richer description would be beneficial.
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?
The input schema already provides descriptions for all three parameters (token, page, page_size), so schema coverage is 100%. The description adds no additional meaning about these parameters beyond the context of 'could not be mapped,' which is already implied. Per rubric, baseline is 3 when schema covers parameters.
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: retrieving identifiers that could not be mapped in an analysis. The verb 'Get' and the specific resource ('list of identifiers') are explicit. It distinguishes itself from sibling tools like reactome_analysis_found_entities, which presumably returns mapped identifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used in the context of an analysis to retrieve unmapped identifiers, but it does not explicitly state when to use it versus alternatives like reactome_analysis_found_entities. No exclusions or alternative suggestions are provided, so the guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It indicates a read-only action ('Get') but does not disclose potential error conditions, side effects, or limitations. The description adds some transparency by clarifying the output is a summary, but it lacks depth for a tool with no annotation support.
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 exactly one sentence, front-loaded with the action, and contains no unnecessary words. It is concise and well-structured for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is adequate but not fully complete. It does not describe the structure or content of the returned 'summary', which could be important for an agent deciding whether this tool meets its needs.
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?
Schema coverage for 'token' is 100% with the description 'Analysis token', fully documenting the parameter. The tool description references 'an analysis' but does not add new meaning or format details beyond the schema. Hence the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'summary of the molecule types (resources) found in an analysis'. This clearly states the tool's purpose and distinguishes it from siblings that return other analysis aspects (e.g., reactome_get_analysis_result, reactome_analysis_found_entities), though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a user needs a summary of molecule types from a given analysis token, but it does not provide explicit guidance on when to prefer it over alternatives or mention prerequisites such as creating an analysis first. The context is self-evident but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states that it returns pathways, omitting important behavioral traits such as default projection to Homo sapiens, the effect of the 'interactors' flag, how species filtering works, error behavior for invalid identifiers, or whether the operation is read-only. This is a meaningful gap given that the tool likely has more nuanced behavior.
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 two short sentences that are front-loaded with the core purpose. It contains no fluff or repetition. Every phrase adds information: 'single' scopes the input, 'pathway enrichment' states the analysis type, and the second sentence clarifies the return. This is an example of efficient, well-structured description writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description provides the basic purpose and return but lacks details about defaults, usage context (singular vs plural), and any caveats. It is minimally adequate but leaves the agent to infer important context from sibling tool names and the schema. The absence of output schema means the description should describe return structure more clearly (e.g., list of pathways or analysis result IDs), which it does only vaguely ('pathways containing this identifier').
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?
Schema description coverage is 100%, so the input schema already documents all four parameters. The description adds no new parameter-level meaning beyond mapping 'single gene/protein identifier' to the 'id' field. It does not clarify the semantics of 'species', 'projection', or 'interactors' beyond the schema descriptions, which are adequate. Thus the baseline of 3 is appropriate.
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 uses a specific verb ('Analyze') and resource ('single gene/protein identifier') with a clear outcome ('pathway enrichment' and 'Returns pathways containing this identifier'). It explicitly says 'single', which distinguishes it from sibling reactome_analyze_identifiers (plural). This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single identifier, but does not explicitly state when to use this tool versus alternatives like reactome_analyze_identifiers or reactome_pathways_for_entity. It provides no exclusion scenarios or context about when projection/interactors settings are useful. The guidance is present only through the word 'single', which is not explicit enough for a tool with many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It only states 'Find all' which implies a read operation returning a collection of complexes, but it does not disclose potential limitations, pagination, output format, or any edge cases (e.g., how partial matches are handled). This is a minimal description that fails to add behavioral context beyond the basic action.
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 a single, front-loaded sentence that immediately communicates the core purpose. Every word is useful, with no fluff or repetition. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with two fully documented parameters, the description is adequate to convey what the tool does. However, with no output schema and no annotations, it leaves the return format and any usage caveats unexplained. It also does not position the tool among its many siblings, so the context is not fully complete. This is not severely deficient but has clear gaps.
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?
Schema description coverage is 100%, with both 'resource' and 'identifier' already explained (e.g., UniProt, ChEBI, Ensembl for resource; P04637 for identifier). The description largely repeats these examples ('e.g., UniProt ID') without adding new semantic meaning. It does not explain how resource and identifier interact or any validation rules, so it adds no value beyond the schema.
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 action ('Find all Reactome complexes'), the resource (Reactome complexes), and the specific scope (containing a specific external identifier). This is a specific verb+resource+scope combination that distinguishes it from sibling tools like reactome_complex_subunits (which returns subunits of a given complex) and reactome_entity_component_of (which finds components of an entity). The example (UniProt ID) further clarifies the input type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you have an external identifier and need complexes containing it. However, it provides no explicit guidance on when not to use it or how it differs from alternatives such as reactome_entity_component_of or reactome_reference_entities. There are no exclusions or alternative tool mentions, so it stops at implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure, but it only states the core lookup behavior. It does not disclose the effect of the 'all_forms' parameter, the structure of the return value, or any limitations, leaving meaningful behavioral context undocumented.
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 two short sentences with no filler. The primary purpose is front-loaded, and every phrase contributes to understanding the tool's function and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple lookup tool with a well-specified schema, but it lacks an explicit comparison to the sibling 'reactome_pathways_for_entity' and does not mention any return format or behavior details, which would be helpful given there is no output schema.
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?
Schema description coverage is 100%, so the schema already documents both parameters ('id' and 'all_forms') with descriptions. The tool description adds no semantic detail beyond 'a specific entity', which is already implied by the parameter name and the first sentence.
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 uses a specific verb ('Find') and clearly identifies the resource ('pathways with diagrams that contain a specific entity'), distinguishing it from the sibling tool 'reactome_pathways_for_entity' by adding the diagram constraint. The phrase 'useful for visualization' reinforces the intended purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'useful for visualization' but does not explicitly state when to prefer this tool over the similar 'reactome_pathways_for_entity' or any other alternatives. There are no exclusions or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It only states a simple list retrieval, but does not mention any side effects, auth requirements, return format, or pagination. For a read-only list tool, a bit more context about the response (e.g., list of disease names/IDs) would be expected.
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 a single, concise sentence that directly states the tool's purpose. Every word earns its place, and there is no padding or redundancy, which is appropriate for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, no output schema), the description is minimally adequate but leaves gaps. It doesn't specify the return format (e.g., list of disease names, IDs, or annotations) or provide any usage context, which would be helpful since there is no output schema to clarify.
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?
The tool has zero parameters, and the schema confirms this. Per the rubric, a baseline of 4 is appropriate when there are no parameters to clarify; the description adds no additional parameter semantics because none exist.
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 'Get the list of diseases annotated in Reactome' uses a specific verb ('Get') and resource ('list of diseases annotated in Reactome'), making the tool's primary function immediately clear. It also distinguishes itself from the many sibling tools that focus on pathways or other entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, with no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states 'Export' but does not clarify whether this is a read-only fetch, what response format is returned (e.g., file download vs. URL), or any side effects. The minimal wording leaves important behavior unspecified.
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 a single, front-loaded sentence with no redundant words. Every word contributes to identifying the tool's purpose without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 optional parameters, no output schema), so the description need not be extensive. However, it lacks contextual detail such as what the 'fireworks' diagram represents and how this differs from other export tools. It is minimally viable but leaves room for clearer context.
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?
Schema description coverage is 100%, with both 'format' and 'species' having their own descriptions in the schema. The tool description adds no extra parameter meaning beyond what the schema already provides, which matches the baseline for high schema coverage.
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 uses a specific verb ('Export') and clearly identifies the resource ('pathway overview (fireworks) diagram') and target ('for a species'). This distinguishes it from sibling export tools like reactome_export_diagram or reactome_export_sbml.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for a species-level fireworks overview) but does not explicitly contrast it with alternatives such as reactome_export_diagram or reactome_export_sbgn. There is no mention of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Export' without detailing behavior such as whether the output is a file download or inline SBML XML, any authentication requirements, or side effects. Since the description carries the full burden for transparency, this lack of disclosure is a significant gap.
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 a single clear sentence that is front-loaded with the action and target. Every word earns its place, with no redundant or vague phrasing. This is appropriately concise for a simple export tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple structure with one well-described parameter, but the lack of an output schema and annotations means the description should explain the return value or output format. It does not, leaving the agent to guess whether SBML content is returned directly or as a download. However, given the low complexity, this is a clear but tolerable gap.
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?
The schema provides 100% coverage for the single parameter 'id', describing it as a 'Pathway or reaction stable ID'. The tool description repeats the same resource types but adds no new semantics. With full schema coverage, the baseline of 3 applies.
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 exports a pathway or reaction to SBML format. The verb 'Export' combined with the specific resource type and output format distinguishes it from other export tools like export_sbgn or export_diagram. This is a precise and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when SBML format is needed, but it does not explicitly compare with alternative export tools such as export_sbgn or export_pdf. There is no mention of when to prefer this tool over others, nor any exclusions or prerequisites. The context is minimal, making it merely adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions filtering and pagination capabilities, which is useful, but does not disclose safety, error handling, rate limits, or the non-mutating nature beyond the word 'Retrieve'. No details on what happens with an invalid token or how results are structured.
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 two sentences, front-loaded with the core action, and contains no redundant information. Every word contributes to understanding the tool's primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The complexity is moderate with 7 parameters and no output schema. The description gives a clear high-level purpose but does not explain the nature of the returned analysis result, possible response fields, or how filtering parameters interact. It is adequate for a simple retrieval but lacks details that would help an agent anticipate output.
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?
The schema provides 100% coverage of all 7 parameters with descriptions, so the baseline is 3. The description adds a high-level mention of 'filtering and pagination' but does not elaborate on individual parameters, leaving the schema to carry the detail.
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 specifies the verb 'Retrieve' and the resource 'previously computed analysis result using its token', making the tool's purpose clear. It distinctly differentiates from sibling tools like reactome_analyze_identifier (which computes new analyses) and export tools (which export results).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previously computed analysis result' implies usage after an analysis has been run, but no explicit guidance is given on when to use this tool versus alternatives like export_analysis_csv or top_pathways. It does not state exclusions or alternatives, only a general context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful behavioral context by specifying that only molecules directly involved in reactions are returned, implying exclusion of nested components. However, it does not disclose any side effects (though likely read-only), pagination, or limitations, leaving some gaps in expected behavior.
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 a single, front-loaded sentence that clearly conveys the tool's purpose. It avoids redundancy and every word contributes to understanding, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is adequate but not fully complete. It explains the main function but does not describe the response format or clarify how it differs from similar-sounding tools in the environment, leaving some ambiguity for an agent deciding between options.
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?
The input schema already provides a description for 'id' as 'Event stable ID or database ID', and the tool description adds minimal extra meaning beyond reiterating the event context. Since schema coverage is 100%, the baseline of 3 is appropriate; the description does not enhance parameter understanding further.
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 uses a specific verb ('Get') and clear resource ('physical entities participating in an event'), with a parenthetical clarification ('molecules directly involved in reactions') that disambiguates the scope. It distinguishes itself from broader tools like reactome_get_entity by focusing on participants of a single event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as 'reactome_participants' or 'reactome_entity_component_of'. It does not mention exclusions, preconditions, or contextual scenarios, leaving the agent to infer usage solely from the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does not clarify whether 'contained' means direct children or all descendants, how events are structured in the response, or any limitations such as return size or error conditions. The description adds minimal context beyond the tool's basic purpose.
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 a single concise sentence that is front-loaded with the action and resource. It contains no wasted words and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description is adequate but not fully complete. It lacks explicit clarification of 'contained' (direct vs. all descendants) and the return structure, especially since there is no output schema. The ambiguity between this and reactome_events_hierarchy leaves room for misinterpretation.
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?
Schema coverage is 100% for the single parameter 'id', which is described as 'Pathway stable ID or database ID'. The description adds no additional semantic detail about the parameter, such as accepted formats or examples, so it meets the neutral baseline for high schema coverage.
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 uses a specific verb ('Get') and resource ('events contained within a pathway'), and defines events as sub-pathways and reactions. This clearly distinguishes it from sibling tools like reactome_get_pathway and reactome_pathway_ancestors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'contained within a pathway' implies the tool is used to retrieve child events of a pathway, but there is no explicit guidance on when to use this over siblings like reactome_events_hierarchy or reactome_pathway_ancestors. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavioral traits. It implies a read operation by using 'Get' and clarifies the return type as external database references. However, it does not mention potential errors, permissions, pagination, or what the output structure looks like, leaving the agent with limited behavioral context.
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?
Single sentence, front-loaded with the core action, no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is adequate but lacks usage context and behavioral caveats. It provides the core purpose but not enough to fully guide selection among many similar sibling tools.
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?
The input schema has one parameter 'id' with a clear description ('Event stable ID or database ID'), and the schema coverage is 100%. The description adds minor reinforcement by tying the parameter to 'participants in an event' but does not provide additional semantic depth beyond the schema.
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 uses a specific verb ('Get') and clearly identifies the resource ('all reference entities (external database references)') and the scope ('for participants in an event'). This distinguishes it from sibling tools like reactome_participants and reactome_participating_physical_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description simply states what the tool does without specifying use cases or exclusions. Given the large set of sibling tools, this lack of guidance is a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. The description merely restates the function without adding context about output format, the effect of the main_only flag, or any other behavioral traits. This is essentially a tautology of the tool name.
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 a single sentence with no wasted words. It is immediately clear and well-structured for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is adequate but has gaps: there is no output schema, and the description does not explain the return value format or the behavior of the main_only flag. For a minimal read-only list tool, this is sufficient but not comprehensive.
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?
The input schema has 100% coverage for main_only, so the baseline is 3. The description adds no additional meaning about the parameter beyond what the schema already provides; it does not mention the parameter at all.
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 'Get the list of species available in Reactome' clearly states a specific verb and resource. It distinguishes the tool from sibling tools like reactome_compare_species, which performs a different operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving species, but it provides no explicit guidance on when to use this tool versus alternatives such as reactome_compare_species or reactome_database_info. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that the tool retrieves root pathways and gives examples; it does not disclose the return format, default species behavior, error handling, or any potential side effects. While the action is simple and non-destructive, the lack of additional behavioral context leaves significant gaps for the agent.
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 highly concise, consisting of two sentences that provide essential information and helpful examples. Every word serves a purpose, and the structure is front-loaded with the primary action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the core purpose but misses some contextual details. It does not mention that the species parameter is optional with a default, nor does it describe the return structure. The absence of behavioral transparency also reduces completeness, but the description is minimally sufficient for an agent to understand the tool's main function.
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?
The input schema fully describes the single 'species' parameter with its default value and type, achieving 100% schema coverage. The tool description adds no additional meaning beyond restating that it operates 'for a species.' With full schema coverage, the baseline score of 3 is appropriate.
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 with a specific verb and resource: 'Get all top-level (root) pathways for a species.' It also provides concrete examples ('Immune System', 'Metabolism') to illustrate the meaning of 'top-level (root) pathways.' This effectively distinguishes it from sibling tools like reactome_events_hierarchy or reactome_get_pathway.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when needing top-level pathway categories for a species), but it does not explicitly address alternatives or exclusion criteria. It does not mention any sibling tools, leaving the agent to infer the tool's specific role from the description alone. This is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility. It discloses the scope ('reaction or pathway') and the types of participants but does not mention return format, hierarchy traversal, or error behavior. For a straightforward read operation, the transparency is adequate but not rich.
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 a single, front-loaded sentence with no filler. The parenthetical list efficiently adds detail about participant types without redundancy.
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 simplicity of the tool (one parameter, no output schema), the description adequately conveys what is returned and the scope of the query. However, it could mention whether the result is limited to direct participants or includes nested elements, but this is not essential for a basic retrieval.
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?
The input schema already provides 100% coverage with a clear description of the 'id' parameter. The tool description adds no additional parameter semantics beyond what the schema documents. Baseline 3 applies due to full schema coverage.
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 uses a specific verb ('Get') and resource ('molecular participants') and clearly enumerates the participant roles (inputs, outputs, catalysts, regulators). It explicitly scopes to reactions or pathways, distinguishing it from sibling tools like reactome_participating_physical_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description simply states what it returns, with no mention of when to choose it over siblings such as reactome_participating_physical_entities or reactome_get_pathway. No prerequisites or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It states the operation is a 'List' (implying read-only), but does not mention output format, pagination, authentication, or network dependencies, providing minimal additional context beyond the tool name.
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 a single, front-loaded sentence that states the action and resource with no unnecessary words. It earns its place efficiently.
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?
For a parameterless list tool, the description gives enough information to understand the tool's purpose. However, it lacks any mention of the return payload or behavior specifics, though given the low complexity and absent output schema, this is a minor gap.
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?
The tool has zero parameters, and the schema is an empty object, so the description need not explain param syntax. The baseline is 4 for tools with no parameters.
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 uses the specific verb 'List' and names the resource 'PSICQUIC registry services for protein-protein interaction data,' clearly distinguishing it from sibling tools like reactome_psicquic_summary and reactome_psicquic_details, which focus on details or summaries rather than listing registries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description neither mentions exclusions nor points to other Reactome tools, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It only states 'pagination support,' which is already implied by the tool name. It does not mention return format, defaults behavior, or any read-only or error traits.
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 a single, front-loaded sentence that conveys the core function and key differentiator without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, and no annotations are provided. The description only mentions pagination, leaving the agent uninformed about response structure, result content, or usage limitations—significant gaps for a search tool.
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?
Schema description coverage is 100%, with all 5 parameters having descriptions. The description's mention of pagination reinforces the purpose of 'page' and 'rows_per_page' but adds no significant meaning beyond the schema, so the baseline 3 is appropriate.
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 searches Reactome with pagination support, distinguishing it from sibling reactome_search. The verb 'search' and resource 'Reactome' are specific, and the pagination mention adds scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for browsing large result sets ('with pagination support for browsing through large result sets'), providing clear context. However, it does not explicitly name alternative tools like reactome_search, so no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It explains that the tool returns facets globally or per query, but does not disclose what the return structure looks like, any rate limits, or explicitly confirm read-only behavior. For a simple getter, this is adequate but not rich.
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 a single concise sentence that conveys the purpose, scope, and optionality. It contains no fluff and is front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema), and the description covers its core behavior. However, without an output schema, the description should ideally explain the shape of the returned facets or how they can be used. This gap prevents a higher score.
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?
Schema description coverage is 100%, so the baseline is 3. The parameter 'query' is already described in the schema as 'Search term (optional, returns global facets if omitted)'. The tool description adds no new meaning beyond the schema, thus no bonus is warranted.
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: 'Get available facets (filters) for search results, either globally or for a specific query.' It uses a specific verb ('Get') and resource ('facets for search results'), and distinguishes itself from sibling search tools by focusing on metadata (facets) rather than actual search results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context – it can be called without a query for global facets or with a query for query-specific facets. However, it does not explicitly state when to prefer this tool over other search-related siblings (e.g., reactome_search, reactome_search_paginated) or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 of disclosing behavior. The verb 'get' suggests a read-only, non-destructive operation, but the description does not explicitly state that it is safe, nor does it describe any limitations, rate limits, or what kind of suggestions are returned. It adds minimal value beyond the basic action.
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 a single, focused sentence that states the tool's purpose without any fluff or redundancy. Every word contributes to understanding, earning top marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description provides a basic understanding but lacks details about return values, suggestion format, or how results should be interpreted. It is minimally sufficient but leaves room for clarification about what the spell-check suggestions actually contain.
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?
The input schema already fully documents the only parameter 'query' as a 'Search term to check' with a maxLength. The description adds no additional semantic detail beyond this, so the high schema coverage (100%) keeps the score at baseline 3.
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 uses a specific verb ('Get') and clearly identifies the resource ('spell-check suggestions for a search query'). It distinguishes this tool from sibling search tools like reactome_search_suggest by focusing specifically on spell-checking, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to obtain spelling corrections for a search query, but it does not explicitly state when to use it versus other sibling search tools, nor does it mention any exclusions or prerequisites. It gives only implied usage context with no alternatives or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the burden. It discloses the output (over-represented pathways sorted by p-value) and implies a read-only analysis, but does not discuss error handling, invalid identifiers, or other behavioral traits. It provides some context but lacks depth for a no-annotation tool.
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 two sentences, front-loaded with the main purpose and then the output. Every word earns its place, with no filler or redundancy.
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?
For a straightforward analysis tool with full schema coverage and no output schema, the description adequately states what it returns. It could mention the effect of p_value_threshold or how to interpret results, but it is sufficiently complete for basic use.
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?
The input schema has 100% coverage with descriptions for all 5 parameters, so the baseline is 3. The description adds marginal value by clarifying that identifiers are gene/protein identifiers, but does not go beyond what the schema already provides for other parameters.
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 performs pathway enrichment analysis on a list of identifiers and returns over-represented pathways sorted by p-value. It uses a specific verb and resource, and distinguishes from the sibling reactome_analyze_identifier by specifying 'list of gene/protein identifiers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a list of identifiers and want enrichment analysis, but it does not explicitly mention when to use this over alternatives like reactome_analyze_identifier or other analysis tools. There is no exclusion or alternative naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds a valuable detail: recursive retrieval of nested complexes. But it does not describe the return format, any limits, or potential performance implications, leaving notable gaps.
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 two concise sentences, front-loaded with the action and resource, and every word adds value. 'Recursively retrieves components of nested complexes' provides key behavior without fluff.
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?
For a simple one-parameter read-only tool with no output schema, the description covers the core purpose and an important behavioral nuance (recursive retrieval). It lacks return value details and usage comparisons, but these are not critical given the tool's simplicity.
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?
Schema coverage is 100% with the parameter 'id' described as 'Complex stable ID or database ID'. The description adds no additional semantic detail beyond what the schema already provides, so the baseline score of 3 applies.
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 verb 'Get' and the resource 'subunits (components) of a complex', making the purpose unambiguous. It also differentiates from sibling tools like reactome_complexes_containing by focusing on the complex's own contents, not the complexes that contain an entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: use this when you need all subunits of a complex. However, it offers no explicit guidance on when to use it versus similar siblings like reactome_entity_component_of or reactome_participants, and no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It is a simple read-only info retrieval tool, so the minimal description may be sufficient, but it does not disclose anything about response format, potential errors, or network behavior. This is a minimum viable level of transparency.
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 a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded with the key information and contains no unnecessary words or repetition. This is an ideal level of conciseness.
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?
For a tool with no parameters and no output schema, the description is mostly complete: it names the exact information returned (version and name). However, it does not specify the structure of the response (e.g., whether it is a JSON object, string, etc.). While not critical for such a simple tool, a little more detail on return format would make it fully complete.
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?
The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameter semantics, and the schema already confirms there are no properties. No additional parameter-related information is needed.
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: retrieving Reactome database version and name information. It uses a specific verb ('Get') and resource ('Reactome database version and name information'), making it distinct from sibling tools that focus on analysis, pathways, export, or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does, but it does not mention any prerequisites, exclusions, or alternative tools for similar purposes. The usage context must be inferred by the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns a download URL, which is useful. However, it does not state whether the operation is read-only, URL expiration, or error handling, leaving some behavioral aspects unspecified.
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 two concise sentences with no filler. It accurately states the action and output without unnecessary detail.
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?
The schema is comprehensive and the description covers the core function and return type. Given the tool's simplicity, this is sufficient, though it could benefit from a brief note on which format to choose or how quality affects output, but the schema already handles those details.
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?
The schema already provides descriptions for all 5 parameters with 100% coverage, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides.
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 exports a pathway diagram as an image and returns a URL. This distinguishes it from sibling export tools that handle SBGN, SBML, PDF, or analysis reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies usage for image exports, but there is no explicit guidance on when to choose this over other export tools. No alternatives or exclusions are mentioned, which would be helpful given the many sibling export tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the export action and format, but does not disclose whether the result is a file, a string, or generated asynchronously, nor any side effects or permissions. This is minimal behavioral disclosure.
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 a single, front-loaded sentence with no redundant words. It efficiently states the action, resource, and output format.
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?
For a low-complexity tool with one well-documented parameter, the description is mostly sufficient: it identifies the input and the output format. However, without an output schema or annotations, some return-value details are missing, but this is partially mitigated by the simple nature of the export operation.
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?
The schema already fully describes the single 'id' parameter as a 'Pathway or reaction stable ID', and the description repeats that same context. With 100% schema coverage, the description adds no additional parameter semantics beyond the tool's output format.
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 uses a specific verb ('Export') with a clear resource ('a pathway or reaction') and a specific output format ('SBGN XML'). It distinguishes this tool from siblings like export_sbml or export_pdf by format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is used when SBGN XML output is needed, but it does not explicitly mention when not to use it or contrast it with alternative export tools. This is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It clearly indicates a read-only look-up of suggestions, but gives no additional details such as result limits, ordering, or any side effects. This is minimally adequate but not rich.
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 one short sentence that directly and efficiently communicates the purpose. No filler or redundant content.
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?
For a simple autocomplete tool with one parameter and no output schema, the description is sufficient. It could explain what type of output to expect, but the low complexity reduces the requirement. Overall, it performs adequately.
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?
The single parameter 'query' is fully described in the schema as 'Partial search term', providing 100% coverage. The description adds no new meaning beyond the schema, so the baseline score of 3 applies.
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: 'Get auto-complete suggestions for a search query.' The verb 'Get' plus the specific resource 'auto-complete suggestions' distinguishes it from sibling search tools like reactome_search and reactome_search_spellcheck.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for autocomplete/typeahead scenarios but does not explicitly state when to use this tool versus the other search-related siblings. No exclusions or alternatives are mentioned, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states it returns a 'small sample' of nodes, which conveys the read-only, limited nature of the operation. However, it does not disclose behaviors like randomness, error handling for non-existent labels, or whether the returned nodes are representative in any particular way. These gaps are notable but not critical for a simple sampling tool.
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 a single, well-structured sentence that delivers the key information upfront: 'Return a small sample of nodes for a given label, to inspect shape and typical property values.' No wasted words or redundant details.
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?
The tool is simple, with only two parameters and no output schema. The description sufficiently explains the tool's purpose and output ('nodes') while the schema covers parameter details. It is complete enough for an agent to understand what to expect, though it could mention that the sample is intended for quick data inspection rather than querying.
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?
The input schema provides descriptions for both parameters (label and limit), so schema coverage is 100%. The description adds minimal extra meaning beyond saying 'given label' and 'small sample', which aligns with the parameters. It does not introduce any new parameter-specific semantics, so a baseline score of 3 is appropriate.
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 with a specific verb ('Return') and resource ('nodes for a given label'), and adds the purpose ('to inspect shape and typical property values'). This effectively distinguishes it from sibling tools like reactome_cypher_query (which runs arbitrary queries) and reactome_cypher_schema (which returns schema).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to inspect the shape and typical values of nodes for a label. It provides a clear context but does not explicitly name alternatives or state when not to use it. However, the purpose is clear enough for an agent to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds a useful warning that the return structure is large, but it does not disclose other behavioral aspects like response format, performance implications, or read-only status beyond the verb 'Get'.
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?
Two sentences, front-loaded with purpose, followed by a concise warning. Every word earns its place, with no redundancy or filler.
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?
For a simple one-parameter tool with no output schema, the description adequately covers what the tool returns (full event hierarchy) and warns about the large payload. It lacks explicit output structure details but is sufficient for the tool's complexity.
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?
The input schema already provides 100% coverage for the single 'species' parameter, including a default and description. The description merely mentions 'for a species', adding no significant semantic detail beyond the schema.
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 states a specific verb ('Get') and resource ('complete event hierarchy'), clarifying it returns the full pathways and reactions tree for a species. This distinguishes it from sibling tools that focus on single pathways or ancestors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates when to use: when you need the complete event hierarchy for a species. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 correctly implies a read-only operation ('Get') and describes the purpose, but it does not disclose output format, whether it returns just IDs or full objects, or if any special input validation applies. This is adequate for a simple read-only tool but lacks depth.
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 exactly two sentences, both front-loaded and free of filler. It delivers the essential purpose and contextual outcome without redundancy.
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?
For a tool with one parameter and no output schema, the description provides enough context for an agent to select it: it names the resource type (pathways or reactions), the relationship type (ancestors), and the use case (fitting into broader structure). It might benefit from specifying the return shape (e.g., list of ancestor IDs), but overall it's sufficiently complete for its simplicity.
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% for the single parameter 'id', which already describes it as 'Reactome stable ID or database ID'. The description adds value by clarifying that the id can refer to an 'event (pathway or reaction)', which is not explicitly stated in the schema. This extra semantic context helps the agent choose appropriate input values.
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 retrieves the 'ancestor pathway hierarchy for an event', using specific verbs and resource scope. It distinguishes from siblings like 'reactome_pathway_contained_events' (which goes downward) and 'reactome_events_hierarchy' (which may be general hierarchy) by emphasizing 'ancestors'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context ('Shows how a pathway fits into the broader Reactome structure') but provides no explicit when-to-use/when-not-to-use guidance or alternatives. For example, it doesn't mention that 'reactome_events_hierarchy' might be used for differently structured queries or that this tool is for direct lineage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It thoroughly discloses read-only enforcement, rejected APOC write procedures, row/size caps, and query timeout, which is exactly the kind of behavioral detail an agent needs.
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 uses five sentences, each adding critical safety or usage information, without redundant fluff. It front-loads the core action and then layers constraints logically.
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?
For a raw Cypher tool with no output schema, the description covers input constraints, safety, and practical guidance. It does not detail error responses, but given the unpredictable nature of Cypher results, the provided information is comprehensive enough.
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?
The schema already documents all five parameters with descriptions (100% coverage). The description adds value by connecting the caps to query design and introducing the timeout behavior, which goes slightly beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Run a Cypher query against the local Reactome Neo4j graph database,' clearly identifying the tool's verb and resource. It does not explicitly distinguish from sibling tools like reactome_cypher_schema or reactome_query, but the specificity of the action makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about read-only mode and result caps, and explicitly advises 'Use LIMIT and project specific fields in your query for large results.' It does not name alternatives or state when not to use this tool, but the context is sufficient for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and does it well. It discloses that the data is 'fetched live from the database via APOC on first call,' cached in-memory for the session, and has a '~100–300 ms one-time' cost. This gives the agent essential behavioral expectations about performance and side effects (no mention of writes, indicating read-only).
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 three sentences, each earning its place: the first defines the tool's output, the second covers performance/caching semantics, and the third gives usage timing plus a pointer for full JSON. No filler or redundancy—excellent conciseness and front-loading.
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?
Despite having no output schema, the description provides a detailed enumeration of the returned data (labels, relationship types, cardinalities, property types, mandatory flags, indexes, and constraints). It also explains how the data is fetched and cached, and when to call it. This is sufficient for an agent to decide when to invoke it and what to expect, especially given the tool has no parameters.
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?
With zero parameters, the input schema is trivially covered (100%), so the description need not explain parameter syntax. The baseline of 4 applies, and the description adds no unnecessary param info while correctly focusing on the tool's output and behavior.
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 uses a specific verb 'Introspect' with a clear resource ('Reactome graph schema') and enumerates the exact content delivered: labels with counts, relationship types with cardinalities, property types, mandatory flags, indexes, and constraints. This clearly distinguishes it from sibling tools like reactome_cypher_query and reactome_cypher_sample, which focus on querying data rather than schema inspection.
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 guidance is given: 'Call this before writing Cypher.' This tells the agent exactly when to invoke this tool. Additionally, it provides an alternative for a different need: 'For the full JSON... read the reactome://graph/schema resource.' This is clear, actionable, and distinguishes when to use the tool versus another resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![reactome-mcp MCP server](https://glama.ai/mcp/servers/reactome/reactome-mcp/badges/card.svg)](https://glama.ai/mcp/servers/reactome/reactome-mcp)

Score Badge

Copy to your README.md:

[![reactome-mcp MCP server](https://glama.ai/mcp/servers/reactome/reactome-mcp/badges/score.svg)](https://glama.ai/mcp/servers/reactome/reactome-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/reactome/reactome-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server