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

Goes well beyond the annotations: discloses pricing ($0.005/call, ~$0.0005/page), that billing only occurs if at least one URL succeeds, and the x402 USDC payment path. It also tells the agent what happens without a wallet — it returns payment terms and a paid HTTP URL instead of content — which is exactly the failure-mode disclosure an agent needs.

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 capability and efficiently dense, but the cost is stated twice in near-identical terms ("$0.005 per call ... Charged only if at least one URL is read successfully" then "Costs $0.005 USDC per call via x402 (charged only on success)"). One of those sentences could be merged.

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 7 params fully documented in the schema and no output schema, the description carries only the burden of behavior and cost, both of which it covers well, including the partial-failure model. The one gap is no relative positioning against read_url/preview_url siblings, which for a 7-param batch tool is a minor but real omission.

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 100%, so mode, links, images, max_tokens, chunk_tokens, include_links and urls are all documented in the schema. The description only contributes "in parallel" and "per-URL ok/error", which is marginal added meaning over the structured fields.

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 concrete verb and resource with scope ("Read up to 10 web pages as clean Markdown in one call, in parallel") and adds the per-URL ok/error shape. It equates itself to the /v1/read HTTP endpoint rather than differentiating from the sibling tool read_url, so an agent still has to infer the single-vs-batch split.

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?

Batch usage is implied by "in one call, in parallel" and the 10-URL cap, but there is no explicit "use read_urls when you have multiple URLs, read_url for one" guidance despite read_url being a sibling. No prerequisites or exclusions beyond the payment note.

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