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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description still adds real context the annotations cannot: the default wait (5s), the cap (20s), and the fact that it reports whether the text appeared and then returns the page contents.

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 short and front-loaded with the core behavior, but the trailing sentence is telegraphic and hard to parse ('Answers the page after it: the elements and text in view, with the same numbers'). The default and cap are tucked into a parenthetical rather than stated cleanly.

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?

There is no output schema, so the description must disclose the return shape, and it does: a yes/no on the text plus the page's visible elements and text. Combined with the default/cap timing details, an agent has enough to call it correctly, though the return description is imprecise.

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 the schema carries the parameter documentation and baseline 3 applies. The description does add the default of 5 seconds for `seconds`, which the schema does not state, but `app` is left entirely to 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 names a specific verb and resource: it waits until `text` appears on the page, or for `seconds`, and is aimed at slow-loading results. That is clearly distinct from the read/find/navigate siblings, though it does not call out an alternative by name.

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 context for when to use it ('for results that load slowly') and describes the two modes (text-based wait vs. plain duration wait). It stops short of stating when *not* to use it or naming an alternative tool.

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