Mark a test run as completed using its unique identifier, so you can finalize testing status. Reopen it later if further testing is needed.
Close a test run. Close a test run using its unique identifier, marking it as completed. Closed test runs can be reopened if further testing is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is largely covered. The description adds one genuinely useful behavioral fact not in annotations — that closing is reversible via reopen — but omits valid source states, required permissions, and any side effects.
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?
Three short sentences, front-loaded with the action, and the reopening caveat is placed last where it belongs. Slightly repetitive opening ('Close a test run. Close a test run using its unique identifier') costs it a point.
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?
With annotations present and no output schema, the description covers the action and its reversibility, but for a destructive state mutation it should say which run states are closable and what happens to in-progress results. The nested single-parameter shape is simple enough that this is only a moderate gap.
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% at the top level, but the description compensates partially by saying the run is identified by 'its unique identifier.' The nested path/testRunId structure and its integer type are left to the schema, so this is adequate but not enriching.
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?
Specific verb+resource: 'Close a test run ... marking it as completed.' It clarifies the resulting state, which is more than a restatement of the name. It doesn't explicitly name the sibling open_test_run, though the reopening note gestures at it.
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?
Usage is implied by the note that closed runs can be reopened 'if further testing is needed,' which hints at when to close versus reopen. There is no explicit when-to-use statement, no prerequisites (e.g., which run states can be closed), and open_test_run is never named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.