Hydrafetch

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

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the agent knows this is not a pure read and may reach the open web. The description adds important behavior beyond that: it waits for the batch to finish, returns only the first page in the same call, routes further pages to batch_status, and discloses that each URL costs 1 credit. It does not cover authentication or rate limits, but the cost disclosure is a valuable addition.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no waste: purpose first, then behavior and routing to batch_status, then cost. Front-loaded and appropriately sized.

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 batch-scraping tool with no output schema, the description covers purpose, usage, waiting behavior, pagination, and cost. It could say more about the return format (e.g., markdown pages), but the schema's maxCharsPerPage description partly compensates.

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 schema already documents urls, wait, limit, and maxCharsPerPage completely. The description adds no parameter syntax or format details beyond that, so the baseline of 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 (scrape) and resource (list of URLs) and distinguishes itself from map (which finds URLs) and scrape (single URL) by implication. An agent can tell what this tool does without opening the schema.

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?

Names the source of URLs ('pages found with map') and gives an explicit alternative for reading further pages or a running batch ('batch_status'). It does not explicitly exclude single-URL scraping, but the 'list of URLs' framing makes the boundary clear.

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

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

Annotations already carry the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so this is known to be a safe read. The description adds behaviors beyond that: results are returned one page at a time, in the order the URLs were sent, and the paging contract via nextOffset. It does not mention rate limits, auth, or terminal batch states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, and the what-is-it clause is front-loaded before the paging instruction. Every clause carries an actionable fact.

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?

There is no output schema, so the description is the only place an agent can learn the return shape; it names progress, a page of results, and nextOffset, which covers the paging loop. However, it omits the rest of the payload (completion state, totals, data.truncated) that the agent must interpret to decide whether to keep polling, so it is only partially complete for a no-output-schema tool.

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, but the description adds semantics the schema does not: the relationship between the returned nextOffset and the `offset` parameter, i.e., how the parameters chain across calls. It says nothing about `limit` or `maxCharsPerPage` beyond what the schema already states.

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 ('Read a batch') plus the concrete payload ('its progress, and one page of results'), and explicitly ties itself to the sibling that produced the input ('started with batch'). An agent can distinguish this from `batch` (the creator) and from `crawl_status` without opening either schema.

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 an explicit conditional instruction for pagination: 'When nextOffset is not null, pass it as offset to read the next page of results.' This tells the agent exactly how to continue, but offers no guidance on when not to call it (e.g., completed/failed batches) or how it differs from other status siblings.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is handled externally. The description adds that data is derived from a domain and aggregates multiple asset types, but says nothing about caching, rate limits, or whether the domain must be resolvable. Adequate but not rich given annotations cover the core behavior.

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 sentences with the return contents front-loaded and the usage hint second; every clause earns its place and there is 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 no output schema, the description usefully enumerates the returned fields (logos, colours, name, description, social profiles), covering the main completeness burden for a single-param read tool. It stops short of clarifying edge cases (missing brand, unrecognized domain) or overlap with the 'logo'/'styleguide' siblings.

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% and there is only one parameter, so the schema fully documents 'domain' including the URL-tolerance note. The description adds no syntax or format detail beyond what the schema provides, 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?

