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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, but the description adds genuinely new operational facts: it spends no credits, it never executes JavaScript so registerTool calls are only found in inline scripts, and layout shift is unmeasured. Those constraints materially change how an agent should interpret a 'not measured' result, which is exactly the kind of context annotations cannot convey.

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 first sentence is front-loaded with the core behavior, and the negative constraints are grouped at the end where they belong. The mid-sentence signal list is dense but each clause maps to a distinct check, so little is wasted; only the enumeration length slightly taxes readability.

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 no output schema, the description still explains the return shape by listing the inspected signals and the four possible item statuses (ready, needs work, not applicable, not measured). It also pre-empts the two most likely misreadings, missing JavaScript-driven registerTool calls and absence of a score, so an agent has everything needed to call and interpret it.

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 single parameter has 100% schema description coverage ('Public http(s) URL.'), so the schema carries the semantics. The description's mention of robot-fetch checks implies the URL must be publicly reachable, but it does not add format or validation guidance beyond the schema, so the baseline of 3 applies.

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 a concrete verb and scope ('Read one page the way a browsing agent ... uses it') and enumerates exactly which signals are inspected: accessible names, clickable divs, ARIA, WebMCP tools, llms.txt, Markdown versions, and robots.txt for named user agents. This is clearly distinguishable from siblings such as audit_page or check_ai_crawlers, which cover broader or narrower concerns.

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?

Exclusions are explicit and useful: it does not score, does not run JavaScript, does not measure layout shift, and does not measure task success, which tells an agent what this tool is not for. It never names an alternative sibling (e.g., audit_page for a scored audit or check_ai_crawlers for crawler policy alone), so the routing decision is implied rather than stated.

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