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

With no annotations, the description carries the burden and does well: it discloses the credit cost, extra credit past 10 steps, the shared 24-second budget, the Pro requirement, and the per-step pass/fail report. It does not outline every side-effect possibility of running arbitrary actions on a live page, but the core behavioral constraints are clearly surfaced.

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 compact and front-loaded: cost, what it does, output, prerequisite, access level, and timeout budget are each covered in a single short sentence. No sentence is wasted.

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?

Given the tool's complexity, no output schema, and no annotations, the description covers the essential operational context: cost, permissions, timeout, prerequisite, and return type. It could be slightly more explicit about how the final page is returned (screenshot vs. markdown), but the schema fills in those details.

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 parameter descriptions already carry most of the meaning. The description adds helpful context, such as the supported action kinds and the recommendation to call inspect_page for selectors, but it does not add substantial semantics beyond 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 states a specific action: running a sequence of browser actions and returning the final page plus a per-step pass/fail report. It also names the exact action types (click, type, select, etc.) and distinguishes the tool from siblings by pointing to domscout_inspect_page as the selector-finding step, making its role clear.

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 description gives clear usage context: call domscout_inspect_page first, and the tool requires Pro or above. It does not explicitly state when not to use this tool versus other output-focused siblings like extract_markdown or capture_screenshot, so it stops short of a full when/when-not guide.

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

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

With no annotations, the description carries the full burden. It discloses that cancellation is cooperative ('may still complete') and that it's free, providing key behavioral traits. However, it doesn't mention idempotency or what happens if the job is already finished.

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 three short sentences, front-loaded with the free note, then the purpose, then the caveat. Every sentence adds value with no redundancy.

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?

For a single-parameter cancellation tool, the description covers purpose, behavior, and a caveat. Missing elements include usage guidance, success/failure semantics, and whether the operation is synchronous, but these are not critical given the simplicity and lack of 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?

The description adds no information about the jobId parameter beyond the schema's minLength. While the parameter is self-explanatory given the tool name, schema coverage is 0%, and the description doesn't clarify what types of IDs are acceptable or how to obtain one.

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 clearly states the tool cancels a durable job, batch, or crawl, using a specific verb and resource. It distinguishes from sibling tools like get_job (read-only) and crawl_site (creation), though it doesn't explicitly name alternatives.

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?

No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., job must be running) or conditions under which cancellation is appropriate, leaving the agent to infer usage from the tool name.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly discloses the credit cost, the extra cost for fullPage and PDF, and the fact that the response is the image itself. It does not mention anonymous-visitor auth or failure behavior, but those are already captured in the URL parameter description.

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?

Two sentences with no filler: cost and return type come first, followed by a clear usage recommendation. Every clause contributes decision-relevant information.

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?

Together with the fully documented 11-parameter schema, the description gives an agent enough context to invoke the tool correctly: cost, output, and when to prefer a sibling. It omits only minor execution-time details such as network error handling or image size limits, which are not essential for tool selection.

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 baseline is 3. The description adds value by explaining the credit implications of fullPage and PDF, which the schema does not cover. It does not need to restate parameter details already fully documented in 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 states a specific verb and resource: capturing a viewport screenshot as PNG/JPEG/WebP, plus fullPage and PDF variants. It also distinguishes the tool from domscout_extract_markdown, so an agent can tell them apart without opening schemas.

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 this tool when layout, styling, or visual state is needed, and it names domscout_extract_markdown as cheaper and more useful for reading text. This is a concrete when-to-use/when-not-to-use rule with a named alternative.

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

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

With no annotations, the description carries the full burden and does it well by disclosing that the call is free, never consumes credits/quota, and returns rate-limit context. It lacks only minor details such as failure behavior or authentication requirements, but the key behavioral guarantee is explicit and highly relevant.

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, with the most important fact ('never consumes credits or quota') front-loaded immediately. Every sentence earns its place: what it returns, when to call it, and how to interpret the outcome.

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?

