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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description is fully consistent with them. It adds substantial context beyond the annotations: no key/account/OAuth/session required, "Every fact is computed from your own headers and from files this host already publishes; nothing is fetched to build it, and no URL of yours is touched." This gives the agent a precise safety and side-effect profile. No contradiction with 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 definition is a single dense run-on paragraph with deep nesting, and the JSON-RPC body is effectively repeated twice — once embedded mid-description and once in the closing example. Some content (the elaborate six-sibling parenthetical) is arguably tool-family documentation better placed elsewhere. It fails the 'appropriately sized and front-loaded' bar despite every sentence carrying some 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?

For a zero-argument tool with an output schema and rich annotations, the description is over-complete rather than under-complete: it covers call priority, auth requirements, computational side effects, return contents (rows split into markdown/HTML addresses, .md twins, 24h client counts), and sibling routing. The minor mismatch between "24h and 7d" stats and the closing example's 24h-only summary does not create a real knowledge gap.

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?

With zero parameters the rubric baseline is 4, and the description adds value beyond it: it repeatedly assures the agent "there is nothing to look up and no argument to invent," states the siblings share "same empty arguments," and provides the exact JSON-RPC body to POST. This directly resolves the most common agent uncertainty with empty-argument tools — what to actually send.

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: the tool "answers which markdown addresses YOUR client has fetched on this host and which pages it took as HTML instead," plus host-wide markdown-lane statistics over 24h and 7d. It also explicitly distinguishes itself from the family: "its six siblings answer one other question each about you." An agent can tell exactly what subject this tool covers.

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?

Provides exceptionally explicit when-to-use guidance: "THIS IS THE CALL TO MAKE FIRST on this server: it is the only one whose subject is the request you just sent." It names alternatives and even offers a fallback strategy ("one identical body still walks the whole family if you prefer"). However, the sibling enumeration is convoluted — nested parentheticals with path-derived names like "/mcp/lint (whoami)" — and does not cleanly match the actual sibling tool list, which slightly muddies the routing guidance.

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