Scrape Page

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

With no annotations provided, the description must disclose behavioral traits itself. It mentions 'real time' and the HTTP/Playwright fallback, but omits important details such as potential rate limits, page size constraints, failure behavior for non-public pages, or whether the action is non-destructive. The 'public' qualifier hints at access restrictions, but significant behavioral disclosure is missing.

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?

The description is two sentences, front-loaded with the primary action, and contains no redundant wording. Its brevity is a strength, though it could have included more parameter or usage details without losing conciseness.

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 tool has three parameters, no annotations, and a hidden output schema, placing a heavy burden on the description to provide operational context. It does not explain when to use this versus siblings, how parameters interact, or any behavioral caveats. The presence of an output schema partially covers return values, but overall the context is incomplete for effective tool selection and invocation.

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?

The schema has 0% description coverage for parameters, so the description must compensate. It only implicitly references the URL ('Fetch a public webpage') and the useBrowser parameter via 'Playwright,' but does not explain waitForMs or the exact role of useBrowser. This leaves two of the three parameters semantically under-defined for the agent.

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's first sentence, 'Fetch a public webpage in real time,' uses a specific verb and resource, clearly distinguishing this from sibling tools like search_web or extract_leads. It also adds the technical approach (HTTP/Playwright) to further clarify the tool's function.

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?

The phrase 'Uses HTTP first and Playwright for JavaScript-rendered pages' provides some context on when browser rendering is invoked, but there is no explicit guidance on when to prefer scrape_page over search_web or other siblings, nor any exclusions or prerequisites. This is sufficient for basic context but lacks clear alternative selection rules.

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