For a zero-parameter, no-output-schema utility call, the description fully covers the return contents and provides concrete invocation context. Nothing essential is missing for an agent to select and invoke this tool correctly.

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 tool has zero parameters, so the baseline is 4. The description correctly adds no param-specific detail since none is needed, and the schema already confirms an empty parameter set.

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, verifiable purpose: it returns credit balance, quota usage, rate limit, and price list. It clearly distinguishes this utility call from the capture/extraction sibling tools by emphasizing it is free and never consumes credits.

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 description gives explicit when-to-use instructions: call before a large run to budget, and after a 429 to distinguish rate limiting from credit exhaustion. It even tells the agent what action to take in each case, which is strong operational guidance.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it discloses per-page billing, async job semantics, non-disablable robots.txt respect, hard caps (500 pages, depth 5), the HTTPS allowlist requirement, and the plan gate. No contradictory annotation exists.

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?

Four dense sentences, no filler; the highest-stakes facts (cost, async workflow) come first and each sentence contributes distinct operational information.

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 gives enough to invoke correctly: required allowedOrigins context, cost model, max bounds, async polling path, and auth requirement. It is slightly incomplete on pattern parameters and what the eventual job result contains, but the polling sibling is named.

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 only 43%, and the description compensates partly by adding cost-per-page meaning to maxPages and emphasizing the HTTPS allowedOrigins constraint. However, it never explains includePatterns/excludePatterns matching semantics, and maxDepth/maxPages defaults are left 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 clearly identifies an asynchronous crawl operation over a set of HTTPS pages constrained by an allowlist, with cost, cap, and compliance facts. This distinguishes it from single-page siblings like domscout_extract_markdown or domscout_inspect_page, and title/description align.

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 description gives clear operational context: submitting is free but costs per page, it returns a job ID to poll via domscout_get_job, and a Business plan is required. It does not explicitly name single-page alternatives or state when not to use this tool, so it stops short of a 5.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It explains per-field found/missing/invalid_selector reporting and that a partial result does not fail the whole call, plus the credit cost. This is valuable behavioral context beyond what the input schema provides.

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 short sentences deliver cost, core functionality, failure semantics, and access requirements with no filler. Every sentence earns its place, and the most decision-relevant facts are front-loaded.

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 combination of the schema and description gives an agent enough to call this correctly: how extraction works, field-level status reporting, cost, and access requirement. URL/auth constraints live in the schema, and the output nature is described in the description despite the absence of 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?

The input schema already documents all four parameters in detail (100% coverage), so the baseline is 3. The description adds general context about CSS selectors and typed JSON but does not add parameter-level details beyond the schema, which is acceptable given full 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 ('Pulls named fields off a page'), the mechanism (CSS selectors), and the output (typed JSON). This clearly differentiates it from siblings like domscout_extract_markdown, which returns markdown rather than structured fields.

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 description gives clear context for when to use the tool: extracting named fields from a page as typed JSON. It also adds practical constraints—2 credits and Pro-or-above requirement—so an agent can decide if it is eligible. It does not explicitly name alternatives or say when not to use it, so not a 5.

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

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

With no annotations present, the description bears the full burden and handles it well: it discloses the 1-credit cost, the fast option's JavaScript limitation and identical result shape, and the retry behavior when a page comes back thin. These are behavioral traits that materially affect how an agent should invoke the tool.

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?

Four sentences, all dense and non-redundant: cost, result contents, positioning versus screenshot, fast-mode tradeoff, and retry rule. The most decision-relevant facts are front-loaded.

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?

For a read-only page-loading tool with a fully documented parameter schema and no output schema, the description still names the returned fields, cost, sibling alternative, and failure-recovery workflow. Nothing necessary for correct selection or invocation is missing.

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 baseline is 3, and the description adds extra operational context for fast:true (static page types, same price/result shape, speed difference, retry if thin) beyond the schema's own text. It does not add field-level context for the other parameters, but the schema already documents them fully.

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 uses a specific verb and resource: it loads a page and returns its main content as clean Markdown, and it lists the exact fields in the result. It also distinguishes itself from its primary sibling by calling itself the cheapest option and noting it returns text rather than an image, so an agent can tell it apart from domscout_capture_screenshot.

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 this is the right tool for reading a page, and tells the agent to use domscout_capture_screenshot only when visual inspection is needed. It also gives concrete fast:true guidance for static pages and instructs checking meta.renderJs and meta.contentQuality and retrying without fast:true when content is thin.

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

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

With no annotations, the description carries the behavioral burden. It explicitly discloses that calls are free and never consume credits/quota, that polling can be done as often as desired, and that a per-second rate limit still applies. It also lists the possible statuses, which is useful operational context beyond what the schema provides.

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 short, front-loaded with the most decision-relevant fact (free/no quota), and flows logically from purpose to statuses to polling guidance. The only minor flaw is repeating the 'free' point in both the first and third sentences.

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?

