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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely useful behavior beyond that: it strips menus/scripts/ads, returns clean plain text, and chunks output into pages of up to 50,000 characters, which signals truncation. It stops short of stating rate limits, retry behavior, or how to detect that more pages remain.

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?

Three front-loaded sentences using 'Use when:' / 'Not for:' / 'Example:' scaffolding, with zero filler. The leading sentence carries the core purpose and return format before any qualifications.

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 correctly takes on the job of describing the return value (title + main text, plain text, paginated). Combined with the usage boundaries this is nearly complete for a three-parameter read tool; the only shortfall is that pagination mechanics ('start') are implied rather than spelled out.

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 description coverage is only 33%: 'url' is documented in the schema, but 'start' and 'max_chars' have no descriptions there. The description partially compensates by revealing the 50,000-character page ceiling (which maps to max_chars' maximum) and by implying multi-page retrieval, but it never explains 'start' or the default 15000, so the compensation is incomplete.

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 states a concrete verb and resource ('Reads a public web page') and specifies exactly what comes back ('its title and main text as clean plain text'). The 'public web page' scope plus the article/docs/blog framing cleanly separates it from the sibling read_github_file, which targets repository files rather than arbitrary public URLs.

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 gives explicit positive triggers ('you need the content of an article, a documentation page, a blog post or any public page') and explicit exclusions ('Not for: pages that need a login; PDFs (use the Faceabot PDF tool)'), routing the agent to an alternative tool for the excluded case. Nothing about when to select this tool is left to inference.

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