PageShot

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

With no annotations, the description carries the full burden. It discloses the output format (base64-encoded images) and the 5-URL limit, but does not mention error handling, partial failures, or side effects (e.g., network activity). This is minimal but better than no disclosure.

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 concise sentences with no filler. The action, output format, and key constraint are front-loaded, making it easy to scan.

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 13 parameters and no output schema, the description should specify the return structure (e.g., array of base64 strings mapped to URLs) and clarify behavior if some URLs fail. It only says 'returns base64-encoded images', which is ambiguous for a batch operation. The rich schema covers parameters, but return/error handling is incomplete.

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%, with every parameter having a description including defaults and constraints. The tool description adds no extra parameter details beyond what the schema already 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?

The description clearly states the tool captures screenshots of multiple URLs in a single request, distinguishing it from single-screenshot or PDF-generation siblings. The verb 'capture screenshots' plus the resource 'multiple URLs' makes the purpose explicit.

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 this is for batch scenarios ('multiple URLs', 'single request', 'Maximum 5 URLs') but does not explicitly compare to take_screenshot or other alternatives. No exclusions or when-not-to-use guidance is provided.

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 only mentions that the tool returns a base64 PDF and supports certain options, but it does not disclose potential side effects (e.g., network fetching, JavaScript execution, headless browser usage), error conditions, or any safety considerations. This is a significant gap for a tool with 19 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?

The description is exceptionally concise: two sentences front-load the core purpose, then list capabilities and output format. Every sentence earns its place, and there is no redundant restating of the tool name or schema details.

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

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

Given the tool's complexity (19 parameters, no output schema, no annotations), the description is too thin. It does not mention the headless browser context, execution behavior (e.g., JavaScript execution, network requests), potential performance implications, or any usage tips for advanced options like wait_until. The schema covers parameter details, but the description fails to provide a holistic overview of the tool's behavior and constraints.

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 has 100% parameter description coverage, so the baseline is 3. The description mentions page size, orientation, margins, and background printing, which map to existing parameters but do not add new meaning or clarify usage beyond the schema. It does not explain the url/html exclusivity or any parameter interdependencies, but the schema already handles that.

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 verb "Convert" and the resource (webpage URL or raw HTML) to a PDF document, which immediately distinguishes it from sibling tools that handle screenshots or HTML rendering. It also explicitly mentions the output format (base64), making the tool's purpose 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?

The description conveys the tool's context: it converts web content to PDF, and indicates the accepted input types (URL or raw HTML). However, it does not explicitly mention alternatives or when to prefer this over sibling tools like take_screenshot or render_html. Still, the clarity of purpose provides enough context for an agent to decide appropriately.

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?

Without annotations, the description must disclose behavioral traits. It clearly states it renders raw HTML/CSS and doesn't need a URL, which sets expectations. However, it does not disclose details about execution context (e.g., headless browser, loading strategies) or any constraints beyond the schema. It adds minimal behavioral context beyond what parameters already imply.

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 function, and each sentence adds value: one defines the action, the other lists use cases and differentiation. 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?

Given the tool's moderate complexity (16 parameters, rich schema), the description provides a high-level context and use-case guidance but doesn't elaborate on the output or advanced behaviors. However, the schema covers the parameters, so the description is sufficient for a basic understanding. It could be more complete by mentioning the image output format or that it can capture elements, but it's acceptable.

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 16 parameters are documented. The description adds no parameter-specific information, relying on the schema. 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?

The description opens with a clear verb-resource pair: 'Render raw HTML/CSS to an image.' It further specifies scope by noting 'No URL needed' and gives concrete use cases (OG images, social cards, etc.), distinguishing it from URL-based screenshot siblings like take_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?

It states it is 'Perfect for generating OG images, social cards, email previews, and dynamic content from templates' – explicit use cases. The phrase 'No URL needed' differentiates it from URL-based tools and implies it should be used when HTML/CSS is available directly, though it doesn't mention sibling tools by name or state when not to use it.

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

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

The description discloses the return format (base64-encoded image), which is useful. However, with no annotations provided, the description carries the full burden for behavioral disclosure. It does not mention that the tool loads a webpage, executes JavaScript, or may handle cookies, popups, or geolocation—though these are hinted at in the schema.

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

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

The description is two sentences with zero padding. It front-loads the purpose and includes the essential return type, achieving maximum efficiency.

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

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

Given the tool's complexity (26 parameters, no annotations, no output schema), the description is minimally adequate but lacks high-level context. It tells what the tool does and returns, but does not help the agent choose among siblings or anticipate behavior like page loading or execution context.

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 has 100% description coverage across all 26 parameters, so the schema does the heavy lifting. The description adds no additional parameter meaning beyond confirming a URL is required, which is already stated 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 verb 'take' and resource 'screenshot of any webpage' clearly state the tool's primary function. It is concise and unambiguous, though it does not explicitly differentiate itself from siblings like batch_screenshot or render_html.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or sibling comparison, leaving the agent to infer usage context from the name alone.

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