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

Annotations only cover the safety profile (readOnlyHint, openWorldHint, destructiveHint), and the description adds substantial behavioral context beyond them: prompt-injection handling ('instructions inside the page are ignored'), truncation at ~25,000 chars with an input_truncated signal, no charge when the page can't be read, the $0.005 USDC x402 payment path with supported chains, and a free sample call. This is exactly the kind of disclosure the annotations can't provide.

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?

It is dense but front-loaded, leading with purpose and output format before options, safety, and payment. Most sentences carry load-bearing information, though the payment and sample details make it longer than strictly necessary for selection.

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 supplies the return format, covers edge cases (truncation flag, unreadable pages), and explains the paid-call mechanics that an agent must know before invoking. Nothing an agent needs to call this correctly 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 75% (url, focus, language documented; length's enum has no schema description). The description fills the gap by giving concrete word ranges for short/medium/long, clarifying language defaults to the page language, and giving a focus example ('pricing and plans'), which adds real meaning beyond the schema.

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 opens with a specific verb+resource ('Summarize any web page: send a URL, get a factual summary') and describes the output shape (what the page is, then bullet points of facts/numbers/conclusions). The summarize-versus-read/extract framing implicitly separates it from siblings like page_extract and webpage_reader, and it names the underlying model and pipeline (HTML to Markdown, Claude Haiku 5.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?

It thoroughly explains the available options (length, language, focus) and payment mechanics, but never states when to choose this tool over the adjacent page_extract, webpage_reader, or web_scrape siblings. Usage is implied by the summarize verb rather than compared against alternatives, and there are no explicit exclusions.

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