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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context: lazy-loaded images are included, and the call costs '1 credit', which is a cost disclosure annotations cannot express.

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 sentences front-load what is returned and follow with the use case, plus a terse cost note. Every element carries information, though the trailing '1 credit.' fragment is abrupt.

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 so by naming the fields returned (URL, format, dimensions, file size). Combined with complete parameter docs and existing annotations, an agent has enough to call it correctly; pagination/ordering behavior is the only notable omission.

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 three parameters (url, limit, min_width) are already documented with meaning and defaults. The description adds no syntax or constraint detail beyond the schema; 'including lazy-loaded ones' is behavioral, not parameter-level. 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+resource ('List the images on a web page') and enumerates the returned fields (URL, format, dimensions, file size), which lets an agent distinguish it from extract_links, extract_metadata and screenshot by resource type. It never names a sibling explicitly, so it stops 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?

'Use it to find photos, logos or product images on a page' gives a concrete use context. There is no when-not guidance and no routing to alternatives such as extract_links when the agent actually wants hrefs rather than image assets.

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/idempotent/non-destructive, so the safety profile is covered. The description still adds real value beyond them by disclosing the cost ("1 credit") and the shape of the returned link records. It omits failure behavior for unreachable pages or JavaScript-rendered content.

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: capability plus returned fields first, usage second, cost last. Zero filler, and the most important information 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?

There is no output schema, and the description compensates by naming the returned fields. Combined with the annotations covering safety and the description covering cost and intent, an agent has everything needed to call this 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%, with url, the type enum, and the limit default/max all documented in the schema itself. 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 ("List every link on a web page") and enumerates the returned fields (anchor text, follow/nofollow, internal/external), which is enough for an agent to tell it apart from extract_images or extract_metadata. It never explicitly contrasts itself with those siblings, so it falls 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?

Gives three concrete use contexts: crawling a site, finding pages to read next, and auditing links. That is clear positive guidance, but it names no alternatives and gives no when-not-to-use conditions (e.g., use url_to_markdown when you want the page text).

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, openWorld and non-destructive, so safety is covered. The description adds value beyond that with cost ('1 credit') and a performance characterization ('faster and cheaper'), though it says nothing about failure behavior for unreachable URLs or missing meta tags.

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, front-loaded with what is returned, then purpose, then the cost/performance trade-off. Every sentence carries distinct 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?

No output schema exists, but the description enumerates the returned fields and their source (Open Graph, Twitter Card, HTML meta), effectively substituting for it. For a single-parameter read tool with rich annotations, nothing an agent needs 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 description coverage is 100% and the single 'url' parameter is fully documented with format and https:// guidance in the schema. 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?

States a specific verb (extract/get) and resource (link metadata) and enumerates exactly what is returned: title, description, preview images, favicon, site name, plus the source formats. It also implicitly distinguishes itself from siblings like url_to_markdown by being 'faster and cheaper than reading the whole 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?

Gives concrete use cases (summarize a link, build previews, check SEO tags) and a comparative heuristic against the heavier alternative of reading the full page. It stops short of naming the sibling tool (url_to_markdown) or stating 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds genuinely non-derivable context: cookie banners are auto-hidden, the cost is '2 credits', and desktop/mobile/full-page modes are supported. That is real value beyond the structured fields.

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 core action and result, followed by capability and cost details. Every sentence earns its place with no redundancy 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?

With no output schema, the description usefully clarifies that the tool returns an image, and it discloses cost and cookie handling. For a simple read tool, an agent has enough to invoke it correctly, though it could state whether large full-page captures have size limits.

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 four parameters with dimensions and defaults. The description's mention of 'desktop, mobile and full-page captures' maps to device/full_page but adds no syntax or meaning 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 and resource ('Capture a screenshot of a web page and return the image') and makes the output type explicit ('so you can see how the page looks'). This cleanly distinguishes it from siblings like url_to_markdown, extract_metadata, and extract_images, which return text or asset URLs rather than a rendered image.

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 phrase 'so you can see how the page looks' implies the use case (visual inspection), but there is no explicit guidance on when to choose this over the sibling extraction tools, nor any when-not conditions. Usage is implied rather than stated.

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 the safety profile (readOnly, idempotent, open-world, non-destructive), so the bar is lower. The description adds real value beyond them: it discloses content extraction behavior (stripping nav/ads/footers), JavaScript rendering support, and a cost of 1 credit – all useful for invocation decisions.

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

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

Four short sentences, all front-loaded with the fetch/return behavior first, then usage, then capabilities, then cost. Every sentence earns its place with no redundancy.

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

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

For a simple one-shot read tool with no output schema, the description covers what it returns (clean Markdown main content), when to use it, and its behavioral traits. The only minor gap is it never mentions the max_chars truncation behavior, but the schema handles that parameter adequately.

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 both url and max_chars are fully documented in the schema, establishing the baseline of 3. The description adds nothing about max_chars truncation or URL formatting, so it does not exceed what the structured fields already provide.

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 ('Fetch a web page and return its main content as clean Markdown') with the cleaned scope spelled out (no navigation, ads or footers). The output format implicitly distinguishes it from the extract_* siblings, which return metadata, links, or images rather than readable 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?

'Use this to read articles, docs, blog posts or any page the user mentions' gives clear context for when to reach for it. It does not, however, name the siblings (extract_metadata, screenshot, extract_links) or state when those are preferred, so routing is left partly to inference.

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