PDFDispatch

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

Adds real context beyond the annotations: rendering happens in Chromium and the result is a temporary download link that expires after one hour, which matters for any agent that plans to hand the link onward. It does not disclose failure modes (invalid HTML, unreachable images) or the escape hatch behaviour of extra_fields, and annotations already cover the write/open-world profile.

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, each carrying a distinct payload: what it does, when it is the right pick, and what you get back. Front-loaded with the action and 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 15-parameter tool with an output schema, the description covers purpose, fit and the returned artifact, which is the right division of labour. The main omission is that the extra_fields escape hatch to the underlying PDFDispatch API is only discoverable in the schema, not flagged as a notable capability.

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 15 parameters including html content rules, paper sizes, margins and header/footer placeholders are already documented. The description adds no parameter-level meaning beyond restating 'complete HTML document', so the baseline 3 applies.

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

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

States a specific verb and resource ('Turn a complete HTML document into a PDF') plus the engine used (Chromium), so the operation is unambiguous. It differentiates implicitly by scoping to 'designed documents' but never names the sibling converters (url_to_pdf, markdown_to_pdf, office_to_pdf) it must be chosen over.

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?

'Best for designed documents: invoices, reports, tickets, certificates' gives a concrete usage context that separates it from the URL/markdown converters. It stops short of explicit exclusions or naming the alternative to use when the input is a live URL or markdown source.

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 annotations, the description discloses that the returned download link is valid for one hour, which is important operational context not directly conveyed by readOnly/openWorld hints. It does not contradict the annotations, though it omits details such as authentication or file persistence.

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, front-loaded sentences with no wasted text. The core action and the link-expiry behavior are both stated immediately.

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

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

Given the rich input schema, output schema, and annotations, the description covers the essential purpose and the time-limited download link. It is sufficient for invocation, with the main gap being sibling differentiation rather than missing parameter or return-value 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 all 15 parameters are already documented in the input schema. The description adds no parameter-specific meaning beyond the implied default styling, making the baseline 3 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: turning Markdown into a PDF. It clearly distinguishes the input resource from siblings like html_to_pdf and url_to_pdf by naming Markdown, but it does not explicitly contrast itself with those alternatives.

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 explicit guidance on when to use this tool versus html_to_pdf, url_to_pdf, render_template, or other PDF-producing siblings. Usage is only implied by the input type, with no exclusions or selection criteria.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds the ordering semantics ('in the given order') and source constraints, which is real added context, but says nothing about whether a new artifact is produced or about size/count 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 tightly packed sentences with zero filler; the core operation and the ordering guarantee are front-loaded, and the input-source guidance follows immediately.

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 a rich nested input schema, full description coverage, and an output schema covering return values, an agent has what it needs to call this correctly. Only minor operational details (result location, limits on file count or size) are absent.

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 every parameter including the nested url/filename fields is already documented in structured form. The description reinforces that files are links and that order is significant, but adds no syntax or constraint 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 (merge) and resource (PDFs) plus the scope 'two or more, in the given order, into one' — enough to distinguish it from every sibling, all of which convert other formats into PDF rather than combine existing 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?

Explicitly tells the agent where input files come from ('results of other tools, upload_file links or public URLs'), which is the key routing decision an agent faces. It does not state when NOT to use it or name sibling alternatives, but the conversion siblings are clearly different operations, so the remaining risk is low.

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

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

Annotations only declare the safety profile (readOnly=false, destructive=false, openWorld=true, idempotent=false); the description adds real context beyond them: the conversion engine (LibreOffice) and the fact that inputs are fetched as links, implying network access and that local files must be uploaded first. It does not say what is returned or whether conversion state persists, but the output schema covers return shape.

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, zero filler, with the core conversion scope front-loaded and the input-mechanics caveat second. Nothing is repeated from the title or schema.

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

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

For a 6-parameter tool with a full schema and an output schema, the description covers the essential gaps: input must be a link, local files need upload_file first, and the engine is known. Minor omissions such as ZIP-vs-merged output for multi-file calls are already handled by the merge parameter's own description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter including merge, pages, landscape and extra_fields is already documented in structured data. The description only reinforces the url/upload linkage, adding no new syntax or constraints 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 (convert) and resource (office documents to PDF) and enumerates the input families (Word, Excel, PowerPoint, OpenDocument), which is exactly what separates it from html_to_pdf, markdown_to_pdf and url_to_pdf. An agent can route by input type without opening any 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?

"Files go in as links; use upload_file first for a file on the user's computer" gives an explicit prerequisite and names the sibling to call first — the most common failure mode for this tool. It does not explicitly exclude the other converter siblings, but the format enumeration makes the boundary 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?

Annotations declare the safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false, idempotentHint=false), so the description only needs to add context — and it does: the return is a download link valid for one hour, a non-obvious expiry constraint. It also discloses that totals and tax per rate are computed server-side rather than expected in the input. Minor gap: no note that each call produces a new artifact (consistent with idempotentHint=false but not reinforced).

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?

