api2pdf

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

Beyond the destructiveHint annotation, the description discloses that the operation is billed, returns a FileUrl, and that the link is only valid for ~24 hours. It also identifies the exact API endpoint and engine. These are meaningful behavioral facts not present in the annotations or 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 tight sentences plus an endpoint identifier. It front-loads the action with 'Encrypt', then states required vs optional passwords, the output, the validity window, and the billing implication. Every clause earns its place; there is no padding or repetition.

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?

The description covers the core behavior, the required and optional inputs, the return value, the link expiration, and the cost implication. Combined with the fully self-documenting input schema and the destructiveHint annotation, an agent has enough context to invoke the tool 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%, so the schema already documents every parameter. The description restates the key semantics of userpassword and ownerpassword but adds no per-parameter detail beyond what the schema provides. This matches the baseline 3 for high schema coverage.

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 ('Encrypt') and resource ('existing PDF (given as a URL)') and clearly distinguishes the tool from siblings like api2pdf_compress_pdf or api2pdf_extract_pages. It also names the two key password concepts and the PDFSharp API endpoint, leaving no ambiguity about what operation is performed.

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 use case is clearly implied: apply password protection to an already-existing PDF available at a URL. It does not explicitly name alternatives or say 'use this instead of X', but the sibling set contains no directly competing password tool, and the description's precise wording supplies enough context. It also flags 'BILLED', which helps an agent weigh when to invoke 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 destructiveHint=true, so the safety/impact profile is partially provided. The description adds meaningful behavioral context beyond this: the operation is BILLED, returns a FileUrl valid for ~24h, and maps to a specific API endpoint. It does not contradict the annotation.

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 carry all essential information: what the tool does, the input format, the output shape, the time limit, billing, and the API endpoint. There is no filler or 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?

The description plus the fully-documented schema covers the required URL parameter, the returned FileUrl, its 24h validity, and billing implications. Given the rich schema and no output schema, this is sufficient for an agent to invoke the tool correctly. It could add error/edge-case detail, but nothing essential 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 every parameter already has a clear description in the schema. The tool description adds only the URL-as-input context and FileUrl output, but does not need to compensate for missing parameter documentation.

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 uses a specific verb ('Compress') with a clear resource ('an existing PDF (given as a URL)') and outcome ('reduce its file size'). It is immediately distinguishable from sibling tools like merge_pdfs, extract_pages, and delete_file, and the title adds the PDFSharp engine context.

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 clearly implies when to use the tool: when an existing PDF is available via URL and the goal is size reduction. It does not explicitly state when not to use it or name alternatives, but the context is unambiguous enough for 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?

The annotations already carry destructiveHint=true; the description adds valuable behavioral context beyond that by disclosing that the operation is BILLED, that the returned FileUrl is valid only ~24h, and by giving the exact API endpoint. It does not elaborate on what destructive behavior might occur, which prevents 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 with no filler. The main action is front-loaded, followed by the use case, return behavior, billing flag, and API endpoint—each 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?

For an 8-parameter tool with nested objects and no output schema, the description covers the essential invocation facts: input URL, output as FileUrl with 24h expiry, billing, and API endpoint. It leaves minor gaps around alternatives and the exact response shape, but the schema covers parameter details.

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 adds format guidance ('PDF, Office docs, and more') for the url parameter that goes beyond the schema's generic 'document/file' wording, giving agents useful selection context.

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 conversion direction ('Convert a document or file ... to Markdown text'), names the engine (MarkItDown), and scopes the input as a URL covering PDF and Office docs. This makes it easy to distinguish from sibling conversion tools like api2pdf_markdown_to_pdf or api2pdf_office_to_pdf.

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 gives a clear use case ('Great for feeding a document's contents back to an agent') and notes the URL-based input. It does not explicitly name alternatives or state when not to use the tool, so it falls 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?

The annotations already declare destructiveHint=true, lowering the burden on the description. The description adds useful behavioral context by clarifying that deletion targets files created by prior generation operations and that the HTTP method is DELETE, reinforcing the irreversible nature of the 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?

The description is two sentences with no redundancy. The core action and required identifier are front-loaded, and the endpoint reference is a compact addition that supports correctness.

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-parameter destructive operation, the description, schema, and annotations together provide everything needed: what is deleted, which identifier to use, and the safety profile. No output schema is required for a deletion call, and no critical details are 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 schema already explains that responseId is 'The ResponseId of the generated file to delete (from a prior generation response).' The description adds only minimal value by repeating this and mentioning the endpoint placeholder, so the baseline score 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?

The description states a specific verb ('Delete') and resource ('a previously generated file') and identifies the exact identifier required (ResponseId). It also mentions the underlying DELETE endpoint, which clearly differentiates this from the generation, conversion, and status-checking sibling tools.

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 clearly specifies when to use it: to delete a file that was generated previously using its ResponseId. While it does not explicitly list when-not-to-use or alternatives, no other sibling tool performs deletion, so the guidance is functionally complete for 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?

Given the destructiveHint annotation, the description adds valuable behavioral context: the operation is BILLED, returns a FileUrl valid for roughly 24 hours, and hits a specific Api2Pdf endpoint. It does not elaborate on the destructive hint, but 'into a new PDF' implies the source is not modified. This adds meaningful detail beyond the annotation without contradicting it.

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 compact and front-loaded: purpose, page-index semantics, output format, expiry, billing, and API endpoint are all conveyed in three sentences. Every sentence contributes information needed to call the tool correctly, with no filler or repetition.

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 10-parameter tool with no output schema, the description covers the essential return shape—a FileUrl valid ~24h—and flags that the call is billed. The remaining parameters are fully described in the schema, including nested objects and the output_binary alternative. Minor gaps such as not explaining rate limits or side effects are acceptable given the schema's completeness.

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 structured schema already documents all parameters. The description does reinforce the most important parameter semantics—0-based `start`/`end` and the single-page behavior when `end` is omitted—but does not add material new information for the other 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?

The description uses a specific verb and resource: 'Extract a range of pages from an existing PDF... into a new PDF.' This clearly separates it from sibling operations such as merge, compress, and convert, and it names the underlying API endpoint for further disambiguation.

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 tool's use case is clear and self-identifying: it extracts a page range from an existing PDF. It also gives concrete usage guidance about `start`/`end` being 0-based and omitting `end` for a single page. However, it does not explicitly contrast itself with any sibling tool 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 adds meaningful behavioral context beyond the annotations: it warns 'BILLED', explains the default FileUrl return with ~24h validity, and documents the output_binary switch to base64. It does not directly contradict the destructiveHint annotation, though that annotation seems surprising for a generation tool and is not clarified.

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 three compact sentences with no filler: purpose first, parameter clarification second, and response/billing context last. Every sentence contributes operational information an agent needs.

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 tool with no output schema, the description covers the return type, FileUrl validity, billing implication, and the API endpoint, while the schema covers individual parameters. It is sufficient for correct invocation, though it does not address potential error or size 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?

Input schema coverage is 100%, so the baseline is 3. The description adds value by clarifying that `format` is the symbology, `value` is the encoded string, and by specifying exactly what output_binary:true does (returns base64 instead of FileUrl).

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 and resource: 'Generate a barcode or QR code image.' It also names concrete symbologies such as QRCode, Code128, PDF417, and DataMatrix, which clearly distinguishes it from the sibling PDF/image conversion tools.

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 its use case through the purpose statement and unique tool name, but it does not explicitly say when to use this tool versus alternatives or mention any exclusions. Sibling differentiation is only incidental because no other sibling generates barcodes.

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 readOnlyHint annotation already establishes this as a safe read operation, so the description need not belabor that. It adds the 'GET /balance' endpoint and the concept of a 'configured' account, but it does not disclose output format, units, or potential error conditions; these are minor given the simplicity and annotation coverage.

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 short sentences with no filler, front-loads the core purpose, and includes a useful API reference. Every word contributes essential meaning.

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 zero-parameter, read-only tool, the description is nearly complete: it names the return concept (remaining balance/usage) and the underlying endpoint. It does not specify format, currency, or units, but these are not critical for invoking the tool correctly and no output schema is present to fill the gap.

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 has zero parameters, so the schema fully covers input requirements and the description need not add parameter detail. The description's mention of a 'configured account' clarifies that no account identifier needs to be supplied, which is useful context beyond the empty 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 action ('Return the remaining balance / usage') and the resource ('configured Api2Pdf account'), and it is unmistakably distinct from the sibling tools, which all perform conversion, compression, merging, or file operations. The specific endpoint reference also reinforces the tool's scope.

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 usage context is implied rather than explicit: an agent can infer this tool is for checking account credit/usage, and no alternative or exclusion criteria are mentioned. While the role is clear given the sibling list, the description does not state when to prefer this over, for example, api2pdf_get_status, which also queries account/job information.

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, so the description does not need to explain the read-only nature. It adds that this returns service/health status, but provides no further behavioral details like response format or rate limits. With annotations covering the key trait, the description adds modest context but not rich behavioral information.

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 a single, front-loaded sentence that immediately states the purpose, followed by the precise API endpoint. It contains no superfluous words and is perfectly sized for such a simple tool.

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 zero-parameter, read-only status check with no output schema, the description is fully sufficient. It tells the agent exactly what the tool does and even provides the REST endpoint for reference. No additional information is needed for an agent to invoke it 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?

The tool has zero parameters, and the schema confirms 100% coverage with no properties. Per the rubric, with 0 parameters the baseline is 4. The description does not need to explain parameters, and it does not attempt to, so this 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?

The description clearly states the verb 'Return' and the resource 'current Api2Pdf service / health status'. It also references the underlying GET /status endpoint, making the purpose unmistakable and distinct from all sibling tools, which perform conversions or file operations.

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 when to use this tool (when you need the current service health), but it does not explicitly state when to use it over alternatives or provide any exclusions. Since there are many sibling tools, none covering status, the usage is intuitively clear but not spelled out.

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?

Beyond the destructiveHint annotation, the description adds valuable context: the operation is BILLED, the default return is a FileUrl valid for ~24h, and output_binary:true switches to base64 bytes. This informs cost and result-handling expectations, exceeding what annotations alone provide.

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 fluff: the purpose, key output modes, billing, and API endpoint are all essential. The action is front-loaded, and 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?

The description covers input, output encoding, URL validity, cost, and endpoint, which is sufficient for a basic invocation. It omits guidance on advanced parameters (storage, headers) and alternative selection, but the schema is detailed enough to compensate.

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 adds the 'valid ~24h' detail and clarifies the output_binary behavior, but this largely mirrors the schema's parameter descriptions and does not significantly deepen parameter understanding.

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 and resource: 'Render an HTML string to an image using headless Chrome.' This clearly distinguishes it from siblings like api2pdf_url_to_image (URL source) and api2pdf_html_to_pdf (PDF output).

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 use for HTML-string-to-image conversion but never explicitly contrasts it with alternatives or states when not to use it. An agent can infer the niche, but no exclusions or alternative routing are 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?

Annotations only provide destructiveHint, so the description adds valuable behavioral context: the returned FileUrl is valid only ~24h, and the operation is BILLED per document. This alerts agents to cost and link-expiry implications beyond what annotations or schema 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?

Five short sentences, each contributing distinct information: input type, output format and validity, use cases, billing, and API endpoint. The description is front-loaded with the core behavior and contains 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?

For a moderately complex 8-parameter tool with no output schema, the description communicates the key return artifact (FileUrl), its lifetime, billing, and rendering engine. Since all parameters are fully described in the schema, the missing pieces are mainly explicit sibling routing guidance, which would push it 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%, with all 8 parameters already documented, including nested objects and output_binary behavior. The description adds no parameter-specific meaning, but it does not need to since the schema fully carries that burden.

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 action ('Render an HTML string to a PDF') and explicitly identifies the engine ('headless-Chrome'), making the tool's operation and scope clear. The API endpoint 'POST /chrome/pdf/html' further pins down the exact functionality and helps distinguish it from URL-based or wkhtml-based siblings.

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 clear intended use cases ('invoices, reports, and letters produced as HTML') and specifies that the input is an HTML string. It does not explicitly name alternatives or exclusions (e.g., 'if you have a URL, use api2pdf_url_to_pdf'), but the input and engine information gives an agent enough context to select 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 goes beyond the annotations by disclosing that the call is BILLED, returns a FileUrl, and that the URL is valid for approximately 24 hours. It also reveals the underlying API endpoint (POST /chrome/pdf/markdown), which adds useful operational context. The destructiveHint annotation is not contradicted, since the description transparently flags the cost-sensitive nature of the 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?

The description is three short sentences with no filler: purpose, return value and lifetime, and billing/API context. Each sentence earns its place, 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?

With no output schema, the description usefully explains the return value and its 24-hour validity, which is essential for an agent deciding whether to download immediately. Combined with the 100% parameter coverage and explicit billing warning, the tool is adequately specified for correct selection and invocation, though a note about authentication requirements would make it fully 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?

The description itself does not document any parameters, but schema description coverage is 100%, so every parameter already has a meaningful explanation in the input schema. The baseline of 3 applies because the schema carries the full burden and the description adds no additional parameter-level nuance.

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 and resource: 'Render a Markdown string to a PDF using headless Chrome.' This clearly distinguishes it from sibling tools like api2pdf_html_to_pdf, api2pdf_url_to_pdf, and api2pdf_office_to_pdf by source format and engine.

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 clearly defines the input type ('Markdown string') and rendering engine, providing enough context for an agent to select this tool when the source is Markdown. It does not explicitly name alternatives or exclusion conditions, but the resource constraint is unmistakable and sufficient for 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 include destructiveHint=true, and the description does not contradict that. It adds useful behavioral context: returns a { FileUrl } valid ~24h, is billed, and uses the API endpoint POST /pdfsharp/merge. It does not discuss auth or rate limits, but those are secondary given the annotation coverage.

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 deliver the core action, input format, output behavior, billing warning, and endpoint with no filler. 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, so explicitly stating the return type and 24-hour validity is valuable. The description covers the core call pattern and the schema documents all remaining parameters. It lacks error-behavior or side-effect clarification, but the essential information for a successful call is present.

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 parameters already have individual descriptions. The tool description mostly reinforces the urls behavior ('given as URLs, in order') and describes the result rather than adding substantial new parameter-level meaning. 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 names a specific operation ('Merge'), a specific resource ('several existing PDFs'), and adds ordering and URL constraints. It clearly distinguishes this from sibling tools like extract_pages or compress_pdf, and the API endpoint further removes ambiguity.

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 input requirements ('given as URLs, in order') and explains the output format and billing implication. It does not explicitly name alternatives or state when not to use this tool, but the context is specific enough to guide an agent.

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?

Beyond the destructiveHint annotation, the description discloses that this operation is BILLED and that the returned FileUrl expires in about 24 hours, both important behavioral traits. It also states the underlying API endpoint. The statement that it returns a FileUrl is slightly over-broad since output_binary can change that, but the schema clarifies.

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 deliver the core purpose, the output/expiry, the cost warning, and the API route with no filler. The most critical information (what it converts and to what) 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?

For a conversion tool with 8 parameters, nested objects, a cost implication, and no output schema, the description covers the essential behavior well: input kind, engine, output URL lifetime, and billing. It does not describe error cases or asynchronous behavior, but the schema covers parameters and the description gives enough for correct invocation.

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 already covers all 8 parameters with 100% description coverage, so the description does not need to explain parameters. It adds no parameter-level information beyond the schema, which is acceptable but not above 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?

The description uses a specific verb ('convert') plus a resource ('office document... at a URL') and target format ('to a PDF'), and names the engine (LibreOffice). It clearly distinguishes this tool from siblings like api2pdf_html_to_pdf or api2pdf_url_to_pdf by restricting input to office document formats.

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 makes the intended use clear: converting Word, Excel, PowerPoint, ODT, and similar office documents from a URL. It implicitly tells the agent not to use this for HTML or Markdown inputs, but it does not explicitly name sibling alternatives 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?

Beyond the destructiveHint annotation, the description discloses that the operation is BILLED, returns a short-lived FileUrl (~24h), and uses POST /chrome/image/url. It does not explain authentication prerequisites or failure behavior, but the cost and ephemeral-output warnings add real 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?

The description is front-loaded with the main action and contains no filler: action, output format/expiry, billing warning, and endpoint. 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?

For an 8-parameter tool with nested objects and no output schema, the description still gives the return shape, time-to-live, cost, and API endpoint. It could mention auth or load-wait behavior, but the schema covers parameter semantics, leaving only minor gaps.

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 descriptions already cover all eight parameters (100% coverage), so the description need not repeat them. It does not add extra parameter meaning beyond what the schema provides, hence the baseline 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?

Description uses a specific verb and resource: 'Take a screenshot of a live web page by URL using headless Chrome.' This clearly distinguishes the tool from siblings like api2pdf_url_to_pdf (PDF output) and api2pdf_html_to_image (HTML input rather than URL).

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 'live web page by URL' gives clear context for when to use it, but the description never names alternatives or states when not to use it (e.g., HTML strings should go to html_to_image). No exclusions are provided, so it earns a 4 rather than 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?

Beyond the destructiveHint annotation, the description discloses the return shape '{ FileUrl }', its ~24h validity, the billing side effect, and the exact API endpoint. This is meaningful operational transparency and does not contradict the 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?

Three short sentences convey behavior, output, auth, billing, and endpoint with no filler. The most decision-relevant information is front-loaded before the billing and API 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?

With no output schema, the description appropriately explains the return value and expiry. It also covers auth and billing, while the detailed input schema handles the remaining parameters. It omits the output_binary alternative, but the schema already documents that clearly.

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 parameters. The description adds only light reinforcement for extraHTTPHeaders and the FileUrl return; it does not need to compensate because the schema is rich.

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 specific verb-resource pair: 'Fetch a web page by URL and render it to a PDF using headless Chrome.' It also names the engine (Chrome) and API endpoint, which differentiates it from sibling tools like api2pdf_wkhtml_to_pdf and api2pdf_url_to_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 description gives explicit conditional guidance: 'Use extraHTTPHeaders to pass auth for a protected page,' and flags that the operation is BILLED. It does not explicitly compare against sibling PDF tools, but the Chrome engine and endpoint make the intended use case 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?

Beyond the destructiveHint annotation, the description adds important operational context: the operation is billed, the returned FileUrl is only valid for ~24 hours, and the underlying API path is disclosed. This meaningfully helps an agent understand side effects and expectations.

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 three dense sentences, front-loading the core purpose and engine, then return shape and billing. There is no filler or repetition of schema content.

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 8-parameter tool with no output schema, the description covers the essential non-schema facts: return shape, URL expiration, billing, and engine-specific TOC capability. It could be slightly more explicit about which sibling tool is the Chrome alternative, but overall it is adequate.

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 parameters. The description adds one useful parameter-level hint — enabling TOC via 'enableToc / tocOptions inside options' — but does not need to repeat what the schema already covers.

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 resource: 'Render an HTML string to a PDF using the wkhtmltopdf engine.' It also distinguishes itself from Chrome-based rendering by highlighting TOC support, though it does not explicitly name the sibling tool it differs from.

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 frames wkhtmltopdf as 'an alternate to Chrome' and mentions a unique capability (table of contents), implying when an agent should choose this engine. It stops short of explicit when-not-to-use guidance or naming the Chrome-based sibling, so it is clear context rather than full routing.

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