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

With no annotations, the description carries the full burden, and it delivers: it discloses that this is a plain fetch, that JavaScript is not executed, that there is a per-call cost, and that payment requires a two-step signed flow. This gives the agent a clear model of side effects and prerequisites.

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 sentences, each with a distinct job: what it returns, how it differs from page_extract, and how payment works. No filler or repetition.

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?

The description is complete for a read tool of this complexity: it names the return contents, the no-JavaScript limitation, the alternative tool, the cost, and the payment flow. No output schema exists, but the description covers what the agent needs.

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 both urls and payment are already documented. The description adds meaningful workflow context for payment—call once without it, sign the terms, then pass it—and reinforces the up-to-10 limit for urls.

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 specific verb and resource: reads up to 10 web pages and returns title, description, readable body, and final URL. It also distinguishes itself from page_extract by specifying that this is a plain fetch without JavaScript.

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 explicitly says to use page_extract for rendered pages, establishing when web_read is the wrong choice. It also provides the full payment workflow: call once without payment for terms, sign with your wallet, then call again with payment.

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