Skip to main content
Glama

Reopen or abandon a run

run_status

Change a checklist run's status: reopen it to edit answers or abandon it when the job didn't happen.

Instructions

Move a run back to open so a step can be answered again, or abandon it when the job did not happen. A signed-off run is refused: a signature is the point at which a run stops moving.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
runYesThe run id, e.g. RUN-2026-0001, or its title when only one carries it
dateNoThe day the step happened, YYYY-MM-DD. Default today
noteNoWhy. Kept on the run's history and printed nowhere else
statusYesopen puts a complete run back into edit; abandoned closes it without a signature

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.21.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations present, the description carries disclosure weight. It discloses a key behavioral constraint: a signed-off run is refused because a signature is the stopping point. It also implies the tool mutates state by moving runs between 'open' and 'abandoned'. It does not cover every side effect, but it is meaningful and not misleading.

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 with no filler. The core purpose and the key restriction are front-loaded, and every phrase earns its place. The description reads naturally and is easy to scan.

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?

Despite having no output schema and no annotations, the description explains the two possible state transitions and the critical signed-off exception. It leaves out details like permissions or edge cases, but for an agent selecting this tool among siblings, it is sufficiently contextual to run the operation 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?

Schema coverage is 100% and the parameter descriptions already clarify the run, status, date, and note fields. The description frames the status values with real-world context, but it does not add a substantial amount of meaning beyond what the schema already provides, 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title and description clearly state two specific actions: reopen a run or abandon it. It is easy to distinguish from sibling tools like run_sign_off, run_delete, and run_start because it explicitly describes the conditions under which a run is moved to 'open' or 'abandoned'.

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 gives clear, scenario-based guidance: use it for reopening a run to re-answer steps or abandoning a run when the job did not happen. It also implicitly rules out signed-off runs by stating they are refused. It does not name alternatives by name, but the context is strong and the purpose is not ambiguous.

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