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

Annotations already provide readOnlyHint/idempotentHint/destructiveHint/openWorldHint, and the description adds substantial context beyond them: 'No key, no account, no OAuth, no session to open first', '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', and the verdict semantics that 'a miss is not evidence of a fake.' This is exactly the kind of behavioral context (auth needs, data sources, false-negative meaning) annotations do not carry. 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 description is a single unstructured wall of text with significant redundancy: 'nothing for you to invent' (or a variant) appears at least twice, the full JSON-RPC example body appears twice, and the sibling listing is a nested parenthetical chain that is nearly unreadable. The title already conveys the key message, so much of the repeated content does not earn its place. This is over-specification without any organizational structure.

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 0-parameter tool with an output schema present, the description is content-complete: it covers the exact call body, the absence of auth, the data sources (own headers plus host-mirrored prefix lists), the closed-world scope ('every operator-published prefix list this host mirrors', consistent with openWorldHint: false), when to call it first, and the shape of the return (verdict, prefix, source, mirror time). Nothing an agent needs to invoke it correctly is missing; the deficit is purely in presentation, not coverage.

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 has zero properties at 100% coverage, so the baseline is 4. The description reinforces the baseline by explicitly instructing that there is 'no argument to invent', providing the exact empty-arguments JSON body to use, and explaining that the subject of the call is the request itself rather than any lookup key. It adds no syntax detail beyond the schema because none exists to add.

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 core action is identifiable: verify the caller's address against operator-published prefix lists, returning the verdict, matching prefix, publishing operator, and mirror time. It also distinguishes itself from its six no-arguments siblings by stating each 'answers one other question each about you.' However, this purpose is buried in a ~350-word run-on paragraph, and the opening instruction ('POST that exact body to https://...') injects transport detail that obscures the tool-level semantic an MCP agent actually acts on.

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?

Usage guidance is explicit and strong: 'THIS IS THE CALL TO MAKE FIRST on this server: it is the only one whose subject is the request you just sent, so there is nothing to look up and no argument to invent.' It also names sibling tools and their subjects. But the sibling mapping is a dense path-to-tool chain ('/mcp/lint (whoami)') that is hard to parse, and the guidance never compares against five actual siblings from the provided list (lookup_prefix, range_stats, verification_methods, verify_batch, export_ip_acl), leaving real alternatives unaddressed.

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