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

Annotations already declare readOnly/openWorld=false/idempotent/non-destructive, and the description adds value on top: no network, no stored state, deterministic same-input-same-output, and concrete limits (64 KB JSON input, 1 s per call, 1 MB result). It also discloses the return shape (normalized form plus reasons), which goes beyond the annotations. The only missed opportunity is saying more about the failure reasons emitted.

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 critical scope statement is front-loaded, which is good, but a full sentence enumerating unrelated artifacts (URL, HTTP header, token, IP range, HTML/Markdown) earns no place in an email validator, and the schema description duplicates the entire English block. Roughly a third of the text is either irrelevant or repeated.

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?

With an output schema present and rich annotations covering the safety profile, the description supplies what's missing: scope boundaries, determinism, and explicit size/time limits. It is essentially complete for a single-parameter pure validator, losing a point only because the misdirecting 'When' list could lead an agent to call it on non-email input.

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 100% for the single parameter, so baseline would be 3, but the description adds real semantics beyond the schema: the accepted RFC 5321/5322 practical subset, the 64-char local part and 253-char domain ceilings, and the fact that output is a normalized form. That is meaningfully more than the schema's 'Email address (string; required; up to 512 chars)'.

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 opening states a precise verb and resource plus its scope: 'Checks email address SYNTAX only (practical RFC 5321/5322 subset: local part ≤ 64, domain ≤ 253, labels, TLD); it cannot tell whether the mailbox exists.' That alone distinguishes it cleanly from siblings. However, the immediately following 'When:' clause lists URLs, HTTP headers, tokens, IP ranges, HTML/Markdown and agent files, which does not describe this tool's purpose at all and dilutes the otherwise sharp statement.

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?

There is one genuinely useful routing rule: 'Not for: checking hostname syntax (domain-syntax-validate)', which names the exact sibling to use instead. But the positive 'When' guidance is boilerplate copied from another tool (URLs, tokens, HTML documents), so an agent reading it would learn nothing true about when to call this validator over, say, extract-emails or university-email-domain.

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