Api2Pdf MCP by usefulapi

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

Adds meaningful context beyond the lone destructiveHint annotation: it discloses that the call is BILLED, that the returned FileUrl is only valid ~24h, and it clarifies the distinct roles of user vs owner passwords. It does not cover failure conditions (e.g. invalid/encrypted source URL), which keeps it from 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 compact sentences, front-loaded with the operation and required inputs, followed by output, billing, and endpoint. Every clause carries information; nothing is padded.

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 supplies the return shape (FileUrl valid ~24h) and the billing note, and the schema covers the nested options/storage objects. Minor gaps remain around error behavior and whether the source PDF must be unencrypted, but the essentials for correct invocation are 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%, so the schema already documents all 10 parameters, setting the baseline at 3. The description only restates the roles of url, userpassword and ownerpassword, adding no syntax or format detail beyond 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?

States a specific verb and resource ('Encrypt an existing PDF (given as a URL)') and names the exact API route POST /pdfsharp/password. It is unambiguously distinguishable from siblings like api2pdf_compress_pdf or api2pdf_merge_pdfs.

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 establishes the precondition (an existing PDF supplied as a URL) and the effect (password-protect), which implies when to use it. However, it gives no explicit when-not guidance or naming of an alternative sibling for related tasks.

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 flag destructiveHint, so the description's additions matter: it discloses that the call is BILLED, that the result is a short-lived ({ FileUrl } ~24h) link, and names the underlying endpoint. It stops short of describing async/polling behavior or what happens to the source document, which matters for a billed mutation.

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 tight sentences, front-loaded with the action and input, followed by return shape, cost, and endpoint. Nothing redundant; every clause carries information an agent can act on.

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 output contract ({ FileUrl }, 24h validity) and the billing caveat. It could say more about the nested options/storage parameters and error behavior, but the schema carries the parameter detail well.

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 (url, inline, options, storage, fileName, output_binary, extraHTTPHeaders, useCustomStorage) documented in the schema itself. The description only reiterates the URL input and the FileUrl output, adding no syntax or format detail beyond the schema, so 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 (compress) and resource (existing PDF), plus the input form (a URL) and the goal (reduce file size). No sibling among the 16 tools offers compression, so this is unambiguous against the list.

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 stated goal implies when to reach for it (file too large), but there is no explicit when-to-use framing, no prerequisites, and no mention of limitations such as whether already-optimized PDFs benefit. Usage is inferable rather than guided.

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?

Adds real behavioral facts beyond the annotation: the call is BILLED, the result is a short-lived FileUrl (~24h), and the underlying endpoint is disclosed. It does not cover auth requirements or what happens when a source URL is unreachable, but the annotations only declare destructiveHint so the description is doing meaningful work.

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: what it does, why you'd want it, and the practical output/billing facts, with the endpoint last. Nothing is padding and the most decision-relevant information leads.

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, and the description compensates by naming the return shape (FileUrl, ~24h validity). Combined with a 100%-documented 8-parameter schema including nested storage/options objects, an agent has enough to invoke it correctly; only auth and failure behavior are left unstated.

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 8 parameters, so the schema already carries the semantics and the baseline is 3. The description restates only that the input is a URL and that a FileUrl comes back; it adds no format, size, or option-passing detail beyond 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?

States a specific verb and resource ('Convert a document or file ... to Markdown text') and names the engine (MarkItDown) plus accepted input families (PDF, Office docs). The direction-of-conversion is explicit, which cleanly separates it from the sibling api2pdf_markdown_to_pdf without needing to name it.

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?

One sentence gives implied usage ('Great for feeding a document's contents back to an agent'), which is a genuine context hint, but there is no when-not guidance, no mention of prerequisites (e.g. accessible/public URL, auth via extraHTTPHeaders), and no pointers to alternatives such as api2pdf_markdown_to_pdf for the reverse direction.

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 destructiveHint=true annotation already tells the agent this is a destructive operation. The description adds useful context that the target is a previously generated file identified by a generation ResponseId, but it does not discuss irreversibility, permissions, or other side effects beyond what the annotation provides.

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-loaded with the action and resource. The parenthetical clarification and API endpoint detail are useful and do not bloat the description.

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 single-parameter delete tool with no output schema and a clear destructive annotation, the description provides enough context to invoke it correctly. It could mention authorization or whether deletion is permanent, but the essential calling information 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?

The schema already documents responseId at 100% coverage, including that it comes from a prior generation response. The description repeats this meaning without adding format, constraints, or examples beyond the schema, so the baseline of 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 states a specific verb and resource: 'Delete a previously generated file by its ResponseId.' It also names the underlying API endpoint, making the operation unambiguous and easy to distinguish from sibling generation and 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?

It explains the required context for use: the file must have been previously generated and the ResponseId must come from a prior generation response. It does not explicitly state exclusions or alternatives, but none are necessary here because deletion is a distinct operation 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 only destructiveHint in the annotations, the description carries real additional weight: it discloses that the call is BILLED, that the result is delivered as a { FileUrl } valid ~24h, and that indices are 0-based. It omits auth/permission requirements and any note that options/storage/useCustomStorage alter the output path, so it is good but not complete.

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 operation, then the indexing rule, then the return contract and billing flag. The terse 'BILLED.' and endpoint line earn their place without 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 10-parameter tool with nested objects (options, storage) and no output schema, the description covers the return value, its lifetime and the billing model, which is the critical missing piece. It does not address error cases (e.g. out-of-range indices) or authorization for protected source URLs.

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 url, start, end, storage, inline, options, fileName, output_binary, extraHTTPHeaders and useCustomStorage. The description's 0-based index and omit-end notes merely restate the schema, so this sits at the 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 names a specific verb+resource ('Extract a range of pages from an existing PDF ... into a new PDF') and pins the input form (URL), which cleanly separates it from siblings like api2pdf_merge_pdfs or api2pdf_compress_pdf. It also identifies the underlying endpoint (POST /pdfsharp/extract-pages).

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 context is clear: page-range extraction from a URL-hosted PDF, with the 'omit end for a single page' case explained. It does not, however, name when to prefer a sibling (e.g. merge/compress) or state any exclusion or prerequisite such as auth on the source URL.

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 only destructiveHint=true in annotations, the description carries most of the burden and delivers real context: the return shape ({ FileUrl } valid ~24h), the base64 alternative via output_binary:true, and the fact that calls are BILLED. It does not explain why destructiveHint is set or what permissions/auth are needed, so it isn't fully transparent.

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?

Front-loaded with the action, then parameter clarification, return value, billing flag, and endpoint in five compact sentences. Nothing is padding, though the endpoint string adds little for an agent selecting the 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?

No output schema exists, and the description compensates by describing the return value, its ~24h validity, and the base64 variant. Combined with 100% parameter coverage in the schema, an agent has everything needed to call and interpret the result.

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 the schema already documents all six parameters. The description restates format and value and adds a small note on output_binary's effect, but adds no syntax, default, or format-list detail beyond 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?

States a specific verb+resource ("Generate a barcode or QR code image") and immediately grounds it with the two required inputs. It is unambiguous against every sibling, all of which are PDF/image conversion or file-management 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?

Usage context is only implied: the description notes it is BILLED and maps to GET /zebra, but never says when to choose this over siblings or when not to call it. No prerequisites or alternatives are named, leaving the agent to infer it is the only barcode path.

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 safety profile is covered externally; the description adds only the endpoint mapping and the word 'configured', hinting that credentials come from configuration. It says nothing about what the balance payload contains, whether usage and balance are distinct fields, or any rate limits.

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, no filler, with the outcome front-loaded and the API mapping trailing as supporting detail. Every clause 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 a trivial read-only, parameterless tool with annotation-covered safety, the description supplies what an agent needs to select it. The only missing element is any hint about the shape of the balance response, which is minor given there is no output schema.

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 there is nothing for the description to disambiguate; baseline 4 applies. The 'configured account' phrasing usefully clarifies that the account is not passed in as an argument.

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 — 'Return the remaining balance / usage for the configured Api2Pdf account' — and even maps it to the underlying endpoint (GET /balance). It is trivially distinguishable from every sibling, all of which convert or manipulate files.

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 (check how much quota remains) but never stated as when-to-use, and no conditions or alternatives are discussed. For a zero-param account utility with no overlapping siblings this is tolerable, but it is guidance by inference rather than by direction.

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 safety profile is covered. The description adds the underlying REST mapping (GET /status), which is useful for an agent reasoning about the API, but it says nothing about auth requirements, rate limits, or failure behavior (e.g. what an unhealthy status looks like).

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 short sentences with the purpose front-loaded and the API endpoint as a compact trailing detail. Nothing is padded and nothing important is buried.

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 no-arg, read-only status endpoint with annotations covering safety, the description is nearly sufficient. With no output schema present, it could go one step further and hint at the shape of the health payload, but that is a minor omission rather than a blocking 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 takes zero parameters, so there is no parameter semantics to compensate for; the empty schema is self-explanatory and the description correctly implies no arguments are needed. Baseline 4 for a 0-param tool.

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 ('Return') and resource ('Api2Pdf service / health status'), which is immediately distinguishable from the document-processing siblings. It stops short of explicitly differentiating itself from the other meta-tool in the set, api2pdf_get_balance, but the resource is clear enough that an agent can tell them apart.

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 says what is returned but never states when to call it — e.g. before issuing PDF operations or when diagnosing failures — nor does it mention any alternative or prerequisite. Usage is only inferable from the endpoint's nature, not from the 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 only carry destructiveHint=true, so the description usefully adds the two things an agent most needs: the operation is BILLED and the default result is a FileUrl that expires in ~24h. It does not explain why the annotation marks this render as destructive, leaving one gap.

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, front-loaded sentences: purpose, return behavior, then billing and endpoint. No filler, and cost plus return shape are surfaced where an agent will see them.

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 essentials: what goes in, what comes back, how long it lasts, and that it costs money. The custom-storage path is left entirely to the schema, which is acceptable but not maximally 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%, including full prose for output_binary, so the schema already does the heavy lifting and a 3 is the baseline. The description restates the output_binary/FileUrl tradeoff and lifetime but adds no syntax or format detail not already 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?

States a specific verb and resource ('Render an HTML string to an image') plus the engine ('headless Chrome'). The 'HTML string' scope implicitly separates it from api2pdf_url_to_image, though no sibling is named explicitly, which keeps it just 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?

No statement of when to use this over api2pdf_html_to_pdf, api2pdf_url_to_image, or api2pdf_wkhtml_to_pdf, and no prerequisites or exclusions. The only guidance-like remark is the recommendation to prefer output_binary:false, which is parameter advice rather than tool-selection 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 only declare destructiveHint=true, so the description carries most of the burden and does so well: it discloses the default return shape ({ FileUrl }, valid ~24h) and that calls are billed per document. It stops short of explaining when the link expires relative to retrieval or what happens on failures, so it is strong but not exhaustive.

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?

Front-loaded with the core action and engine, followed by return shape, use cases, billing, and endpoint. Every sentence except the trailing 'Api2Pdf API: POST /chrome/pdf/html' endpoint restatement carries useful information; that last line is mild 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?

With no output schema, the description correctly fills the gap by describing the FileUrl return and its validity window, plus billing behavior. Nested options and custom-storage parameters are left entirely to the schema, which is adequate given 100% coverage but leaves the description slightly thin for an 8-parameter tool.

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 eight parameters including the storage and options objects. The description only indirectly touches output_binary by noting the default FileUrl return, adding little beyond the schema. 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?

States a specific verb (render), resource (HTML string to PDF), and engine (headless-Chrome), which implicitly separates it from api2pdf_wkhtml_to_pdf (different engine) and api2pdf_url_to_pdf (different input). It does not explicitly name those siblings, but the engine and input-type qualifiers give an agent enough to disambiguate.

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?

'Great for invoices, reports, and letters produced as HTML' implies the usage context, and 'BILLED per document' is a useful cost warning. However, there is no explicit when-not guidance and no named alternative (e.g. use wkhtml for legacy CSS, or url_to_pdf when you have a link), so routing is left to inference.

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 supply destructiveHint=true, a lower bar, and the description adds genuinely useful behavior the annotation cannot convey: the return is a FileUrl with a ~24h validity window and the call is BILLED (consumes credits). It still omits what 'destructive' means here, rate limits, or credit cost magnitude, so it is strong but not exhaustive.

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, front-loaded with the action, then the return value, then the billing flag and endpoint. No filler; each 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?

With no output schema, the description takes on the burden of describing the return and does so ({ FileUrl }, ~24h expiry), plus it discloses billing. It does not touch the options passthrough or output_binary alternative, but those are covered in the schema, so the gap is minor.

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 8 parameters (including nested options/storage) are already documented in the schema, establishing the baseline of 3. The description adds no parameter-level detail beyond the schema, so no credit above baseline is warranted.

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 ('Render a Markdown string to a PDF using headless Chrome') and names the engine, which cleanly separates it from siblings like html_to_pdf, url_to_pdf and wkhtml_to_pdf. An agent can identify the input type and output type 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 implies usage (a Markdown source string is required) and flags the billing cost, but never states when to pick this over html_to_pdf/wkhtml_to_pdf/url_to_pdf. No exclusions or prerequisites are given, so routing between the Chrome/WKHTML/URL PDF variants is left to inference.

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 only destructiveHint=true available in annotations, the description carries real added burden and delivers: it discloses that the call is BILLED and that the returned FileUrl has a ~24h lifetime. It still omits cost magnitude, credit/rate-limit behavior, and whether source PDFs are retained, 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 clauses front-load the operation, then the return, then billing and the API route. No sentence is wasted and nothing requires reading ahead to understand the core action.

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 essentials an agent needs to call it correctly: ordered URL input, the FileUrl return with its expiry, and the billing implication. Remaining gaps (custom storage, binary output, options pass-through) are fully covered by the 100%-coverage schema, so the definition is close 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%, so every one of the 8 parameters is already documented in the schema, including the ordering semantics and the storage/options nesting. The description only restates 'URLs, in order' and adds nothing about options, storage, useCustomStorage, or output_binary, 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 gives a specific verb and resource ('Merge several existing PDFs ... into a single PDF') and immediately names the input form (URLs, ordered) and the underlying engine endpoint. An agent can distinguish it at a glance from siblings like api2pdf_compress_pdf or api2pdf_extract_pages.

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 the input shape and ordering constraint, which implies when the tool applies, but never names an alternative or a when-not condition (e.g. when to use extract_pages or compress_pdf instead). Usage context 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?

Annotations only carry destructiveHint=true, which says nothing useful for a conversion tool; the description supplies the operationally relevant facts instead: it is BILLED (a cost signal the agent should weigh), and the result is a FileUrl valid ~24h. It omits auth requirements and any rate/throughput behavior, so it is strong but not complete.

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 compact sentences with zero waste: purpose and engine first, then the return shape with its 24h expiry, then the billing flag and raw endpoint. Every clause earns its place and the critical scoping 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 correctly carries the return contract ('Returns a { FileUrl }, valid ~24h'), and it covers engine, accepted formats, billing, and the underlying API route. It stops short of noting that output_binary can instead return base64 bytes and how storage/useCustomStorage change the destination, which slightly limits completeness for this 8-parameter tool.

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 8 parameters, so the schema already documents url, inline, options, storage, fileName, output_binary, extraHTTPHeaders, and useCustomStorage. The description only implies the URL input and the FileUrl output and adds no syntax or format detail beyond the schema, so 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 ('Convert an office document ... at a URL to a PDF using LibreOffice') and enumerates the accepted source formats (Word, Excel, PowerPoint, ODT). That format/engine scope is what separates it from the sibling url_to_pdf, html_to_pdf, and wkhtml_to_pdf tools without needing to open a 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 implied by the accepted document types ('office document ... Word, Excel, PowerPoint'), which tells the agent when this tool fits. However, it never explicitly says when to prefer it over url_to_pdf or html_to_pdf, nor states any prerequisites or exclusions, so the agent must infer the routing decision.

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 are thin (only title and destructiveHint=true), so the description carries most of the load and does add real value: it discloses that the operation is BILLED, that the return is a { FileUrl } valid ~24h, and the underlying endpoint. It does not reconcile the odd destructiveHint=true for what reads as a non-destructive screenshot, but it never contradicts it. No auth or rate-limit context is given.

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, front-loaded with the operation, then the return shape, then the billing/endpoint metadata. No filler or repetition; every clause 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?

For an 8-parameter tool with nested objects and no output schema, the description supplies the essentials an agent needs: what it does, what it returns (a short-lived FileUrl), and that it costs money. The FileUrl-vs-output_binary tradeoff and custom storage flow live only in the schema, which is acceptable given full coverage.

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 8 parameters, including nested objects, so the schema already documents everything. The description only echoes the 'url' parameter ('by URL') and adds no syntax or format meaning for options, storage, output_binary, or extraHTTPHeaders. 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 pair ('Take a screenshot of a live web page'), the input form ('by URL'), and the engine ('headless Chrome'). The 'by URL' framing inherently distinguishes it from api2pdf_html_to_image (HTML input) and the 'screenshot/image' output distinguishes it from api2pdf_url_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?

The description gives no when-to-use guidance and never names an alternative. An agent must infer on its own when to pick this over api2pdf_html_to_image or api2pdf_url_to_pdf. No prerequisites or exclusions are 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?

With annotations only providing destructiveHint=true and a title, the description adds meaningful behavioral context: billing status, return format with ~24h validity, and the ability to pass auth headers during fetching. It does not explain why the operation is considered destructive, but it adds useful traits beyond 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?

The description is front-loaded with purpose, then output, auth tip, billing warning, and endpoint. Every sentence carries distinct information 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?

Given 8 parameters, nested objects, no output schema, and sparse annotations, the description supplies important missing pieces: the FileUrl return with TTL, billing status, and auth header usage. It does not explain storage or output_binary behavior, but the schema covers those fields 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 the schema already documents all 8 parameters, including nested objects. The description only highlights extraHTTPHeaders for auth and mentions the returned FileUrl, adding little semantic detail beyond the schema 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 states a specific verb and resource: 'Fetch a web page by URL and render it to a PDF using headless Chrome.' It identifies the engine (Chrome) and the API endpoint, but does not explicitly distinguish this tool from sibling PDF generators like api2pdf_html_to_pdf or 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?

It provides scenario guidance for one parameter ('Use extraHTTPHeaders to pass auth for a protected page') and warns 'BILLED,' which is useful context. However, it gives no explicit when-to-use-this-vs-alternatives guidance for choosing among the many PDF conversion 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?

Adds context the annotations don't carry: the operation is BILLED, the return is a { FileUrl } valid ~24h, and TOC support is engine-specific. It doesn't clarify what destructiveHint=true means for a render (file creation/overwrite/billing), but that is a minor gap against a real safety hint already present.

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 dense sentences, front-loaded with the engine and its differentiator, then return value, billing, and endpoint. No filler; each clause 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?

For an 8-parameter, nested-object tool with no output schema, it covers engine choice, output shape/lifetime, and billing. Storage/useCustomStorage and inline/attachment behavior are left entirely to the (100%-covered) schema, which is acceptable but slightly incomplete for a billed write operation.

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 baseline is 3, but the description goes beyond the schema's generic 'engine-specific options' passthrough by naming concrete keys (enableToc / tocOptions inside `options`). That is genuine added meaning for the one non-obvious parameter.

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 (render), resource (HTML string to PDF) and the engine (wkhtmltopdf), then positions it against the sibling Chrome path by name ('an alternate to Chrome'). An agent can distinguish it from api2pdf_html_to_pdf without opening either 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?

Gives clear selection context: this engine is the one that supports a table of contents, implying 'use this when you need a TOC.' It does not explicitly state when to prefer the Chrome sibling instead or name it, so it stops short of full routing guidance.

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