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

Goes well beyond the readOnly/openWorld annotations: discloses that URL fetches are restricted to public hosts, that only static markup is read, and what is invisible (layout, prominence, script-built menus). It also describes the output contract (answerable/partial/missing with evidence), which no annotation covers.

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 the six questions, then inputs, then verification signals, then the limitation. It is a dense paragraph rather than a list, and the mid-sentence enumeration of markup sources is long, but nearly every clause carries information.

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 supplies the return shape (per-question status plus evidence) and the key limitation (static markup only). An agent has enough to decide to call it and to interpret results correctly.

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 baseline is 3; the description adds real value by noting `url` must be a public host fetched safely and that `html` may be plain page text. That host restriction and text fallback exceed the terse schema descriptions.

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: answers the six Krug trunk-test questions from a page's markup, and enumerates all six questions. This is clearly distinct from siblings like site_heading_outline or content_hierarchy_check because it names the exact framework and the specific markup signals inspected.

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?

Gives clear invocation guidance (pass a public `url` or `html`/`text`) and an explicit scope boundary ('supports the real paper test and does not replace it'). It does not name alternative sibling tools or say when another tool would be preferable, so it stops short of a 5.

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