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

With no annotations, the description carries the full burden and does so richly: returns a plain `verification_uri`, an email notice is also sent, no code exists in either direction, the user chooses the key's scope on the page, and a 403 outside that scope should be read as scope, not failure. It also discloses the enumeration-resistant behavior (same answer whether or not the address has an account), which an agent could not infer from the schema.

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?

Front-loaded with the imperative 'Use this first' and organized in short paragraphs that each carry a distinct instruction. Some emphasis is repeated for effect ('There is no code... nothing to read out, nothing to type, nothing for you to put in a link'), which is defensible anti-error reinforcement but slightly verbose.

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?

No output schema or annotations exist, so the description must cover returns and lifecycle, and it does: the return value, the asynchronous polling contract with the sibling tool, the status field to watch, and the scoping/403 edge case. Nothing an agent needs to initiate and complete this flow is missing.

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 coverage is 0%, so the description must compensate, and it does for both parameters: `email` is the address on the user's Zeno account, must be asked for rather than guessed, and 'aims' the request so only that owner sees it; `client_name` is the only identifier shown on the approval page and its absence makes the client look unnamed. This is meaning well beyond the untyped string properties.

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 resource: obtain a Zeno API key for the current session via a user-approved flow. It immediately distinguishes itself from siblings by naming `collect_api_key` as the follow-up and `email`/`client_name` as its inputs, so an agent can tell it apart from the many read/write Zeno tools without opening the schema.

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?

Explicit sequencing: 'Use this first', then call `collect_api_key` with the returned `claim_token`, waiting `poll_interval_seconds` until status stops being `pending`. It also names the non-obvious alternative context (every current Zeno user already has an account) and warns not to assume a mistyped address is a missing account.

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