Names a specific resource (a company's brand) and enumerates the concrete contents it returns (logos for light/dark, colours, name, description, social profiles), which is clearer than a bare verb+noun. However, it does not distinguish itself from the sibling tools 'logo' and 'styleguide', which plausibly overlap, so an agent cannot fully disambiguate from structure alone.

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 second sentence gives a use case ('answer what a company is or how it presents itself'), which implies intent, but it names no alternatives and offers no when-not-to-use guidance. Given overlapping siblings like 'logo' and 'styleguide', explicit routing would have been valuable and is absent.

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 openWorldHint=true, readOnlyHint=false, destructiveHint=false. The description adds genuinely new operational context beyond those: the job is asynchronous ('returns a crawl id straight away') and each page consumed costs 1 credit, which tells the agent to budget the crawl. It does not cover failure behavior or rate limits, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, correctly front-loaded: what it does, how to retrieve output, then the cost constraint. Every sentence carries distinct information and nothing is redundant.

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 still tells the agent the immediate return is a crawl id and where to follow up (crawl_status), and all three parameters are described. Minor gaps remain around error handling or authentication, but for a straightforward async crawl trigger this is close to complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description goes slightly beyond the schema by tying 'limit' to a concrete consequence (1 credit per page scraped, so set limit to what you need), which gives the agent a reason to tune that parameter rather than just its range.

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 ('discover and scrape the pages of a website') plus the mode ('as one background job, following its links from a starting URL'), so the agent knows this is a recursive multi-page scrape. It does not explicitly distinguish itself from the single-page sibling (scrape) or the URL-listing sibling (map), which keeps it just short of a 5.

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?

Implies when to use it (whole-site coverage via link following) and points to crawl_status for reading progress and results. However it never states when NOT to use it or names a competing alternative (scrape, map, batch) explicitly, leaving the usage boundary 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so safety is covered. The description adds genuinely new behavior beyond that: the call returns progress plus exactly one page of results, and the response carries a nextOffset sentinel (null = no more pages), which the agent needs to drive pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The core capability (progress + one page) comes first, and the pagination instruction that governs repeated invocation follows it.

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 carries the return-value burden and does explain the shape (progress, one page, nextOffset sentinel). It is nearly sufficient; the truncation signal (data.truncated) and terminal-condition wording are left to the schema, which is acceptable but not ideal given no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline would be 3, but the description adds a cross-call relationship the schema cannot express: the value to pass as offset comes from the previous call's nextOffset. Offset/limit/maxCharsPerPage mechanics are otherwise left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Read a crawl') and ties the resource to its producer ('started with crawl'), so the agent can distinguish this status/read tool from the crawl starter. It does not explicitly contrast with the parallel batch_status sibling, leaving that differentiation to be inferred.

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 a clear precondition (a crawl started with crawl) and an actionable loop rule for following pages via nextOffset→offset. It never states when NOT to use it or when batch_status is the right alternative, so it stops short of full alternative-routing.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that extraction is model-driven and constrainable by schema or prompt, but says nothing about cost, latency, rate limits, or failure behavior when a schema cannot be satisfied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action and followed immediately by the selection criterion. No filler or restated field names.

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?

No output schema exists, but the description explains the return shape (JSON conforming to a provided schema, or prompt-derived) and that multiple URLs can be processed. Adequate for an agent to call correctly; only an edge case like schema-vs-prompt precedence is unaddressed.

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 six parameters are already documented in the schema. The description mentions the schema/prompt duality but adds no syntax, precedence, or interaction guidance (e.g., whether prompt and schema can be combined) beyond the structured fields.

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+resource ('Pull specific fields out of one or more pages as JSON') and the two shaping mechanisms (JSON schema or prompt). It implicitly distinguishes itself from the scrape sibling by contrasting with 'the whole page text', though it never names the alternative tool.

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 a clear when-to-use condition with concrete examples ('prices, names or dates rather than the whole page text'), which effectively routes the agent away from scrape/crawl for targeted value retrieval. No explicit when-not or named alternative, 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, and the description does not contradict them. It adds some behavioral context (submitting gets the issue 'looked at', and where to find the requestId), but says nothing about what happens after submission, whether feedback is idempotent, or any throttling.

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 tight sentences, front-loaded with the purpose and then the trigger condition. 'A good rating is welcome too' is slightly conversational but carries real signal about the accepted input range.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-param feedback tool with no output schema and full annotation coverage, the description covers what the tool does, when to call it, and where to get the identifiers. Only the post-submission effect is left implicit.

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 is already documented. The description restates the requestId/URL sourcing rather than adding new meaning, so it sits at the baseline of 3.

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: tell Hydrafetch whether an earlier result was accurate, i.e. rate a prior call's output. It also names the triggering siblings (scrape, search, other calls), so an agent can distinguish it from those tools without opening a schema.

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 a clear trigger: use it after a scrape/search/other call returns missing, wrong or blocked content, and notes a good rating is also valid. It does not spell out a when-not condition or rate limits, but the usage context is unambiguous.

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

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

Annotations already declare this tool read-only and non-destructive, so the safety profile is covered. The description adds useful behavioral context beyond the annotations: it does not render the page, and it returns source images with metadata. This gives the agent a clearer mental model of what invocation will and will not do.

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 with no wasted words. The core action is front-loaded, and the comparison to screenshot is placed second where it helps decision-making without bloating the description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only tool with no output schema, the description is complete enough. It explains what the tool returns, how invocation behaves, and how it differs from a likely sibling. Nothing an agent needs to select or call this tool 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 schema already documents the single url parameter with 100% coverage, so heavy description compensation is unnecessary. The description reinforces that the URL identifies a page to harvest images from, but it adds no new parameter-level detail such as formats, defaults, or constraints. 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 ('Harvest') and resource ('a page's images with their metadata'), and explicitly distinguishes itself from a screenshot by noting it returns source images rather than a rendered picture. This makes the tool's purpose unmistakable and differentiates it from the sibling tool 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 gives clear guidance on when this tool is preferable to a screenshot: it is cheaper and returns source images rather than a visual representation. However, it does not explicitly mention when not to use it or name other alternatives among the siblings, so some selection context is left implied.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds genuinely non-obvious behavioral context beyond that: the relative cost ('a fifth as much') and the shape of the result ('one asset instead of the whole record'). It does not discuss caching, auth, or rate limits, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The output form is front-loaded in the appositive, and the routing rule against 'brand' follows immediately, so every clause 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?

With no output schema, the description usefully characterizes the return value as a single embeddable image URL, which is the key thing an agent needs. It omits error behavior and whether the URL is permanent or signed, so it falls just short of fully complete for a simple 3-param read tool.

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 both enums are fully explained in the schema, so the baseline is 3 per the rubric. The phrase 'chosen for the background you name' loosely reinforces the theme parameter's role, but adds no syntax, defaults, or constraints beyond what the schema already documents.

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 (a company's logo) and the concrete form it takes (a directly embeddable image URL), which is more precise than the tool name 'logo' alone. It also explicitly differentiates itself from the sibling 'brand' tool, so an agent can select correctly without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states exactly when to prefer this tool over the sibling: 'Use this rather than brand when the mark is all you need,' and backs it with two concrete selection criteria (cost and payload size). This is an explicit when-to-use and when-to-use-alternative statement.

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, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds substantive behavior beyond that: discovery is via sitemap and links only, with no content fetching, which tells the agent the operation is lightweight and non-rendering. It omits rate limits and output shape details.

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 sentences; the purpose and its scope constraint are front-loaded and the second sentence handles usage. Zero wasted words.

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?

There is no output schema, so the description responsibly states the return is a list of URLs. Combined with full schema coverage and covering annotations, it is nearly complete, though it doesn't describe pagination/limit interaction or ordering of results.

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% and both params (url, limit) are documented in the schema itself, including the 1-5000 range. The description adds no syntax, format, or constraint detail beyond the schema, so the baseline of 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 (list) and resource (URLs on a website) and immediately clarifies the mechanism (sitemap and links) and the negative scope ('without fetching their content'). This contrasts cleanly with siblings like scrape and crawl that do fetch content.

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 a concrete when-to-use: 'see which pages exist before choosing which to scrape,' which effectively signals the scrape alternative and a discovery-first workflow. No explicit exclusions or edge cases (e.g., when to prefer search or crawl), so not a full 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?

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful context about the return shape (main content as clean markdown, optional HTML/links/structured data) that goes beyond the annotations. It does not mention rate limits, auth needs, or failure behavior, so it falls short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core purpose and output, followed by usage and routing. Every sentence earns its place with zero 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?

There is no output schema, so the description reasonably compensates by describing the return (clean markdown plus optional HTML/links/structured data) and the routing context for a three-sibling group. Pagination, errors and auth are not addressed, but for a simple single-page read tool this is close to complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents url, formats and preferStructure thoroughly, including the 'structure came back plain' retry hint. The description's 'optional HTML, links or structured data' broadly restates the formats enum without adding syntax or defaults beyond what the schema provides, 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 (fetch), a bounded resource (one web page), and the primary output (main content as clean markdown) plus optional variants. It explicitly distinguishes itself from crawl (many pages) and batch (list of URLs), so the agent can differentiate without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit selection criteria: 'Use it to read a page whose URL you already have,' then names the two sibling alternatives crawl and batch with the conditions that select them (many pages of one site, list of URLs). Nothing is left 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?

Annotations already declare destructiveHint=false and openWorldHint=true, so safety is largely covered. The description adds that rendering happens in a real browser and that the result is a hosted PNG at a public URL, but it omits the persistent caching/storage side effect (readOnlyHint=false) that the schema alone explains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the core action front-loaded before the usage cue. Nothing could be removed without losing 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?

With no output schema, the description correctly states the return value (a PNG at a public URL), and the 8 parameters are fully covered by the schema. Only the caching/persistence behavior of the capture is left implicit.

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 (maxAge caching, timeout, waitFor, fullPage, viewport overrides) is already fully documented. The description adds no parameter-level meaning beyond that, which is the expected baseline.

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 ('Render a page in a real browser and capture a PNG') plus the return artifact ('its public URL'). This clearly separates it from sibling text-oriented tools like scrape, extract, and crawl.

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 an explicit selection condition: 'Use when the question is what the page looks like rather than what it says.' That implicitly routes the agent away from scrape/extract, though it never names the alternative tool.

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 establish read-only, open-world, non-destructive behavior, and the description adds useful context: results are ranked, each includes title/url/snippet, and enabling scrapeResults fetches markdown at an extra credit cost. 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?

Two sentences with the core function and return format front-loaded, followed by an efficient statement of the optional scrape behavior and its cost. 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?

With no output schema, the description usefully specifies the return fields and the markdown variant. It does not mention pagination or result limits, but the schema covers parameters and annotations cover safety, making the tool adequately callable.

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 description independently clarifies scrapeResults's markdown behavior and cost, but it does not add meaning for limit, query, or preferStructure beyond what the schema already provides.

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 (search the web) and names the return payload (ranked results with title, url, snippet). It does not explicitly contrast with sibling tools like scrape or extract, but the core purpose is unambiguous.

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?

Provides no guidance on when to choose search over its many siblings such as scrape, extract, or crawl. The only usage instruction is the conditional scrapeResults note, which addresses parameter behavior rather than tool selection.

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/openWorld/non-destructive, so the bar is lower, yet the description still adds meaningful behaviour: values are read from computed styles in a real browser and CSS variable references are returned resolved to the hex actually painted. It could say more about cache freshness semantics beyond the schema's maxAge note, but this is solid added 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?

Front-loaded with what is returned, then the resolution behaviour, then the screenshot alternative — a logical order. The middle sentence is dense but each clause describes a distinct part of the payload, so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the full burden of explaining return values, and it does so comprehensively: colour roles, contrast ratios, dark theme, type scale, radius, component styling, and generated stylesheets. An agent knows exactly what it will get and when to call screenshot instead.

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 all three parameters (url, domain, maxAge) are documented there with examples and defaults. The description adds no parameter-level meaning, so the baseline 3 is correct.

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: read a site's design tokens from computed styles in a real browser, and enumerates the exact payload (colours by role, contrast ratios, dark theme, type scale, radius, button/panel styling, CSS/Tailwind/shadcn sheets). It is clearly distinguishable from siblings like brand, logo, or scrape.

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 routes the agent to a sibling: use screenshot when the goal is recreating how a site looks rather than just its tokens. That is a real when-not condition, but it doesn't distinguish against other plausible neighbours such as brand or extract, so it falls short of full alternative coverage.

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