Preview rejecting a submission (no spend)

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

With no annotations, the description carries the burden, and it does disclose a key behavioral trait: 'No network write.' This clearly indicates the tool is non-mutating and safe. However, it doesn't explain what the confirmation token is used for, whether it is returned, or whether any validation occurs, leaving some ambiguity. The description adds useful context beyond the tautological title.

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 description is exceptionally concise: two sentences, each earning its place. It front-loads the core action in the first sentence and adds the critical safety nuance in the second. There is zero waste, making it easy to parse quickly.

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 simple preview tool with no output schema, the description covers the essential no-write guarantee, but it omits what the confirmation token is or what the tool returns. It also doesn't specify any conditions or errors. Given the absence of annotations and output schema, the description is adequate but not fully complete for an agent to know what to expect after invocation.

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 only 33% (only 'reason' is described). The description does not mention any parameters to compensate for the undocumented 'taskId' and 'worker'. While parameter names are self-explanatory, the low schema coverage means the description should provide additional context, but it remains silent, leaving the agent to infer their meanings from the tool name and siblings.

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?

The description clearly states the tool's action: 'Mints a confirmation token for reject_submission.' This specific verb (mints) and resource (confirmation token) directly distinguish it from the sibling reject_submission, which actually performs the rejection. The title reinforces the purpose as a preview with no spend.

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?

Usage is implied through 'No network write' and the title's '(no spend)', suggesting a dry-run before using reject_submission. However, there is no explicit statement like 'Use this to preview before rejecting' or mention of when not to use it. The presence of sibling tools like preview_create_task suggests a family of previews, but the description doesn't explicitly guide the agent to prefer this for validation.

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