URLpipe

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

Annotations already provide idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds useful behavioral detail: it captures only console.error and console.warn (not console.log), includes uncaught exceptions and unhandled promise rejections, and mentions a cost of 1 credit. It does not disclose the async token flow (though that is in the schema) or the exact output structure, but given the annotations, it adds sufficient context.

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. The first sentence is the core action, the second is a cost note, and the third is a use-case tip. It is front-loaded with the most important information and contains no 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?

The tool has 9 parameters, 2 required, nested objects, and no output schema. The description explains what the result will contain (console errors, warnings, exceptions, rejections) but does not detail the exact output format or the async token retrieval flow. However, the sync parameter and get_result tool are referenced in the schema, and the description gives enough context for an agent to understand the tool's purpose. It is slightly incomplete for a complex tool but adequate given the schema's richness.

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?

All 9 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The tool description does not elaborate on parameter semantics beyond the schema, but it does clarify the scope of the captured data (console errors vs logs), which indirectly helps with understanding the purpose of the tool. No parameter-specific information is added, but it is not needed given the schema's thoroughness.

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: loading a page in headless Chrome and returning console.error/console.warn messages, uncaught exceptions, and unhandled promise rejections. It explicitly excludes console.log, which differentiates it from general logging. It also gives a clear use case ('what you would open DevTools for'), distinguishing it from sibling tools like fetch_html or 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?

The description clearly says when to use this tool: for broken third-party scripts and client-side errors that cannot be reproduced locally. It does not explicitly name alternatives or state when NOT to use it, but the context is strong enough to guide selection. Slight gap: no direct comparison to siblings, but the use case is specific.

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 note idempotency and non-read-only status; the description adds valuable behavioral context beyond that: it costs 1 credit regardless of options, it runs JavaScript and loads web fonts/images, and it renders exactly like a browser. It also discloses that page_options affect downstream artifacts (ads and banners removed from html, markdown, and summaries). 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 front-loaded with the core action, then purpose, then parameter summaries, with no redundant filler. Every sentence earns its place: the first identifies the endpoint and behavior, the second scopes usage, and the third organizes the nested option groups. It is structured for quick scanning.

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 a complex 10-parameter tool with nested objects and no output schema, the description covers the essential behavioral context: what is captured, rendering fidelity, pricing, and how the two main option groups affect the result. It does not need to explain return values because the schema already documents sync/async behavior, and annotations cover idempotency. Slightly more could be said about error cases, but this is adequate.

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 fully documents all 10 parameters. The description adds useful grouping and intent—'screenshot_options size it... encode it... restyle it' and 'page_options wait for the page and take ads and cookie banners out of it'—but these are summaries, not new parameter semantics. This meets the baseline 3 without exceeding it.

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 opens with a specific verb and resource: it 'Captures the whole rendered page as a PNG', and clarifies rendering fidelity ('JavaScript executed, web fonts and images included, exactly as a browser would draw it'). It also distinguishes itself from read-oriented siblings by saying 'Use it to see a page rather than read it', making the tool's purpose 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?

