URLpipe

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds important behavior: it loads the page (a side effect), captures specific error types, explicitly excludes console.log, and mentions the 1-credit cost. It does not contradict the annotations and provides context beyond the structured hints, such as cost and the distinction from console.log.

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 exactly two sentences with no fluff. The core functionality is front-loaded in the first sentence, and the second sentence gives a practical use case. Every word earns its place, and it is not overly verbose despite the tool having 9 parameters.

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 are covered. The description explains what the tool does, what it captures, and when to use it. It does not explicitly mention the asynchronous behavior (sync=false returning a token) or the need to call get_result, but these are detailed in the parameter schema. Given the schema richness and the tool's complexity, the description is adequate and leaves the agent with enough to select and call the 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?

Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds no parameter-specific meaning beyond the schema, except the mention of '1 credit' which is cost-related but not tied to any parameter. The baseline of 3 applies because the schema carries the full parameter documentation and the description does not need to compensate.

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: it loads a page in headless Chrome and returns console.error/warn, uncaught exceptions, and unhandled promise rejections. It explicitly excludes console.log, which distinguishes it from generic page-fetch tools like fetch_html or scrape_url. The purpose is unambiguous and distinct from its 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?

It provides a clear usage scenario: 'What you would open DevTools for: broken third-party scripts and client-side errors you cannot reproduce locally.' This gives the agent a concrete context for when to invoke it. However, it does not explicitly name alternatives or state when not to use it, only implying the condition via the DevTools analogy.

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?

Beyond annotations, it discloses the 1-credit cost, the POST endpoint, and the rendering behavior (JavaScript, fonts, images). This adds meaningful operational context that annotations alone do not provide.

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 well-structured and front-loaded: endpoint and core behavior first, then cost, then use cases, then a compact summary of options. Every sentence contributes useful information without 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?

The description, combined with a rich input schema and output schema, covers what the tool does, when to use it, what it costs, and how the option groups behave. Async behavior and detailed parameter constraints are already in the schema, so the description does not need to repeat them.

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?

With 100% schema coverage, the baseline is 3, but the description adds a useful semantic grouping: screenshot_options size/encode/restyle, and page_options wait/clean the page. This helps an agent map intent to the right nested parameters beyond the schema's individual property descriptions.

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 the operation: capturing a rendered page as a PNG via POST /screenshot, with JavaScript, fonts, and images rendered as a browser would. It also distinguishes itself from text-reading siblings by framing the tool as 'see a page rather than read it.'

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 concrete use cases: layout checks, visual regressions, link previews, and verifying anti-bot pages. It implies alternatives by contrasting with reading pages, though it does not explicitly name sibling tools or state when not to use it.

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?

The annotations already cover safety and idempotency (readOnlyHint=false, idempotentHint=true, destructiveHint=false). The description adds valuable context beyond the schema: the 15-credit cost, the fact that results are ranked by a language model rather than raw frequency, and the POST endpoint. This meaningfully informs the agent about what the operation does and what it costs.

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 and front-loaded: it states the endpoint, the result, the ranking method, and the cost in the first two sentences. The third sentence earns its place by giving a concrete cost-saving alternative. There is no filler or repetition of the schema.

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 9-parameter schema is fully documented, an output schema exists, and the annotations cover idempotency and destructiveness, the description is largely complete. It could add a bit more context about when keyword extraction is preferable to summarization or metadata extraction, but the provided guidance about fetch_markdown covers the most important decision point.

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 100%, so the input schema already documents all 9 parameters in detail. The description adds no additional parameter-level semantics beyond the schema; the cost and ranking notes are behavioral, not parameter-specific. This matches the baseline of 3 for fully covered schemas.

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: it exposes POST /keywords and returns the 5–15 terms and phrases that best represent the page, ordered by relevance. It also distinguishes the behavior from raw frequency counting by noting the ranking is done by a language model, so the agent knows exactly what kind of output to expect.

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: 'As with summarize_page: if you are going to reason over the result yourself, fetch_markdown costs 1 credit and gives you everything.' This explicitly names an alternative and the condition under which to choose it. It does not enumerate exclusions for all 13 siblings, but the main competing content-extraction path is addressed.

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?

Annotations already mark this as non-read-only and idempotent, and the description adds meaningful behavior beyond them: JavaScript-injected values are included because the page is rendered first, and the operation costs 5 credits. It also clarifies that the result is a reconciled metadata object, not the page's raw tags. No contradiction with the annotations is present.

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 tight paragraphs deliver the core behavior, the surprising rendering behavior, the cost, and the key alternative without redundancy. Every sentence earns its place, and the verb-resource statement is 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?

Given 9 parameters, nested page_options, and an output schema, the description appropriately covers selection, cost, rendering behavior, and result shape. The remaining operational details (sync default, labels, max_age, residential) are fully covered by the schema, so nothing needed to invoke the tool correctly is missing. It could still add one sentence comparing it to extract_keywords/scrape_url, but that is optional.

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 100%, so all 9 parameters are already documented in the input schema. The description does not add parameter-level detail, which is acceptable at the baseline 3; it only references the url indirectly by describing page rendering. No parameter ambiguity needs rescuing.

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?

Description uses a specific verb and resource ('Exposes POST /meta. Reconciles Open Graph, Twitter card and standard page metadata into one clean object') and enumerates the returned fields. It also differentiates itself from a raw tag dump and from cheaper Markdown, so an agent can tell it apart from fetch_html, fetch_markdown and extract_keywords.

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 one explicit routing rule: if the agent only needs the title, that is available in Markdown at lower cost. It also scopes the tool as reconciled page metadata rather than a raw meta-tag dump, which implies when it is appropriate. It does not spell out exclusions for extract_keywords, fetch_html, or scrape_url, 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?

The description adds behavioral details beyond the annotations: it identifies the HTTP endpoint, states the 1-credit cost, and explains that the HTML reflects the post-JS, post-redirect DOM rather than the curl shell. Annotations already cover idempotency and non-destructiveness, so the description complements rather than repeats them.

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 compact, information-dense paragraphs with no filler. The core behavior and cost are front-loaded, and the alternative tool is mentioned in the final sentence without unnecessary elaboration.

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 100% schema coverage, nested-object parameter details, output schema, and clear sibling-tool guidance, the description provides everything an agent needs to select and invoke this tool correctly. The behavioral context around pricing and rendering rounds out the available structured information.

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 100%, and the schema already documents all nine parameters with detailed semantics. The description adds no parameter-level detail, so the baseline 3 applies.

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?

States a specific verb and resource: it exposes POST /html and returns the page's HTML after JavaScript and redirects. It also differentiates the result from the raw shell curl output and from fetch_markdown, making the tool's scope unmistakable.

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?

Explicitly says 'Use it when you need the markup itself' and names fetch_markdown as the alternative when reading page content. This gives the agent a clear decision rule instead of leaving the choice to inference.

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?

The annotations already provide safety and idempotency hints, and the description adds useful behavioral context: headless Chrome rendering, main-content extraction, dropping navigation/sidebars/cookie banners, and the 1-credit cost. It does not contradict the annotations, though it leaves async behavior details to the schema.

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: the operation and output format come first, followed by a clear usage recommendation and cost rationale. Every sentence contributes value without repeating schema content.

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 tool with 9 parameters, nested page_options, a full output schema, and a rich sibling set, the description covers the essential decision: use this for readable Markdown and prefer it over heavier HTML fetching. It is slightly incomplete in not surfacing the default async behavior (sync=false), but that is fully specified in the 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 100%, so the parameters are fully documented structurally. The description adds no parameter-specific meaning beyond the general Markdown-output context, which matches the baseline of 3 for high 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 clearly identifies the operation: "Exposes POST /markdown" and explains that it renders a page in headless Chrome and converts its main content to clean Markdown. It also distinguishes itself from fetch_html by emphasizing compactness, so an agent can tell siblings apart.

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 launch guidance: "Start here when you want to READ a page," and justifies it with cost and compactness. It names fetch_html as a key alternative, but does not explicitly state when-not-to-use the tool or discuss other sibling tools like scrape_url or summarize_page.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context by enumerating what the metadata contains: stage durations, store reuse, analysis failure reasons, and webhook delivery status. It does not contradict the annotations.

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 tight and well-structured: the first sentence states scope, and the second provides routing guidance and diagnostic value. Every sentence earns its place with no filler.

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?

With a 2-parameter schema that is fully described, an output schema, and annotations covering safety and idempotency, the description gives the agent everything needed to correctly choose and use the tool. It even supplies diagnostic use cases that are not implied by the 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 100%, so the schema already documents both parameters well. The description does not add significant parameter-level detail, but it doesn't need to because project_id and token are already explained ('From list_projects' and 'The token the original call returned').

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 the tool as inspecting metadata about a past request, explicitly excluding the result. It differentiates itself from get_result by saying 'This is the metadata; get_result returns the page itself.'

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 tells the agent exactly when to use this tool: 'Reach for this one when a call did not do what you expected.' It also names the alternative (get_result) and explains the distinction, leaving no ambiguity about when to choose this over its sibling.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to repeat that. It adds value by explaining the async collection mechanism, the 30-day retention, and the 'processing' status response — details not covered by annotations. This is useful context beyond the structured data.

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 well-structured: it opens with the core purpose and return format, then explains usage context and lifecycle. Every sentence earns its place, and the length is appropriate for the complexity. The front-loaded core purpose ensures quick comprehension.

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?

