Skip to main content
Glama
Sign In

Jean — Molecular Biology & Genomics

by io.github.genmnz
OverviewDiscussionsAdmin

cancel_research_run

Read-only

Withdraw a research run's pending hypotheses (all of them, or the ones named) so no resume runs them, and return the sealed run file.

Input Schema

NameRequiredDescriptionDefault
runYesthe run file to cancel pending hypotheses in.
_filesNoThe project: record references shaped like _subject. Their records become library documents a tool names in sequences/parts/document; a trace or alignment is found by file name.
reasonNowhy, recorded on each canceled attempt.
_subjectNoThe record to act on: exactly one of sequence, accession (+source), sample (an id from list_samples) or file ({name, text} or {name, base64}); record_index picks one record of several.
hypothesesNothe pending hypotheses to cancel, by id; unset cancels every pending one.

Output Schema

NameRequiredDescriptionDefault
runYesthe whole program as a sealed jane.research-run file: the ledger, every corpus input pinned by SHA-256, the last attempt at each hypothesis. Pass it back to continue
statusYesthe canceled run's status: counts, pending (now none of the canceled), settled and canceled hypotheses
cancelledYesthe hypotheses this call canceled

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / reason / description
      Previous value: -"why, recorded on each cancelled attempt."New value: +"why, recorded on each canceled attempt."
    • changedOutput schema / properties / cancelled / description
      Previous value: -"the hypotheses this call cancelled"New value: +"the hypotheses this call canceled"
    • changedOutput schema / properties / run / description
      Previous value: -"the whole programme as a sealed jane.research-run file: the ledger, every corpus input pinned by SHA-256, the last attempt at each hypothesis. Pass it back to continue"New value: +"the whole program as a sealed jane.research-run file: the ledger, every corpus input pinned by SHA-256, the last attempt at each hypothesis. Pass it back to continue"
    • changedOutput schema / properties / status / description
      Previous value: -"the cancelled run's status: counts, pending (now none of the cancelled), settled and cancelled hypotheses"New value: +"the canceled run's status: counts, pending (now none of the canceled), settled and canceled hypotheses"
  2. First observed

TDQS

B3.1/5.0
Behavior1/5

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

The description says the tool withdraws (mutates) pending hypotheses so they will never run again, while annotations declare readOnlyHint=true and destructiveHint=false. That is a direct conflict about whether state is modified and whether work is irreversibly removed. The description also adds no permission, reversibility, or finality detail that would resolve the conflict.

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?

A single front-loaded sentence with the effect stated first and the scope qualifier in parentheses. Slightly run-on but no wasted clauses.

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?

An output schema exists, so the mention of returning the sealed run file is a bonus rather than a requirement, and the core effect on pending hypotheses is unambiguous for a nested-parameter tool. The main incompleteness is the lack of any statement reconciling the cancel behavior with the read-only annotation.

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 every parameter including `run`, `hypotheses` and `reason` is already documented. The description only restates the hypotheses default ('all of them, or the ones named'), matching what the schema says, and says nothing extra about `reason`, `_files`, or `_subject`.

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?

States a specific verb and resource: 'Withdraw a research run's pending hypotheses (all of them, or the ones named)'. The phrase 'so no resume runs them' implicitly separates it from resume_research_run and research_run_status, though no sibling is named outright.

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 only implied: the agent can infer this is the tool that prevents a run from being resumed. It never states when to prefer it over resume_research_run, research_run_status or list_research_runs, nor what preconditions the run must meet (e.g. whether it must be paused/sealed first).

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

All Jean — Molecular Biology & Genomics toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources