results_dropDelete a stored result from the current session by its result_id and confirm whether it was removed.
Delete one result stored in this session. Returns whether it was dropped.
| Name | Required | Description | Default |
|---|---|---|---|
| result_id | Yes | A result_id from this session, e.g. r_8c1f0a9d3e |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares a delete ('Delete one result stored in this session'), but the annotations declare readOnlyHint=true and destructiveHint=false. A removal operation is a state mutation, so the description directly contradicts the structured safety profile. It also fails to disclose whether the drop is reversible or what happens on a repeated drop of the same id.
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?
Two short sentences with no filler; the destructive action is front-loaded and the return behavior follows. Nothing is padded or repeated from the schema.
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 no output schema, the description does supply the return signal ('whether it was dropped'), which is useful. But for a deletion tool with contradictory annotations, it omits irreversibility/undo semantics and the behavior of dropping an already-dropped id, leaving real gaps.
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?
There is a single parameter with 100% schema description coverage; the schema already documents the result_id format and example pattern. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.
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 and resource ('Delete one result') plus a scope qualifier ('stored in this session'), which is enough to separate it from results_list/results_query/results_sample. It does not, however, explicitly name or contrast itself with any sibling, so it stops short of a 5.
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 description says what the tool does but never says when to reach for it versus results_list, results_query, results_describe, or results_sample, nor whether the result must be re-created afterwards. No usage context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.