url-to-pdf

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

Annotations already establish readOnly=true, destructive=false, and openWorld=true, so the safety burden is covered. The description adds genuinely non-redundant behavior: the call is free, and the server contains paid tools requiring a purchasable API key — auth and cost context the annotations do not 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?

A single sentence with three tight clauses, led by the highest-value fact ('Free'). No filler, no restatement of the tool name, and 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?

With no output schema, the description carries the return-value burden and does so reasonably — it enumerates capabilities, prices, and key-purchase location. It stops short of describing the response shape or format, which is a minor gap for a simple no-argument discovery endpoint.

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 rule baseline of 4 applies. Nothing in the description is needed to explain inputs, and it correctly says nothing about arguments.

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 concrete verb ('Returns') and specifies exactly what comes back: the server's capabilities, per-tool pricing, and where to obtain an API key. That content profile is unmistakably distinct from the sibling url_to_* conversion tools, so an agent can route to it 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?

Usage is only implied: the word 'Free' plus the capability/pricing content signals this is a discovery entry point, and mentioning 'where to buy an API key' hints that paid tools need auth first. There is no explicit statement of when to call this versus proceeding straight to a url_to_* tool, and no exclusion 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 the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true, idempotentHint=false). The description adds genuinely non-obvious behavioral context: an API key must be purchased at a specific URL, and auth matches the other paid tools. It does not mention rate limits or noise, but the auth gating is valuable.

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 tightly written sentences with no filler: output fields first, then the rendering approach, then the auth requirement. Every sentence earns its place and the most useful 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?

With no output schema, the description usefully enumerates the returned fields (title, meta description, canonical URL, language, main text, links), covering the return-value gap. Auth requirements are also stated. For an 11-parameter tool it is nearly complete, though it could clarify behavior on failed extractions or redirects.

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 11 parameters carry detailed descriptions with ranges, defaults, and semantics (e.g., waitUntil enum, maxLinks default 100). The description adds no parameter-level meaning, so the schema alone carries the load — 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') and resource ('structured data from a page') and enumerates the exact fields returned (title, meta description, canonical URL, language, main text, links). This clearly separates it from url_to_markdown and url_to_screenshot, though it never names those siblings explicitly.

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 'Readability-first, no LLM involved' hints at a positioning but gives no when-to-use guidance against the sibling tools (url_to_markdown, url_to_pdf, url_to_screenshot). It does not state when this tool is preferred over extracting markdown or a PDF.

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 cover the safety profile (readOnly, non-destructive, open-world). The description adds genuinely new behavior: the API-key precondition, the dual branching (render vs. purchase guidance), and the fact that output is a 1-hour download URL that expires. That expiry detail is material and not captured anywhere else.

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 the purpose before the auth/billing detail. The inline quoting of headers is slightly noise-prone, but nothing is repetitive or padding.

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 14-parameter tool with no output schema, the description covers purpose, auth prerequisites, and the return artifact (a 1-hour download URL / purchase guidance). The rendering behavior of the many viewport, ad-blocking and cookie options is left to the schema, which documents them fully, so the remaining gap is small.

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% across all 14 parameters, with ranges, defaults and enum values already documented. The description adds no parameter-level meaning, so this 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?

The opening sentence gives a specific verb and resource: 'Extract page content as clean Markdown.' That cleanly separates it from url_to_pdf and url_to_screenshot. However it never explicitly contrasts itself with the closer sibling url_to_extract, so it stops short of full sibling differentiation.

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 explains the billing/auth gate but gives no guidance on when to choose this tool over url_to_extract, url_to_pdf or url_to_screenshot, nor any prerequisites beyond the API key. An agent gets no alternative-selection 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 establish only the safety profile (readOnly, non-destructive, open-world). The description adds genuinely non-obvious behavior: a paid API key prerequisite, accepted credential locations ("x-api-key" or "Authorization: Bearer"), the dual-path response, and the fact that the returned download URL expires after 1 hour. That is exactly the context an agent needs before calling.

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 the action, then the prerequisite, then the branching outcome. The purchase URL sentence earns its place because it explains the failure mode an agent will otherwise misread as an error.

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 an 18-parameter, no-output-schema tool the description covers the critical unknowns: auth requirement and the shape/expiry of the result. It does not mention render-failure or timeout error behavior, a minor gap given that openWorldHint implies external variability.

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% across all 18 parameters, including ranges, defaults and enums, so the schema already carries parameter meaning. The description adds nothing about parameters, which is the correct baseline of 3 when the schema does the heavy lifting.

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 verb and output format ("Render a web page to PDF"), which cleanly separates it from url_to_markdown, url_to_extract and url_to_screenshot without naming them. It stops short of explicit sibling differentiation, but the artifact type makes the boundary obvious.

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?

Usage is implied by the auth explanation: with a valid key it renders, without one it returns purchase guidance. However, there is no guidance on when to prefer this tool over the sibling renderers (screenshot, markdown) or on limits such as page complexity, so the agent must infer selection criteria.

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 only declare the safe read-only/open-world profile; the description adds the load-bearing behavior the agent cannot get elsewhere: an API key is required, how the key is supplied (header), and the two distinct outcomes (1-hour download URL vs purchase guidance). For a tool whose output is a URL string, this is exactly the missing behavioral 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?

Two sentences with the core action front-loaded, followed by the prerequisite and the branch outcomes. No filler, and the purchase URL is functional rather than decorative.

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?

Despite 17 parameters and no output schema, the description covers the two things structured data does not: auth prerequisite and what the call returns in each case. Parameter semantics are fully handled by the schema, so nothing an agent needs to invoke 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?

Schema description coverage is 100%, so all 17 parameters (clip, waitUntil, deviceScaleFactor, etc.) are already fully documented in the schema. The description adds no parameter-level meaning, 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 output ('Capture a page as an image'), which cleanly separates it from the sibling destination tools (url_to_pdf, url_to_markdown, url_to_extract). An agent can identify the tool's job 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?

The description gives a concrete operating condition: with a valid x-api-key or Bearer header it renders and returns a URL, otherwise it returns purchase guidance. That tells the agent when the tool will actually work and what to expect. It stops short of explicitly routing between this and the sibling conversion tools, so it is clear context without alternatives.

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