Despite having an output schema (which explains the return structure), the description provides complete context for calling this tool correctly: how to obtain tokens, the free re-read behavior, retention period, and the processing response. With 2 parameters fully described in both schema and description, and clear usage guidance, nothing essential 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?

The input schema already provides descriptions for both parameters (token and project_id), so the schema coverage is 100%. However, the description adds context about how the token is obtained ('any tool called without sync: true answers with a token') and how to get project_id ('From list_projects'), which enriches the parameter meaning beyond just the schema text.

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 exposes a GET endpoint and returns the result of a past request, with specific examples of return formats. It distinguishes itself from siblings like get_request and list_requests by focusing on async result collection and re-reading paid results, which is unique among the listed tools.

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 explicitly explains when to use this tool: when an async call returns a token, this tool turns it into the result. It also notes that re-reading is free and results are kept 30 days, and advises calling again if status is 'processing'. It implicitly excludes synchronous calls (sync: true) and provides clear lifecycle context.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: it reveals that operation prices differ by a factor of seventeen, and it explains that a quota_exceeded error indicates this number has run out. This goes beyond the annotations by tying the tool to rate-limit semantics and error interpretation, which is exactly the kind of context the dimension seeks.

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: the first states the core purpose, the second provides a concrete usage scenario and an error-interpretation tip. It is front-loaded with the primary function and wastes no words. Every sentence earns its place, and the structure is efficient and scannable.

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 simplicity (no parameters, an output schema exists), the description covers all essential aspects: what data it returns (plan allowance, remaining quota, operation costs), when to use it (before expensive calls), and how to interpret a specific error (quota_exceeded). It is fully sufficient for an agent to know when and why to invoke it.

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 schema coverage is trivially 100%. Per the rubric, a baseline of 4 is appropriate when there are no parameters to explain. The description does not need to elaborate on parameters, and it correctly avoids doing so.

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 what the tool does: it reports the organization's plan limits, remaining quota for the period, and the cost of each operation. This is specific and distinct from sibling tools like fetch_markdown or summarize_page, which are about fetching or summarizing content. It uses a concrete verb-resource pair ('get usage and prices') and leaves no ambiguity about its 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 description explicitly advises using this tool before a run of expensive calls, gives a concrete example comparing fetch_markdown and summarize_page costs, and explains how to interpret a quota_exceeded refusal. This gives clear guidance on when to call it and how it relates to other operations, effectively routing the agent to the right context.

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?

Annotations already carry the safe, read-only, idempotent profile, so the description's job is to add context beyond that. It does by disclosing token-based scoping, the included usage statistics, and the relationship between projects, credits, and billing. This is meaningful behavioral context without contradicting the annotations.

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?

Both sentences earn their place: the first defines the output contents, and the second provides essential usage and billing orientation. The 'Start here' directive is front-loaded and there is no repetition of schema or annotation 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?

For a parameterless list operation with an output schema, the description fully covers what an agent needs to invoke it correctly and why it should be the first call. It explains scope, output content, and downstream usage with no missing operational 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?

The tool takes zero parameters, so the schema already fully documents the input surface. The description adds context about how the returned project_id will be used by other tools, which is the relevant semantic information here.

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?

States a specific verb and resource: lists projects visible to the token. It also specifies what each project entry contains (request counts in last 30 days, result delivery location), which clearly differentiates it from the sibling action tools.

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?

Explicitly says 'Start here' and explains that every other tool consumes a project_id from this list, giving the agent a clear invocation order. The billing clarification also prevents the agent from assuming project choice affects cost.

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?

Annotations already declare readOnly, idempotent, and non-destructive, so the description need not restate those. It adds useful behavioral nuance: /scrape appears as one entry with internal children, and the scrape token aggregates them. Also notes exact label matching. No contradictions.

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 concise sentences front-load the core purpose and ordering, then add critical behavioral and filtering details without fluff. Every sentence earns its place.

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 list tool with 6 parameters, an output schema, and rich annotations, the description covers ordering, token reuse, scrape aggregation, and label matching. Pagination is handled by schema; return structure is in output schema. Nothing essential 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 parameters are already described. The description reinforces the labels parameter ('every key given must match its value exactly') but adds little beyond schema. No additional syntax or edge cases beyond what's 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?

States a specific verb (list), resource (requests of a project), and ordering (newest first) with tokens. Clearly distinguishes from get_request and get_result by focusing on the listing of past requests and the token reuse.

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?

