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

Goes well beyond the readOnly/destructive annotations: it discloses that it judges by pattern rather than semantics, that it returns a fill-in template with named slots rather than final copy, that the template is selected by error kind, and that auto-dismiss under 20 seconds is flagged as a disappearing-message failure. It also states what it cannot verify (field linkage, announcement), which is exactly the kind of blind-spot disclosure an agent needs before trusting the result.

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 purpose and standards, then the input shape, then the detection list, then the return contract and limits — a sensible order. It is dense rather than padded, though the long comma-separated flag list is the least scannable part and could be tightened.

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?

There is no output schema, so the description carries the return contract itself — a per-message fill-in template with problem-then-one-step structure and named slots — and it closes with the tool's epistemic limits. For a single-parameter, read-only checker, nothing an agent needs to call it or interpret results responsibly 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 100% with a single parameter, so the schema already defines `text`, `where`, and `autoDismissMs`. The description still adds value: it explains the string-or-object union in plain terms, and supplies the 20-second auto-dismiss threshold that the schema does not state, turning a bare numeric field into a judgment criterion.

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 — checking error/status strings — and pins it to named standards (WCAG 3.3.1, 3.3.3, 4.1.3) plus the exact defect classes it detects. An agent can tell this apart from generic copy tools like review_microcopy or notification_copy_check because the scope is error/status messaging and the criteria are enumerated.

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?

Usage is implied by the scope ('error and status strings') and bounded by a useful limitation ('cannot see whether a message is linked to its field or announced'), but there is no explicit when-to-use/when-not guidance and no named alternative among the many sibling copy-checking tools (plain_language_check, notification_copy_check, error_state_writer_template).

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