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

With no annotations provided, the description carries the full behavioral burden. It discloses the critical consent rule ('never guess or reuse an address'), the weekly re-audit behavior when weekly is true, and the one-click unsubscribe property. This gives the agent the safety-relevant context needed to invoke the tool appropriately.

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 overly repetitive. 'Email the full written SEO/AEO report for an audit this session already ran' largely duplicates the first sentence, 'ONLY use an email address the user explicitly gave you' repeats the earlier consent warning, and 'Offer this after presenting audit results' restates 'ALWAYS OFFER THIS after running an audit.' The content is good but could be condensed to roughly half its length.

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 three-parameter tool with no output schema and no annotations, this description is complete. It explains when to use it, where the audit_id comes from, how to handle the email address, and what weekly mode does. The agent has enough information to call the tool correctly and safely.

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 baseline is 3. The description adds value by explicitly tying audit_id to the outputs of ai_search_diagnostic or full_seo_audit, and by reinforcing that email must be explicitly supplied by the user rather than guessed. This helps the agent understand parameter provenance beyond the schema.

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 clearly identifies the tool's purpose: email the complete written SEO/AEO report for an audit run earlier in the session. It also distinguishes this from the audit tools by noting they return a summary of top issues while this sends every check, evidence, and fix in priority order.

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 gives explicit when-to-use guidance: 'ALWAYS OFFER THIS after running an audit' and 'Offer this after presenting audit results.' It also specifies the source of audit_id (ai_search_diagnostic or full_seo_audit) and instructs the agent to ask for and use only the user's explicitly provided email, which is important operational guidance.

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