Skip to main content
Glama

Show run history

run_history
Read-onlyIdempotent

Inspect previous optimization runs from disk, newest first, to review state, YAML, key settings, metrics, and data problems without writing anything.

Instructions

Facts of the earlier runs under a folder, newest first, read from the files on disk. Writes nothing.

Use it to see what was tried: state, the YAML of each run, key settings, main metrics. A missing or partial file (no metrics.json, a cut last history line, a broken status.json) is a fact in problems, not an error. CONTRACTS.md section 21.

root: the folder to search (relative paths start at the work folder). Default: the work folder. depth: how many levels of folders to search (default 2: runs/ under the work folder; at most 5). A run folder holds run.json or status.json. A root that is a run folder gives that run. The scan stops after 5000 folders and says so. limit: the newest runs only (default 20). count is the number of runs found, and a note says when older runs are left out. 0 gives all runs. detail: the full facts of each run (all settings, all metrics, which files exist). Each run: name, run_dir, path (relative), state, iteration, iterations, process_alive, modified, yaml_path, yaml_exists, yaml_newer_than_run (the YAML file is newer than the run: it may not be the one that ran), settings (voxel_size_mm, volume_fraction, iterations, solver, filter_radius_mm, n_active, load case names), metrics (compliance_initial and compliance_final, mass_final_g, volume_final_mm3, volume_fraction_final, run_time_s), metrics_source and problems. list_runs is the cheaper list (it reads no metrics).

Input Schema

NameRequiredDescriptionDefault
rootNo
depthNo
limitNo
detailNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds real context beyond them: missing or partial files surface as facts in `problems` rather than errors, the scan caps at 5000 folders and reports it, and `limit` truncation is announced via `count`. It also warns that `yaml_newer_than_run` means the YAML may not be the one that ran.

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?

Front-loaded with the core purpose, then structured per-parameter. It is fairly long because there is no output schema and it enumerates every returned field, which earns most of its space, but the field list is dense enough to border on reference-doc dumping.

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?

No output schema exists, so documenting the return shape is necessary and the description does it field by field (name, run_dir, state, settings, metrics, metrics_source, problems). Combined with the parameter and edge-case coverage, an agent has everything needed to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden and does: root (relative paths resolve from the work folder, default), depth (default 2, max 5, what makes a folder a run folder, run-folder root shortcut), limit (default 20, 0 means all, count semantics), and detail (what extra is included). This is more than the bare schema types convey.

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?

States a specific verb and resource ('facts of earlier runs under a folder, newest first, read from files on disk') and explicitly differentiates itself from the sibling list_runs ('the cheaper list, it reads no metrics'). The agent can pick between run_history and list_runs without opening either 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?

'Use it to see what was tried: state, YAML, key settings, main metrics' gives a clear usage context, and the closing sentence names the cheaper alternative list_runs with the tradeoff. It lacks an explicit 'do not use this when...' exclusion, for example versus compare_runs or run_status, so it stops short of the top band.

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