discard_write
Cancel a staged file write by operation ID to drop pending changes before they are applied.
Instructions
Drop a staged write op without applying it.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| op_id | Yes |
Cancel a staged file write by operation ID to drop pending changes before they are applied.
Drop a staged write op without applying it.
| Name | Required | Description | Default |
|---|---|---|---|
| op_id | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies destruction of a staged op, but says nothing about reversibility, whether the op_id must be valid/staged first, what error occurs on an unknown id, or that nothing is written to the target resource. That is a significant gap for an irreversible mutation.
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?
A single front-loaded sentence with no wasted words; the destructive intent leads. It is arguably too terse for a mutation tool, but there is no padding or redundancy.
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?
No annotations, no output schema, one undocumented parameter, and irreversible semantics. The description should at minimum state the required precondition and what the caller gets back or loses; as written an agent cannot confidently invoke it.
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 required parameter exists and schema description coverage is 0%, so the description must compensate — but it never mentions op_id or where to obtain one (e.g., from list_staged or a prior propose_write). The parameter is left entirely to the bare schema type.
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 ('Drop') and resource ('staged write op') plus the key scope qualifier 'without applying it'. An agent can distinguish it from commit_write/propose_write, though it never names a sibling to sharpen the contrast.
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?
'Without applying it' implies this is the abandon path versus commit_write, giving implied usage context. But there is no explicit when-to-use statement, no mention of the alternative revert_write, and no stated prerequisite (e.g., the op must still be staged).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.