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

Beyond the annotations (readOnly/openWorld/non-destructive), the description discloses crawl mechanics an agent cannot infer: 40-page cap, 4 concurrent requests, robots.txt compliance for the ATPDesigners user agent, sitemap.xml usage, and that only static HTML is read. It also describes the coverage preamble (pages read vs found, skips, truncations, request budget), which is exactly the kind of behavioral context annotations cannot carry.

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 purpose, then crawl behavior, then the coverage preamble, then the check list, then explicit non-goals. Dense but efficient; the long enumeration of detected issues is informative rather than padding, though it could be tightened slightly.

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 carries the full burden of describing results and does so: the result opens with coverage figures and then reports the specific categories of problems. Combined with the stated non-goals, an agent knows both what it will receive and what will be absent.

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%, so the schema already documents url, paths, sitemap and maxPages in detail. The description adds value on top by explaining the crawl concurrency ('4 requests at a time'), the precedence rule that listing paths suppresses link-following, and the practical 40-page ceiling that maxPages can only lower.

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 ('Spot static performance problems across a site') and enumerates exactly which static signals it detects. It implicitly separates itself from timing-based tools ('never measures time and makes no speed claims') but never names a sibling such as page_weight_report or rendered_vs_static_notes, so the discrimination is inferred rather than stated.

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 establishes clear context for use: static-only HTML analysis, crawl scoped to the given origin, sitemap-assisted discovery, and an explicit exclusion set (no timing, no linked CSS/JS fetched). It gives no positive routing advice toward an alternative tool when timing data or rendered output is needed, so it stops short of full when/when-not guidance.

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