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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as true, false, and false respectively. The description adds useful behavioral context beyond annotations: the error-handling pattern ('returns an error object never a protocol error') and the fact that it is safe to retry after correcting input. It also clarifies that it is free. A 4 because it doesn't specify rate limits or volume constraints, but the added detail is substantial.

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 concise (12 sentences) and front-loaded: the first sentence states the core purpose. Every sentence adds value—purpose, cost, checks performed, example input/output, usage guidance vs. siblings, and error-handling behavior. No wasted words.

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?

Given the tool's moderate complexity (2 parameters with 100% schema coverage, an output schema present, and comprehensive annotations), the description is complete. It covers what the tool does, when to use it, what it checks, example format, limitations (not for subject line), and error behavior. The output schema documents return values, so the description appropriately focuses on usage guidance.

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 baseline is 3. The description adds semantic value by giving a concrete example of input ('subject': 'Quick question', 'body': '<email text>') and explicitly noting that the subject may be empty when auditing body copy alone. This clarifies usage beyond the schema's description.

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 uses a clear verb+resource pair ('Audit outreach copy') and specifies the purpose is to check 'for spam triggers and deliverability risks.' It differentiates from siblings by explicitly naming subject_line_scorer and sequence_planner, and the provided example clarifies scope.

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 states when to use the tool: 'Use on the body of an outreach message.' It also gives clear when-not-to-use instructions: 'Not for the subject line alone (subject_line_scorer) and not for the send schedule (sequence_planner).' This provides excellent differentiation from sibling tools.

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