Four short sentences, each carrying distinct information: purpose, input style, computed behavior, mode constraint, return value. The most important routing detail (data, not HTML) is front-loaded and nothing is repeated from the schema.

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

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

An output schema exists, so return values needn't be detailed, yet the description still flags the one-hour link expiry, which is operational and not visible in structured fields. Combined with the mutual-exclusion rule and the computed-totals note, an agent has everything needed to call this correctly on the first attempt.

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 earns above that by stating 'Set exactly one of invoice, receipt, certificate or report,' which the schema does not enforce (no oneOf / mutual exclusion is expressed). That single sentence prevents the most likely misuse. It adds little about the remaining fields, but the schema already documents those thoroughly.

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

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

The description names a concrete verb and four concrete resources ('Make an invoice, receipt, certificate or report PDF from data') and immediately scopes the approach ('in a built-in design: send the data, not HTML'). An agent can distinguish this from html_to_pdf and markdown_to_pdf 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?

It gives a clear selection rule against the closest sibling ('send the data ... not HTML'), which routes template-driven requests here and free-form markup to html_to_pdf. It also states the one-of-four mode constraint. It stops short of naming the sibling tools or covering cases like markdown_to_pdf explicitly, so it is clear context rather than a full when/when-not matrix.

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

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

Annotations already cover safety and openness hints, and the description adds useful behavioral detail: the image is returned inline when under 1 MiB and also as a link valid for one hour. It does not describe failure handling or rate limits, but it adds meaningful return-behavior context beyond 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?

The description is two sentences with no wasted text. The primary purpose is front-loaded, followed by the practical return-size and link-expiry constraints.

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

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

Given the fully documented 13-parameter schema, output schema, and annotations, the description is nearly complete for correct invocation. It could still say more about alternatives among sibling tools, but it covers the essential capture behavior and return format.

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 13 parameters are already documented in the schema. The description does not add parameter-specific meaning such as mutual exclusivity between url and html or selector behavior beyond what the schema provides.

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: 'Capture HTML or a public web page as an image.' It clearly distinguishes the tool from PDF-oriented siblings by identifying the output as an image, so an agent can select it without inspecting 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?

It gives a clear usage context: checking a layout before making the PDF. However, it does not explicitly name the PDF alternatives such as html_to_pdf or url_to_pdf, and it does not state when not to use screenshot.

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

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

Annotations only declare the mutation/profile flags (readOnly=false, idempotent=false, destructive=false). The description adds genuinely useful context beyond them: the file is kept for one hour, is never downloadable, uploading costs nothing, and — critically — the actual transfer must be done with curl or any HTTP client rather than by the MCP call itself. It stops short of noting whether the link is single-use or time-limited or any size 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 compact sentences, front-loaded with the core action and immediately followed by the consumer tools and the retention/privacy constraints. Every clause carries 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?

An output schema exists, so return-value explanation is unnecessary, and the description covers cost, retention, privacy, and the transport mechanism the agent must use. Remaining gaps — link expiry/lifetime for the URL itself and any file size limits — are relatively minor for a single-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?

There is only one parameter and schema description coverage is 100%, with the schema itself explaining the filename-with-extension convention via an example. The description adds no additional semantics for the parameter, 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 states a precise verb and resource — 'Get a link to upload a file from the user's computer' — and clarifies that the tool provisions an upload URL rather than performing the upload or conversion itself. It also names the two sibling consumers (office_to_pdf, merge_pdfs), so an agent can distinguish it from the other eight tools without opening 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?

'for office_to_pdf or merge_pdfs' scopes the use case explicitly, which implicitly excludes tools like html_to_pdf, url_to_pdf, and screenshot that take URLs or text. It doesn't state an outright 'do not use for X', so it falls just short of a full when/when-not description.

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 openWorldHint=true and non-idempotent, non-destructive write semantics, so the bar is lower. The description adds one genuinely new behavioral fact — the download link expires after one hour — but says nothing about rate limits, failure behavior on unreachable or login-walled pages, or that a whole browser render is involved (slow/costly).

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, purpose first, return contract second. Every clause carries information and nothing repeats the schema or annotations.

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 14 fully documented parameters, an output schema, and annotations covering safety/open-world semantics, the description only needs to fix purpose and the return contract — both present. It falls short only of routing guidance among the four sibling converters, which an agent cannot derive from structured fields.

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 defaults, enum-like paper sizes and the escape hatch to the upstream API for extra_fields, so the schema carries the parameter load. The description contributes no additional parameter meaning, which is the baseline 3 case when coverage is complete.

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 ("Print a public web page to PDF") and adds the output form (download link). The word "web page" implicitly distinguishes it from html_to_pdf/markdown_to_pdf/office_to_pdf siblings, but those alternatives are never named, so the agent must infer the split.

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 word "public" is a useful negative constraint (no authenticated or internal pages), but there is no explicit when-to-use versus html_to_pdf or screenshot, and no guidance on when the wait_delay/wait_for_expression options matter for script-rendered pages.

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