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

Annotations already declare readOnlyHint=false and openWorldHint=false, so the agent knows this mutates platform-side state without reaching outside. The description adds context annotations cannot carry: the call is free, gated by a license, runs against the caller's own Gmail session, and the vendor never holds credentials or sees mail. It does not address the non-idempotent risk (calling twice may open two passes) or pass lifetime, which is the one real behavioral gap.

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 action and its license prerequisite are front-loaded in the first clause, and the rest is framed as return content plus trust posture. Some promotional packaging ('$222 once', 'Free') is tolerable because it tells the agent the call itself costs nothing, but it consumes space that could have covered idempotency.

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 tool with an output schema, the description covers the essential unknowns: prerequisite license, cost, privacy boundary, and what the response runbook contains. Missing only whether repeated calls open duplicate passes and whether a pass expires, which matters given idempotentHint=false.

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 100% for the single license_key parameter, so the baseline is 3 and the schema already explains origin of the key. The description corroborates rather than extends that ('the license key is the gate'), adding only the fact that it was issued once by inbox_clearance_buy.

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 and object: 'Open an Inbox Clearance pass' and names the returned artifact (the pass runbook with 17 elements and 8 settings). It also names the prerequisite sibling inbox_clearance_buy, but it does not distinguish itself from inbox_clearance_record_pass or inbox_clearance_report, so an agent picking among the four inbox_clearance tools still has to infer.

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?

The gate condition is explicit: a perpetual license bought once via inbox_clearance_buy is required, and the license_key parameter is described as 'the gate'. That is clear context for when the call is valid, but there is no when-not guidance and no routing to the sibling tools (record_pass, report) that an agent might confuse it with.

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