Delete multiple test runs at once by providing their IDs. Runs are moved to trash and can be restored later.
Delete multiple test runs. Delete multiple test runs at once in a single request. Specify the test run identifiers you want to delete, and all selected test runs will be moved to the trash. Deleted test runs can be restored later if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| body | 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, openWorldHint=true and non-idempotency, so the safety profile is covered. The description adds genuinely new behavior beyond that: deletions are a soft move to 'the trash' and can be restored later. It does not disclose atomicity/partial-failure behavior, which is the main remaining gap.
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?
The first two sentences say the same thing nearly verbatim ('Delete multiple test runs. Delete multiple test runs at once in a single request.'), which is pure redundancy at the front of the description. The remaining sentences are useful but the padding costs it.
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?
For a destructive batch mutation with no output schema, the description covers the trash/restore lifecycle but omits what happens on invalid or duplicate IDs, whether the operation is all-or-nothing, and what the response contains. Given annotations cover the safety hints, this is adequate but not complete.
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?
One parameter with 0% reported schema description coverage (though the nested 'id' carries a short description). The description compensates by telling the agent to 'specify the test run identifiers you want to delete', clarifying that the body is a list of identifiers, though it adds no details on format or limits.
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?
States a specific verb ('Delete') plus resource ('test runs') and explicitly scopes it to 'multiple... at once in a single request', which cleanly separates it from the sibling delete_test_run (single) and restore_test_run. An agent can route to it without opening the schema.
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?
The batch framing implies when the tool is appropriate, but there is no explicit when-to-use/when-not guidance and no pointer to the alternatives (delete_test_run for single deletion, restore_test_run to undo). It also doesn't state any preconditions such as needing valid, existing IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.