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

The annotations already declare readOnly/idempotent/non-destructive, and the description adds rich behavioral detail beyond that: one GET per document with a 6-second timeout, multiple verdict classifications including soft-404, and the RFC 9728 §3.1 insertion-form behavior triggered by a path. No contradiction with annotations exists.

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 one long, dense run-on that mixes operational guidance, endpoint lists, verdict definitions, and timing details. The unexplained 'FIRST CALL...whoami' snippet is confusing and does not belong in a tool description. The content is valuable but poorly structured and hard to parse quickly.

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 does explain what each result contains (status, verdict, and client action), which is essential. It also covers the network behavior and both well-known URL forms. However, the fixture/schema mismatch and the unclear whoami instruction create gaps that could prevent correct invocation.

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 documents the host parameter with 100% coverage, and the description usefully adds that a path enables the RFC 9728 insertion-form check. However, the instruction 'or {} for the built-in fixture' directly contradicts the schema's required host property, which could lead an agent to make an invalid call. This conflicting guidance outweighs the useful path detail.

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 states a precise, observable task: GET the well-known documents an MCP client reads before the handshake and report each one's status, verdict, and client action. It clearly distinguishes from the handshake_report sibling by scoping to pre-handshake discovery documents. The opening whoami snippet is noisy, but the core purpose is unmistakable.

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 implies usage by saying 'FIRST CALL' and by giving concrete host/path examples, so an agent can infer when to use it. However, it never explicitly contrasts it with siblings like handshake_report or states when not to use it. There is no direct alternative-selection guidance.

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