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

Beyond the annotations, the description discloses critical behaviors: the raw key is returned ONCE, the session key has the same access as the caller's key (no privilege change), and billing refusals (BILLING_INACTIVE or MONTHLY_CAP_REACHED) carry a tellHuman sentence that must be relayed to a human. These details are essential for correct handling of the tool's output and failure modes.

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 front-loaded with the core purpose and then flows into proxy usage, key return behavior, and billing refusal instructions. Every sentence adds value, though the capitalized 'PASS IT TO YOUR HUMAN' is slightly emphatic but justified for urgent instruction. It is appropriately sized for a proxy-only tool with nuanced failure modes.

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?

The description covers the tool's identity binding, proxy usage context, one-time key return, access level, and billing failure handling. With no output schema, the mention of the response's tellHuman field provides sufficient return value information. It does not explicitly address the optional parameters beyond labeling, but the schema covers those completely.

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%, so the input schema already documents all three parameters in detail. The description adds only a hint about labeling ('distinctly labeled') but does not explain the autoUpdate or cliVersion parameters. With the schema doing the heavy lifting, a baseline score of 3 is appropriate.

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 specifies the exact action and resource: 'Mint a per-session API key bound to YOUR identity (same org/project/agent)'. It also clarifies this is proxy-only and used at startup. However, it does not explicitly differentiate from the sibling tool mint_harness_key, which could cause confusion for an agent choosing between key-minting tools.

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?

It states when to use this tool: 'The watchdog proxy calls this once at startup and uses the returned key'. It also provides a strong when-not: 'do NOT absorb the refusal and continue with read-only work as if the session were healthy'. But it does not mention alternatives like mint_harness_key, leaving a gap in sibling selection guidance.

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