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

Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond them: free, anonymous, no account, no arguments required, and that it returns the exact fault plus a remediation sentence. It does not mention rate limits or latency, keeping it below a 5.

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 core behavior, then the return contents, then invocation guidance. Sentences are dense and long but every clause carries information; nothing is redundant with the schema or annotations.

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?

Complete for a zero-parameter diagnostic tool. With annotations carrying the safety profile and an output schema present, the description needs only to establish purpose, invocation, and the shape of the answer — all of which it does, including the remediation-sentence detail.

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?

Zero parameters, so the baseline is 4, and the description goes further by explicitly justifying the empty schema ('Takes no arguments') and explaining that address facts are derived from the call itself rather than supplied input.

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 ('Reports how the request carrying this call looks from the outside') and pins it to a concrete domain (Web Bot Auth / RFC 9421 signature verification). An agent immediately knows this tool introspects the caller's own signed request rather than performing an action on external data.

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 actionable invocation guidance: 'Sign the call the way you sign requests to anyone else' and 'Takes no arguments: an unsigned call still gets an answer about its address.' It covers how to call it and the unsigned fallback, but there are no alternatives or exclusions to name (no siblings exist), so it stops short of the explicit when/when-not framing.

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