postgrid_cancel_cheque

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes beyond the bare verb by disclosing the status precondition. With no annotations, however, it does not disclose whether cancellation is irreversible or what side effects occur, which would matter for an agent deciding to invoke a destructive operation.

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 the action first and the crucial precondition immediately after. Every word adds information and there is no repetition of schema details.

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 one-parameter operation, the description plus schema is nearly complete. It lacks an explicit statement of what a successful cancellation returns or what error occurs for a non-ready check, but the core invocation context is covered.

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?

The schema already documents id as the 'Cheque ID to cancel' at 100% coverage, so the tool description adds no new parameter meaning. This is the baseline 3 for a fully self-describing schema.

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 the operation ('Cancel') and the specific resource ('a check/cheque') with a concrete lifecycle qualifier, so it is unambiguous and distinguishable from the sibling postgrid_cancel_letter. No confusion about what entity is affected.

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?

Explicitly defines the only valid precondition: check status must be 'ready' before it enters printing. This tells an agent when to call and implies not to call for checks in later states, though it does not name a fallback or how to check status.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.