List stored run records under a specified work directory to inspect and compare previous Plant Simulation experiments.
List stored run records under a work directory.
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "list_runs"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| work_dir | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it discloses very little: no statement of read-only safety, permissions, ordering, pagination, or what happens when no runs exist. "Stored" weakly implies a non-mutating lookup, but a caller cannot confirm side effects or result size from this text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler, so it is efficient and easy to parse. The brevity is achieved by omission rather than by tight editing, but the sentence itself contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is structurally simple (one optional parameter, no output schema, no nesting), yet the description omits the two things an agent most needs: the default behavior when work_dir is absent and any hint of what a "run record" contains. For a list operation with no output schema and no annotations, that leaves the caller guessing at results and scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter, so the description must carry its meaning; "under a work directory" does loosely map to work_dir and suggests it scopes the listing. However, it never states whether work_dir is optional, what the default scope is when it is omitted, or what form the path takes — exactly the gaps the schema leaves open.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ("List") and resource ("stored run records") plus the scoping dimension ("under a work directory"), so the agent knows this is a read of persisted runs, not a live simulation. It does not distinguish itself from siblings like reproduce_run or run_experiment, leaving the agent to infer that those create or replay runs while this one enumerates them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus reproduce_run, run_experiment, or experiment_summary, and no prerequisites or exclusions. The only implied guidance is that it applies to already-stored runs, which the agent must derive from the word "stored".
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.