doc_probe_js

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose a meaningful side effect: a saved receipt that 'pre-fills js_render and markdown_passthrough,' plus the headless-Chromium mechanism. But it remains silent on whether the operation is read-only, failure modes (e.g., if Chromium is missing or the page never renders), and network behavior toward external pages, so the disclosure is partial.

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 compact sentences with no filler: the first front-loads the core purpose, the second contrasts with doc_probe and adds the Markdown detection, the third notes the prerequisite and side effect. Each sentence earns its place, though the second sentence packs several ideas together slightly densely.

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?

An output schema exists, so return values need not be explained. The description covers the mechanism, prerequisite, the distinction from doc_probe, and the receipt side effect. It references js_render and markdown_passthrough, which are not among the listed siblings, creating minor ambiguity about those targets, but overall the definition is substantially complete for a single-parameter tool with an output schema.

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 0%, so the description must compensate. It never explicitly documents the url parameter, though the tool's purpose makes it obvious that url is the documentation page to probe. Since there is only one trivial parameter, the implied meaning mostly suffices, but there is no explicit parameter guidance to offset the 0% schema coverage.

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 action ('Probe a JS-rendered documentation page'), a concrete resource, and the mechanism (headless Chromium). It differentiates itself from doc_probe by noting it operates 'over the rendered DOM' and adds a Markdown-copy detector. It relies on the reader already knowing what doc_probe's 'selector report' is, so it's clear but slightly dependent on sibling context.

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 'Same selector report as doc_probe, but over the rendered DOM' clause communicates the intended use case: dynamic/JS-rendered pages that static probing would miss. It also states a concrete prerequisite ('Requires Playwright Chromium installed'). However, the when-to-use vs. alternatives guidance is implied through the contrast with doc_probe rather than stated as an explicit rule.

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