PageShot

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

With no annotations provided, the description carries the full disclosure burden. It successfully adds that the tool 'Returns base64-encoded images' (critical for response handling) and specifies the 'Maximum 5 URLs' constraint. However, it omits error handling behavior (what if one URL fails?), timeout characteristics, and resource intensity given this is a batch operation.

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?

Exactly three sentences with zero waste: action definition, output format, and constraint limit. Front-loaded with the core purpose, making it easy to scan and comprehend instantly.

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 13 parameters with complete schema coverage, the description appropriately focuses on tool purpose, output format (base64), and scope limits rather than repeating parameter details. Missing output schema is partially mitigated by the explicit return value description.

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 does not add parameter-specific semantics (e.g., explaining 'wait_until' strategies or geolocation behavior), but the high schema coverage means the description doesn't need to compensate for undocumented parameters.

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

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

Description uses specific verb 'Capture' with resource 'screenshots' and clearly identifies the scope as 'multiple URLs'. The phrase 'batch' in the name combined with 'multiple URLs' in the description effectively distinguishes it from sibling tool 'take_screenshot' (implied single) and from 'generate_pdf'/'render_html' (different output types).

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 implies batch usage through 'multiple URLs' and states the constraint 'Maximum 5 URLs', but does not explicitly compare against sibling alternatives or state when to prefer this over repeated calls to 'take_screenshot'. Usage is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden and successfully discloses the critical return format ('Returns PDF as base64'). However, it omits behavioral details like execution time expectations, browser context implications, or error handling for invalid URLs despite having 19 complex parameters.

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 filler, front-loaded with the primary action. Deducted one point for the inaccurate mention of 'margins' which creates slight confusion given no such parameter exists in the schema.

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

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

Adequate for a 19-parameter tool with no output schema, as it compensates by specifying the return format. However, given the complexity (cookies, auth headers, JavaScript evaluation), it should mention security implications or resource intensity.

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%, establishing a baseline of 3. The description adds value by grouping related capabilities ('page size, orientation...'), though it inaccurately mentions 'margins' which does not appear to be a parameter in the schema.

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

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

The description clearly states the specific action ('Convert') and resources ('webpage URL or raw HTML to a PDF document'), distinguishing it from screenshot siblings. It identifies the core transformation accurately.

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?

While the output format (PDF) implicitly distinguishes it from screenshot siblings, the description provides no explicit guidance on when to choose PDF generation over screenshots or how to handle the url/html mutual exclusivity (though this is covered in the schema).

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It establishes that raw HTML is processed locally without a URL, but fails to mention critical behavioral traits evident from the schema: JavaScript execution capabilities (the 'evaluate' parameter), headless browser context, external resource loading behavior, or the format of the returned image data (binary vs base64).

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 consists of two efficiently structured sentences. The first states core functionality immediately; the second provides use cases and the key differentiator ('No URL needed'). There is no redundant or filler text—every word serves to clarify scope or distinguish from alternatives.

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 high complexity (16 parameters including JavaScript execution, timezone localization, and viewport controls) and lack of output schema, the description is minimally adequate. It covers the primary use case but omits important safety context regarding arbitrary code execution via the 'evaluate' parameter and does not indicate the return value format (image bytes).

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%, establishing a baseline of 3. The description adds conceptual context by mentioning 'templates' (relating to the html parameter) and 'CSS' (relating to the css parameter), but does not provide additional semantic guidance on complex parameter interactions like how 'evaluate' interacts with 'disable_javascript', or viewport sizing recommendations beyond the schema's defaults.

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 provides a specific verb ('Render'), clear input ('raw HTML/CSS'), and output format ('to an image'). The 'No URL needed' phrase effectively distinguishes it from sibling screenshot tools that likely require URLs, while listing specific use cases (OG images, social cards, email previews) clarifies the target resource types.

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

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

The description provides clear contextual signals for when to use the tool (generating OG images, social cards, dynamic templates) and implies the key constraint (no URL needed) which differentiates it from take_screenshot. However, it lacks explicit 'when not to use' guidance or named alternatives among the 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully discloses the return format (base64-encoded image), which is critical given the lack of an output schema. However, it omits operational details like browser engine used, timeout behaviors, rate limiting, or whether the operation has side effects (network egress).

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 consists of two efficient sentences with zero waste. It is appropriately front-loaded with the core action and captures the essential return value information 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?

Given 26 parameters with complex capabilities (JavaScript evaluation, geolocation, authentication cookies, clipping), the description is minimally viable. It discloses the return format (mitigating the lack of output schema), but fails to mention browser context, concurrent limitations, or image size constraints that would help an agent invoke this rich tool effectively.

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%, establishing a baseline of 3. The description adds minimal parameter context beyond the schema, only implying the URL parameter via 'any webpage.' It does not clarify relationships between parameters (e.g., latitude/longitude dependency) or provide usage examples for complex parameters like 'evaluate' or 'cookies.'

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 the specific action (take a screenshot) and target (any webpage), and mentions the return format. While it implies single-page capture (distinguishing from 'batch_screenshot' by name), it does not explicitly differentiate when to use this vs. the batch alternative or vs. generate_pdf for documentation purposes.

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

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

The description provides no guidance on when to use this tool versus sibling alternatives like batch_screenshot (for multiple URLs) or generate_pdf (for document output). It also omits prerequisites like the URL being publicly accessible or handling authentication.

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