Discard a drafted accrual before posting, recording the reason while keeping the row as discarded. Use reversing entries for accruals already posted.
Retire a drafted Abgrenzung before it posts. The row stays on record as discarded with its reason; a posted accrual cannot be discarded (already_posted), reverse it instead.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| accrualId | Yes | ||
| workspaceId | Yes | ||
| idempotencyKey | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, but the description adds real substance: the row is retained as `discarded` with its reason, and the failure mode surfaces as `already_posted`. That tells the agent the outcome is a soft state transition, not a delete, and what error to expect.
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 tight sentences with the action and precondition front-loaded, then the outcome and error case. Every clause carries information an agent needs.
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 output schema, so the description correctly explains the resulting state and error code, and it routes the mis-case to the right sibling. The remaining gap is parameter-level detail (notably idempotencyKey behavior) rather than tool behavior.
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% and the description only implicitly explains one of four parameters (the reason string being persisted on the discarded row). accrualId, workspaceId, and especially idempotencyKey — whose semantics matter for a retryable mutation — are undocumented in both schema and description.
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 ('Retire') plus specific resource ('a drafted Abgrenzung before it posts'), and it explicitly separates this from accrual_reverse / accrual_post by naming the post-state boundary. An agent can identify the tool from the description alone.
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?
States the precondition (drafted, not yet posted), the exclusion (a posted accrual cannot be discarded), and names the correct alternative for that case ('reverse it instead'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.