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

Annotations already declare destructiveHint:true, openWorldHint:true, and readOnlyHint:false, establishing it's a write operation with real-world consequences. The description adds concrete behavioral context beyond annotations: postage/handling charges, the prohibition against repeating the forwarding address, the idempotency retry guarantee, and the confirmation boundary. It doesn't explain what specifically gets destroyed or reversed, but for a real-world forwarding action, the privacy and financial warnings are valuable additions.

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 dense and packs multiple constraints into a single flow, but it front-loads the core action well. Some sentences repeat information already implied by annotations (e.g., the confirmation boundary) and the prerequisite sentence is somewhat tautological ('every prerequisite stated above'). It's efficient but could be better structured with explicit parameter guidance.

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?

Given no output schema and an open-world destructive operation, the description covers the safety-critical aspects (confirmation, idempotency, privacy, billing). However, it doesn't explain what the tool returns, how long forwarding takes, or the meaning of 'default address' and 'secure browser flow' in Corply's context. For a 6-parameter tool with nested objects, there are gaps in parameter semantics and return expectations.

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 17%, so the description must compensate for undocumented parameters. The description supplies semantics for 'confirm' (fresh founder confirmation), 'idempotencyKey' (stable, enables safe retries), and indirectly 'mailItemId' (one exact mail item), but doesn't address 'companyId', 'serviceLevel', or the nested '_corply_context' object. With 6 parameters and most undocumented in the schema, the description leaves significant gaps.

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 (queue physical forwarding) and resource (one exact mail item), distinguishing it from siblings like request_mail_scan and request_mail_shred. The phrase 'one exact mail item' and the secure browser flow location give strong clarity, though the default address mechanism is somewhat abstract.

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 states when to use it (after fresh founder confirmation, with confirm:true and idempotencyKey) and prerequisites (authenticated active company access). However, it doesn't name alternative tools like request_mail_scan or explicitly say when NOT to use this vs other mail actions.

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