Explicitly instructs to look here before fetching a page, explaining that passing a token to get_result reuses cached results. Also clarifies the /scrape entry behavior and label filtering, giving concrete when-to-use 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?

The description goes well beyond annotations. It discloses that the tool makes a network request (openWorldHint true), is not read-only (readOnlyHint false) because it runs a computation and charges credits, supports idempotency (idempotentHint true) via idempotency_key, and is non-destructive (destructiveHint false). It adds unique behavior: it fetches the page independently, caches results (max_age), supports async delivery, and has a residential exit option. No contradiction with annotations.

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 paragraphs, but every sentence carries useful information: purpose, cost, latency, fetch behavior, and a note about interaction with scrape_url. It is front-loaded with the core purpose. Slightly longer than necessary but justified by the tool's complexity.

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 (10 parameters, async modes, caching, cost), the description is thorough. It explains cost, caching, async vs sync, residential fetching, and idempotency. An output schema exists (not shown here), so return-value details are covered. Nothing an agent needs to invoke it correctly 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?

The input schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides; it adds context on cost and behavior, but that's not tied to individual parameters. It doesn't compensate for any gaps because there are none.

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 ('Runs a real Google Lighthouse audit') and resource ('against the live page'), and enumerates the exact outputs (performance, accessibility, best-practices, SEO scores, Core Web Vitals). This clearly distinguishes it from siblings like fetch_html or capture_screenshot, which serve different purposes.

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 provides contextual guidance on when to use the tool: it mentions higher cost (2 credits) and longer runtime than other tools, and clarifies that it fetches the page itself, affecting cost when used inside scrape_url. However, it doesn't explicitly state 'use this when you need Lighthouse scores' or name alternative tools for comparison, so the guidance is implicit rather than prescriptive.

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?

Goes well beyond annotations. Discloses billing semantics (each operation billed exactly as individual; no discount), per-visit surcharge sharing, partial-failure response shape ('object keyed by operation, each entry carrying its own success'), and edge cases that cause extra page fetches (lighthouse, specific screenshot_options). These are behaviors an agent would otherwise discover only by executing 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?

The description is long but every sentence carries unique information. Core purpose and the 'reason to use' appear first, then the response format, then the cost exceptions. No filler or repetition of schema content; the structure mirrors an agent's decision flow: what, why, what happens, when not to.

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 complex tool with 13 params and nested objects, this description addresses all decision-critical aspects: composite batching, billing behavior, partial failures, and the specific conditions that break the single-visit optimization. The output schema exists beSilencing; the description does not need to enumerate return fields. Nothing an agent requires to invoke correctly 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 already provides 100% description coverage for all parameters. The description adds meaningful interplay semantics not present in the schema: that operations like lighthouse don't share the visit)Skip; screenshot_options with certain fields cause an independent visit. This contextualizes the `operations` and `screenshot_options` parameters without repeating schema details, which is exactly what is needed.

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 a specific verb ('runs any subset of the other operations in one request') and resource (POST /scrape), and distinguishes itself from siblings by being a composite operation. It makes the tool's aggregation purpose immediately obvious, unlike what any sibling description likely does.

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?

Explicitly explains when to prefer this tool: 'it is the reason to use it' – residential surcharge paid once per visit. It also lists exceptions where it would not save money (lighthouse, certain screenshot_options) and thereby tells the agent when not to use it or when to expect extra charges. No other tool description among the siblings provides such direct routing 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?

Beyond the annotations, the description adds valuable behavioral context: the 17-credit cost, the fact that it 'runs a language model over the page,' and the content filtering behavior. It slightly oversimplifies the async default by saying it 'Returns a concise Markdown summary' when sync=false actually returns a token immediately, but the sync parameter description covers that detail.

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 tight paragraphs with no filler. The first sentence states the endpoint and output; the second paragraph's cost and routing guidance earns its place by preventing expensive misuse. Every sentence adds value.

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?

With a rich, fully documented schema and an output schema present, the description need not enumerate parameters or return fields. It supplies the missing high-level context: cost, content filtering, and when to prefer fetch_markdown. The only notable gap is not explicitly signalling the async default, though the sync parameter description handles that.

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 100%, so the schema already fully documents all nine parameters. The description adds no parameter-specific semantics beyond general context, which matches the baseline for high 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 names a specific resource and action: 'Exposes POST /summarize' and 'Returns a concise Markdown summary of the page's main content, with the navigation, ads and boilerplate left out.' This clearly separates it from siblings like fetch_markdown and fetch_html.

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 explicitly tells the agent when to use this tool versus an alternative: it is 'the most expensive operation we sell, at 17 credits,' and fetch_markdown is recommended instead if the agent will read the page itself. It states the tool is for when 'the summary is the artefact being produced, not a step on the way to one.'

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