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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds valuable context beyond annotations: it consumes the user's free allowance, requires authorization and a stable fingerprint, is not idempotent, and that additional reports require purchase. This goes beyond what annotations provide, though it doesn't detail the exact email content or 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?

Four sentences, each carrying distinct information: what the tool does, what it consumes, what it requires, and what it is not. No filler or repetition of schema details. The most important behavioral constraints (non-idempotent, allowance consumption) are front-loaded.

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 tool with no output schema, the description covers the key operational aspects: asynchronous nature, email delivery, quota consumption, non-idempotency, and purchase requirement. It doesn't describe what the user sees immediately (e.g., a request ID or confirmation), but the core invocation context is well covered. The sibling tools are all read-oriented, so the description's emphasis on 'start' and 'new' sufficiently differentiates it.

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 67% (email and fingerprint have descriptions; startupName does not). The description adds context about the fingerprint's purpose ('Persisted caller identifier reused across calls. Never rotate to bypass quotas.') and email's purpose ('User-authorized, non-disposable email for the memo notification.'). The description text reinforces the fingerprint's role in quota enforcement, which is useful. startupName lacks a description, but its meaning is self-evident from the tool name and context.

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 states a specific verb ('Start'), a resource ('asynchronous startup analysis'), and the delivery mechanism ('email the public memo link'). It clearly distinguishes this from sibling tools like get_screening_status or read_startup_memo, which are about reading results rather than initiating a new analysis.

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 description explicitly warns not to repeat while waiting (non-idempotent), notes that additional reports require purchase, and implies this is the tool to use when starting a new analysis. It also mentions prerequisites (authorization and stable fingerprint), giving clear context for when to invoke this tool.

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