For a simple status-polling tool with two parameters and no output schema, the description is largely complete: it identifies the jobId source, enumerates status values, and covers rate limits. It does not describe the full response payload or retention behavior, but that is not essential for making a correct call.

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?

Both parameters are already fully documented in the schema with 100% coverage, so the description does not need to repeat their meanings. It adds minor context by noting job IDs come from crawls, batches, or auto-promoted captures, but this is not substantial new parameter semantics.

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 clearly states the operation ('poll'), the resource ('a job ID'), and the sources of those IDs (crawl, batch, auto-promoted capture). It also enumerates the expected statuses, leaving no ambiguity that this is a status-check tool rather than a cancel or create operation.

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 clear context for when to use the tool: after a crawl, batch, or capture returns a job ID, and it explicitly says polling can be repeated freely. It does not name alternatives like cancel_job or state when not to poll, but the intended use is unambiguous.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses the cost ('Costs 2 credits'), the access requirement ('Requires Pro or above'), and the nature of the response (semantic snapshot with selectors). These are non-obvious operational traits an agent needs before invoking. It does not describe failure modes or async behavior for the default path, but the most decision-relevant behaviors are surfaced.

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?

Four short sentences, each earning its place: cost, output contents, usage positioning, and access tier. There is zero filler and the most operationally important facts (cost and output) are front-loaded before the usage guidance. This is a model of concise, information-dense tool documentation.

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?

For a 5-parameter tool with no output schema and no annotations, the description covers the essentials: pricing, authorization tier, output shape, and when to use it in the workflow. The main gaps are the undocumented maxNodes parameter and the absence of a precise output contract (no output schema means 'accessibility tree, interactive elements, selectors' is all an agent gets). These are minor against the solid core, so 4 is appropriate.

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 80% (url, delay, detail, and waitForSelector are documented), so the schema carries most of the parameter load and the baseline of 3 applies. The description adds nothing about parameters, and maxNodes remains undocumented in both the schema and description – a real gap. The description's output details hint at what selectors are returned, but that does not compensate for the missing parameter semantics.

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 and resource: 'Returns a semantic snapshot: the accessibility tree, the interactive elements, and a selector for each.' This concretely distinguishes it from siblings like domscout_extract_markdown (content) and domscout_capture_screenshot (visual), while the reference to domscout_automate_page clarifies its role in the workflow. The title and description together give an agent an exact picture of what the tool produces.

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 description gives explicit usage context: 'Use this before domscout_automate_page to find out what is on the page and what to target.' This names the companion tool and the timing precisely. It stops short of a 5 because it does not state when NOT to use it or mention alternatives like domscout_extract_data, but the primary orchestration flow is clear.

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

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

With no annotations, the description carries the behavioral disclosure burden. It transparently states that the call is free)Skip never consumes credits or quota, that a human reads the submission, and that secrets should be omitted. This adds meaningful operational context beyond the schema, though it does not describe the immediate response or any side effects.

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 reasonably well structured and front-loaded with the free/quota note, but it contains redundancy: 'Free' plus 'never consumes credits or quota' plus 'never be charged, by design' says the same thing three times. The use-case list is valuable reticle, but the opening repetition costs 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?

For a feedback tool with 7 parametersaging, no annotations, and no output schema, the description provides strong usage context, cost behavior, and a human-review note, which covers important operational expectations. However, it leaves partial parameter semantics unexplained and does not describe what happens after submission beyond 'a human reads these', so it is not fully complete.

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 only 43%, so the description should compensate by explaining the uncovered parameters. It does mention including requestId and that 'message' is the main text, but it does not explain 'type', 'severity', 'expected', 'actual', or 'endpoint' beyond what the schema already provides. The field names and enums are somewhat self-explanatory, but the low coverage means the description should do more.

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 clearly states the tool's purpose: to tell the domscout team about a problem or gap. It gives specific verbs ('tell', 'send feedback') and concrete example scenarios (error, undocumented parameter, missing capability, wrong result), which sharply distinguishes it from the data-extraction and crawling siblings.

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?

Usage guidance is explicit with 'Use this whenever something about this API got in your way' and a list of concrete triggers. It also instructs to include the requestId from a failed call and warns against including secrets, but it does not mention any when-not-to-use cases or alternatives, as no sibling directly competes with feedback.

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