The description gives explicit use cases ('layout, visual regressions, link previews, or checking what an anti-bot page actually showed us') and sets a clear rule of thumb: use it to see rather than read a page. It stops short of naming specific sibling tools or stating when not to use it, but the 'rather than read' contrast implicitly routes text-extraction tasks elsewhere.

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 reveals the non-obvious cost (15 credits), the output's nature (model-ranked rather than frequency-based), and the practical consequence that fetch_markdown is cheaper if the agent will do its own reasoning. These go beyond the annotations, which only indicate idempotency and non-read-only behavior; there is no contradiction with readOnlyHint=false.

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, front-loaded sentences: endpoint, output/quality, cost, and the decision-relevant comparison. Every sentence adds value and no space is wasted on 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 9-parameter tool with no output schema, the description covers the crucial selection facts: what the result looks like, how much it costs, and when to use a cheaper sibling. The full parameter details live in the schema, so nothing essential to correct invocation is missing, though a bit more detail on the result structure would have been useful.

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 every parameter already carries a meaningful description. The tool description adds no parameter-specific semantics beyond the schema, which is acceptable and earns the baseline for high 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 the exact endpoint (POST /keywords) and the concrete output: 5–15 terms/phrases best representing the page, ordered by relevance. It also distinguishes the tool from siblings by noting that the ranking comes from a language model, not raw frequency, and by referencing fetch_markdown and summarize_page.

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 guidance for a key alternative: if the agent will reason over the content itself, fetch_markdown at 1 credit is the better choice, while extract_keywords is positioned as the way to get a pre-digested keyword list. It does not, however, spell out when to pick extract_keywords over summarize_page or extract_metadata, so the routing guidance is strong but not exhaustive.

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=false (so mutation is possible, but the description clarifies it's a read operation) and idempotentHint=true. The description adds valuable behavioral context beyond annotations: it states the page is rendered first, so JavaScript-injected values are included, and it discloses the 5-credit cost. It also clarifies that this is not a raw meta-tag dump, which manages expectations. While it doesn't cover error handling or rate limits, the added context is meaningful given the annotation coverage.

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 concise and well-structured. It opens with a direct statement of what the tool does, then elaborates on the outcome, followed by a clarifying note about scope and a cost-effective alternative. Every sentence earns its place: no filler, and the critical clarification about not being a meta-tag dump is placed in the second paragraph but remains prominent. The length is appropriate for 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 has 9 parameters, a nested object, and an output schema, the description covers the essential behavioral context: the purpose, the inclusion of JS-injected values, and the cost. It does not explain the async flow (sync parameter, get_result), but the input schema fully documents that, and the output schema exists. The description is complete enough for an agent to understand when to use it and what to expect, though more explicit mention of the async pattern could improve it slightly.

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 nine parameters are already well-documented in the input schema. The description does not add any parameter-specific semantics beyond what the schema provides; it focuses on the tool's purpose and output. The baseline of 3 is appropriate since the schema handles parameter documentation, and the description does not need to repeat it.

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 exposes POST /meta and reconciles Open Graph, Twitter card, and standard metadata into a clean object with a specific list of fields. It distinguishes itself from a raw meta-tag dump and points to the alternative of using Markdown for a title, making the purpose unambiguous and distinct from 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?

The description explicitly contrasts this tool with a cheaper alternative: 'If you only need the title, it is also in the Markdown — and that costs 1 credit.' This directly instructs the agent on when to use this tool versus fetch_markdown, and implicitly signals that this tool is for comprehensive metadata needs. The cost difference and the condition (only need title) are concrete, actionable 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?

Annotations already cover idempotency, openness, and non-destructiveness. The description adds meaningful behavioral context beyond that: JavaScript execution, redirect following, the 'DOM a real browser sees' distinction, and the 1-credit cost. This helps the agent set expectations without contradicting any annotation.

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, front-loaded with endpoint and core behavior, then usage guidance and a cost comparison. Every sentence earns its place; there is no repetition of schema content or 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?

For a tool with 9 parameters, nested options, async behavior, and no output schema, the description clearly states the return value (rendered HTML) and cost model while the schema covers parameter mechanics. It could add a note about the async/token flow, but the sync parameter description already handles that, so nothing essential is missing for 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?

Schema description coverage is 100%, so the baseline is 3: the schema already documents all 9 parameters thoroughly, including nested page_options fields. The description adds no parameter-level detail, but it does not need to because the schema carries that burden completely.

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: 'Exposes POST /html. Returns the page's HTML after JavaScript has run and redirects have been followed.' It also distinguishes itself from plain curl and from fetch_markdown, so an agent can readily tell what this tool uniquely 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?

Gives explicit when-to-use guidance: 'Use it when you need the markup itself: a specific attribute, a script tag, a structured-data block.' It also names the alternative for content reading: 'If you want to read the page's content, fetch_markdown costs the same and returns a fraction of the text.' This is clear routing to the right 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 include readOnlyHint=false (no read-only), openWorldHint=true, idempotentHint=true, destructiveHint=false, but do not cover the rendering process or cost. The description discloses that it uses headless Chrome, drops navigation/sidebars/cookie banners, and that results are compact. It also notes a surcharge for residential exits. However, it does not detail the exact behavior of async mode or token collection, though that is partially covered by the sync parameter schema. With decent annotation coverage, a 4 is justified.

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 concise and front-loaded with the main purpose and usage. The behavioral context (headless Chrome, content filtering) is early, and the cost/alternative comparison is efficient. It is not overly long, and each sentence adds value. A minor deduction for not mentioning the async token flow in the description, but it is covered by the sync parameter, so overall strong.

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 has 9 parameters, 2 required, and an output schema is absent, the description covers the essential use case and behavior. It explains key parameters like sync and max_age effectively through the schema and description combined. However, it does not explain the return format or token collection process fully, relying on the get_result sibling. Considering the complexity and that annotations carry some info, a 4 is appropriate, not a 5 because the async workflow could be clearer.

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 all parameters thoroughly, including details like max_age format and idempotency_key behavior. The description does not need to re-explain parameters. It adds a note that 'removed ads and banners are gone from html, markdown and summaries too' for page_options, which is a useful extra beyond the schema. However, this is minor, so a 3 baseline is appropriate given 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 states the tool makes a POST to /markdown, renders the page in headless Chrome, and converts main content to clean Markdown with specific elements kept and others dropped. This is a specific verb+resource with detail that distinguishes it from fetch_html and scrape_url, both siblings with 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 explicitly says 'Start here when you want to READ a page' and contrasts with fetch_html, noting that fetch_html returns the whole DOM which is larger and says nothing extra about meaning. It also highlights cost (1 credit) as a differentiator. This provides strong guidance on when to use and when not to use.

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 mark this as read-only, idempotent, and non-destructive. The description adds substantial behavioral detail beyond that: results are returned in the same form the original call would have produced, unfinished requests return {"status": "processing"}, results are kept for 30 days, and re-reading is free. 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 longer than a one-liner, but every sentence carries essential information: endpoint, return-shape mapping, async collection mechanics, retention/free re-reads, and retry behavior. It is front-loaded with the endpoint and purpose, with supporting details in logical order.

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 no output schema, the description must explain return values, and it does: Markdown stays Markdown, structured operations are objects, screenshots are images, and scrapes become combined objects. It also covers the pending state and retention duration, so an agent has enough information to call and handle the response 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 coverage is 100%, so the baseline is 3. The description adds meaning by explaining that the token is the async handle produced by earlier non-sync calls and that it converts that token into the final result. It also clarifies that re-reading an existing token is free, which informs how the token parameter should be treated.

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 opens with a precise verb and resource: 'Exposes GET /result/:token. Returns the result of a past request.' It immediately distinguishes this tool from sibling tools by explaining that it is the collection mechanism for async calls, turning a returned token into the corresponding result.

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 when-to-use context: 'any tool called without sync: true answers with a token, and this turns that token into the result.' It also covers the free re-read case. It does not explicitly contrast with siblings like get_request or list_requests, but the async-token trigger is a strong usage signal.

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?

Adds behavioral context beyond annotations: credit cost, runtime, and that it fetches the page itself (leading to two page visits inside scrape_url). Annotations already indicate idempotency and non-read-only status, and the description aligns with them. 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 sentences, each adding value: core function, cost/time, and the page-fetch caveat. Information is front-loaded with the action and followed by important caveats. No redundant phrasing.

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 an output schema present, return format is covered. The description addresses purpose, cost, runtime, and a behavioral quirk. It doesn't explicitly mention alternative tools, but cost and time context help in choosing. Adequate for the complexity, though a 'use this when' hint would be a minor improvement.

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 all parameters are documented in the schema. The description does not elaborate on parameter semantics beyond noting cost and page-fetch behavior, which are not parameters. It doesn't clarify usage of sync, max_age, or idempotency_key beyond schema, so baseline 3 is appropriate.

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+resource ('Runs a real Google Lighthouse audit against the live page') and enumerates the categories covered (performance, accessibility, best-practices, SEO, Core Web Vitals). It also distinguishes itself from page-fetch tools by noting it fetches the page itself, differentiating it from scrape_url 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?

It provides cost (2 credits) and time context ('takes longer than anything else here'), implying it is for when a deep audit is needed and the expense is acceptable. It does not explicitly name alternatives or give when-not-to-use conditions, but the cost and runtime signals offer clear decision-making 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?

Beyond the annotations, the description discloses billing semantics ('billed and stored exactly as the individual call would be'), the partial-failure response shape, and the visit-sharing exceptions. The idempotent and non-destructive hints are not contradicted, and the extra context materially improves the agent's model of the call.

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 front-loaded with the core purpose and each paragraph earns its place: behavior, response shape, and cost caveats. The length is justified by the number of interacting options, and there is no redundant wording.

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 no output schema, it describes the response structure explicitly. It also covers the important edge cases around residential surcharging, lighthouse, screenshot options, and partial failures, making the tool safely callable without needing to infer behavior from the schema alone.

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 documents all 13 parameters, so the baseline is 3. The description adds cross-parameter meaning by clarifying how operations and certain screenshot_options affect page-visit sharing and cost, which is not evident from reading the schema alone.

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: 'Exposes POST /scrape' and 'Runs any subset of the other operations in one request.' This makes the batching behavior clear and differentiates it from the individual sibling tools such as fetch_html, capture_screenshot, and lighthouse_audit.

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 explains when to prefer this tool: with a residential exit, several results from one page visit pay the surcharge once, while noting this is not a discount. It also gives when-not guidance by calling out lighthouse and screenshot options that force separate page fetches and therefore do not share the visit.

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 reveals that this is the most expensive operation at 17 credits, that it runs a language model over the page, and that the output strips boilerplate. This gives the agent important cost and behavior context that annotations do not convey.

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, with the core behavior in the first sentence and the cost/usage guidance in the second. Every sentence earns its place, and the alternative-tool guidance is integrated without verbosity.

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 the complete parameter schema and annotations, gives the agent enough to select and invoke the tool correctly. It explains cost, output format, and when to prefer a sibling. It does not detail the async return behavior, but the schema's sync parameter and sibling get_result already cover that path.

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?

All 9 parameters are already fully described in the schema, so the description does not need to repeat them. The high-level description correctly orients the agent toward the resource and result, but it adds no parameter-specific detail 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 names the exact endpoint ('POST /summarize'), states the output ('concise Markdown summary of the page's main content'), and specifies what is excluded ('navigation, ads and boilerplate'). It clearly separates this tool from cheaper page-fetching siblings like fetch_markdown by emphasizing that the summary itself is the product.

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 decision guidance: it is the most expensive option at 17 credits, and if the model is reading the page for itself, fetch_markdown is cheaper at 1 credit. It closes by stating the exact condition for using this tool: '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.