Jean — Molecular Biology & Genomics

plan_next_tools

Read-only

What can run next, and what each next step would add. Give it a tool whose run just finished (or the output types in hand) and it returns the tools whose own declared inputs those outputs fill, each with the parameter the wire lands on, the question that tool answers, its limits, what grades it, whether it is seeded, asynchronous, writing or leaving the machine, and which of its DECLARED data files the run in hand already read, so a step that would re-read the same table can be told apart.

Input Schema

Name	Required	Description
`after`	No	the tool whose run just finished — its declared outputs are what is in hand. Leave unset and give `output_types` instead.
`_files`	No	The 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.
`_subject`	No	The 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.
`max_steps`	No	longest chain to consider when a `target_type` is given.
`read_only`	No	keep only steps that write nothing.
`target_type`	No	optional: the output type you want to reach. Returns the shortest chains of tools that get there.
`output_types`	No	the port types in hand, when no single tool produced them (`sequence`, `record`, `bands`, `sites`, `protocol`, `matrix`, `series`).

Output Schema

Name	Required	Description
`count`	Yes	how many tools can consume these outputs by their declared types
`paths`	Yes	the shortest chains of tools reaching `target_type`, when one was asked for
`tools`	Yes	the candidates, in catalog order: the parameter each wire lands on, the question that tool answers, its limits, what grades it, and what it reads
`message`	Yes	what was walked, in words
`outputs`	Yes	the types the walk started from
`untyped`	Yes	tools declaring an untyped parameter the builder would let this be wired into — a wire the graph cannot vouch for

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

removedInput schema / properties / independent_only

Removed value: -{
-  "default": false,
-  "description": "keep only steps that read none of the data files the finished run read, so each adds its own evidence.",
-  "type": "boolean"
-}

First observedOct 20, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by enumerating what each returned candidate carries: the wire parameter, the question it answers, its limits, whether it is seeded/asynchronous/writing/off-machine, and whether it would re-read a DECLARED data file already read. It does not describe its own cost or latency, but for a read-only planner this is well above the annotation baseline.

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 purpose is front-loaded in the first clause, which is good. However, the second sentence is a single sprawling run-on that piles a dozen returned-field attributes into one breath, making it harder to parse than a short list would be; trimming would not lose information.

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

Completeness4/5

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

With 7 parameters, a nested _subject object, and an output schema present, the description does the right work: it explains the input modes and characterizes the shape of the returned candidate set without re-specifying the return schema. The only gap is the absence of any guidance on what an empty or ambiguous result means.

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 explains `after`, `output_types`, `target_type`, `max_steps` and `read_only`. The description reinforces the after/output_types either-or and adds the notion that entries are 'wired' to a landing parameter, but it adds no new semantics for max_steps, read_only or _subject that the schema does not already carry.

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 first sentence ('What can run next, and what each next step would add') plus the input contract ('give it a tool whose run just finished or output types in hand') makes clear this is a next-step planner over declared port types. It is distinguishable from neighbours like rank_next_tests or describe_tools, but the description never names those siblings to sharpen the boundary.

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?

It states the entry condition well: supply `after` for a finished run, or `output_types` when no single tool produced them. There is no when-not guidance, no mention of when to prefer this over rank_next_tests or describe_tools, and no note on how target_type/max_steps change the mode of use beyond the schema text.

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 tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?