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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond those flags: the no-arg call returns a pasteable snippet, the snippet prints {elements, viewport} JSON, and the second call yields the actual audit scores. There is no contradiction with the annotations.

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 three sentences with no wasted words, and the main action is front-loaded. Each sentence covers a distinct aspect: what the tool evaluates, how to use it, and when it is relevant relative to audit_page.

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?

This is a specialized two-call audit tool with no output schema, but the description offers enough to use it correctly. It covers the required invocation sequence, the expected data interchange format, the dimensions being scored, and the intended rendered-page use case.

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?

The schema already describes elements and viewport with 100% coverage, so the baseline is 3. The description is worth credit because it explains how those parameters are obtained and used ('Call with no arguments to get a DevTools snippet... Call again with that JSON'), connecting the schema's params to a concrete workflow and removing ambiguity.

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 opens with 'Evaluate visual rhythm from a rendered page's geometry,' which names a specific verb and resource. It then lists the concrete outputs ('alignment, gap-rhythm, and optical-balance scores') and explicitly positions itself as the complement to audit_page for things only visible once rendered, clearly differentiating from its most relevant sibling.

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 a concrete two-phase workflow: call with no arguments to receive a DevTools snippet, then call again with the snippet's JSON to obtain the scores. It correctly orients the tool toward rendered-page context by noting it is for 'things only visible once rendered,' though it does not enumerate exclusions for every other audit sibling.

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