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

Annotations already declare readOnly/openWorld/idempotent, yet the description goes well beyond them: robots.txt behavior, the blocked/unreachable/emptyReason outcomes, the auto-vs-always render escalation, the hydrated pre-pass for embedded JSON, and prompt-injection handling via untrustedContent/untrustedProvenance. This is exactly the extra behavioral context annotations cannot carry.

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?

Purpose and returned fields are front-loaded and every sentence carries operational detail the agent needs. The closing two sentences on untrusted content overlap somewhat ("untrustedContent" is explained twice), which keeps it from being maximally tight.

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 fully accounts for the return shape (title, markdown, deduped links, blocked/unreachable/emptyReason, rendered/hydrated flags) and the safety framing. Nothing an agent needs in order to call or interpret the tool is missing.

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 baseline is 3, but the description adds real meaning: render="auto" re-reads only when the fetch looks thin, long task text is cut to matching passages, and links are capped at 50 and deduped to same-site paths. That exceeds what the schema alone conveys.

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?

Specific verb and resource ("Read any web page") with concrete example domains (prices, hours, services, policies) and an explicit statement of what comes back (title, markdown, links). It is easy to tell apart from generic siblings by scope, but it never names or differentiates itself from the likely-overlapping sibling inspect_site, so it stops short of a 5.

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 use context ("A cheap alternative to a screenshot") and explains the render modes' trade-off ("auto" only when the plain fetch looks thin). However, it names no alternative tool and sets no explicit when-not-to-use boundary, so an agent must infer routing against siblings.

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