superPDF AI

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

With annotations already declaring readOnlyHint=false, idempotentHint=true, and destructiveHint=false, the safety profile is covered by structured data. The description adds nothing behavioral beyond that: it does not say the result is written to a new file, that output must not already exist, or that input/paths are restricted to allowed folders – all of which live only in the schema.

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

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

Two sentences, no filler, and the core capability is front-loaded before the syntax hint. Nothing in the text is redundant with the name or title in a wasteful way.

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 need not be described, and annotations carry the safety profile. Still, for a file-mutating tool with five parameters, the description omits placement defaults, the omit-pages-means-all-pages rule, and any sibling routing, leaving it only minimally 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 coverage is 80%, so baseline is 3, but the description genuinely compensates for the one gap: the 'text' property has no schema description, and the description supplies the {page} and {total} placeholder syntax. That is real value beyond the schema for a parameter an agent would otherwise have to guess at.

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 outcome: 'Add page numbers or a footer'. That is clearer than the title alone and tells the agent it stamps text onto pages. It does not, however, distinguish itself from near siblings like pdf_add_watermark or pdf_add_text, which perform visually similar stamping 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as pdf_add_watermark or pdf_add_text. The only guidance offered ('Use {page} and {total} in the text') is syntax help for one parameter rather than tool-selection advice.

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 the write/idempotent/non-destructive profile, so the description adds real value with the coordinate origin convention and the 'Latin characters only' limitation, a constraint not present in the schema or annotations. It does not restate the output-file/overwrite behavior, which the schema already covers.

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 with the action front-loaded, followed by the coordinate convention and the character limitation. No filler; every clause carries 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 an output schema, annotations, and 86% schema coverage, most structured detail is handled elsewhere. The description supplies purpose, coordinate convention, and the Latin-only constraint, leaving little an agent would need missing, though it says nothing about page-selection behavior beyond the 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?

Schema coverage is high (86%), so the schema already documents x, y, size, pages, input and output. The description restates the x/y origin (schema already says points from left/bottom edge) and adds the Latin-only text constraint, so it adds marginal meaning over the structured fields – 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 and resource (draw text on pages) and gives concrete use cases (typed signature, date, note). It is clear but does not explicitly differentiate itself from siblings like pdf_add_watermark or pdf_fill_form, which an agent might reasonably confuse it with.

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?

Examples of use cases imply when the tool is appropriate, but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as pdf_add_watermark or pdf_fill_form. Usage is only inferred.

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 the full safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description only needs to add context. It contributes the diagonal placement behavior that distinguishes a watermark from ordinary overlay text, but says nothing about appearance options (color, opacity, angle) or how the stamp relates to existing page content.

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

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

A single front-loaded sentence with zero filler; the action and its visual characteristic come first and the examples are compact. It is efficient, though it is arguably too terse to be maximally useful.

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 need no explanation, and the schema covers page selection and the no-overwrite output constraint. For a 4-parameter mutation tool, however, the description omits any note that the source file is left untouched and that a new file is always produced.

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 75%, so the schema already explains input, pages, and output semantics; the one undescribed parameter (text) is illustrated by the description's examples ('DRAFT or CONFIDENTIAL'). That small addition roughly matches the baseline for a well-covered schema with no syntax detail beyond it.

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 ('Stamp text ... across pages') and adds the distinctive manner ('diagonally') plus example values, which separates it from siblings like pdf_add_text or pdf_add_page_labels. It stops short of naming an alternative, so it is clear but not sibling-differentiated by name.

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 condition for when to choose this tool over the many overlapping siblings (pdf_add_text, pdf_add_page_labels, pdf_flatten). The example strings imply a content-marking use case, but no when/when-not guidance or prerequisites are given.

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 readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuine value beyond that by disclosing the output convention — the [-removed-] and {+added+} markers — which is non-obvious and would otherwise have to be discovered from the output 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?

A single sentence, front-loaded with the core action and followed by a tight colon-delimited list of what it reports. No wasted words.

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 two-path comparison tool with an output schema present and full schema coverage, the description says everything the agent needs: the inputs' roles, the granularity, and the diff notation. Nothing material 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 coverage is 100%: before, after, and max_chars are all documented in the schema, including the per-page character cap. The description adds no meaning beyond the schema, 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 (compare) and resource (text of two PDF versions) plus the scope (page by page). The added detail of what the output reports — changed/added/removed pages and words — distinguishes it from read-oriented siblings like pdf_read_text.

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 purpose implies when to use it (differencing two revisions of the same document), but no explicit when-to-use/when-not guidance or named alternatives are given. Adequate but no routing help among the large pdf_* sibling set.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description's 'one new PDF' is consistent with (and mildly reinforces) non-destructive creation, but it adds no information about permissions, allowed-folder enforcement, or the no-overwrite rule beyond what annotations and schema supply.

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

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

A single sentence with no wasted words, front-loading the action and the result artifact. Nothing redundant with the title.

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 full-coverage schema, an output schema, and annotations covering the mutation/idempotency profile, the description only needs to add the ordering semantic, which it does. It is complete enough to invoke correctly, though it says nothing about failure modes such as an already-existing output path.

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 baseline is 3, but the description adds one genuinely new semantic: the output page order follows the order given in the pages argument. That is behavior the schema's 'Page numbers or ranges, such as "1, 3-5"' does not convey.

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 ('Copy the listed pages ... into one new PDF') and clarifies the output is a newly created file rather than a modification of the input. This is clearly distinct from siblings like pdf_merge or pdf_remove_pages, but no sibling is named to reinforce the distinction.

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?

There is no explicit when-to-use guidance and no alternatives are named. An agent choosing between this, pdf_split, and pdf_remove_pages gets no routing help; the only hint is that page order is preserved, which implies a reordering/reordering-subset use case.

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 readOnly/idempotent annotations, it discloses substantial behavior: damaged pages are marked unread while others still convert, scanned pages go through OCR (15 languages), content is truncated at max_chars, and content is untrusted. This is rich, decision-relevant 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?

Purpose is front-loaded, but the body is a single dense run-on sentence enumerating every extracted element type, which is hard to scan and mixes high-value edge-case behavior (OCR, truncation, damaged pages) with minor item types.

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 complex extraction tool with an output schema, the description covers the key operational edge cases an agent needs: unreadable pages, OCR language scope, truncation, and untrusted content, so nothing critical 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 coverage is 50%; the description adds meaning for max_chars (content cut and marked truncated) and explains the optional page selection, but format enum values are left to the schema and input is documented in the schema. Baseline 3 for a tool where the schema carries most param detail.

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 (PDF text) with the three target formats, and the detail of extracting structure (headings, tables, charts, tree) clearly distinguishes it from pdf_read_text and pdf_extract_tables.

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 this tool is useful (structured extraction, long documents with a section tree, scanned pages via OCR) but never explicitly states when to prefer it over siblings like pdf_read_text or pdf_extract_tables.

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 a non-read-only, non-destructive, idempotent write, and the description adds real context: it writes a new file, uses one sheet per table for xlsx, and requires the output name to match the format extension. One caveat: the schema's 'Must not exist yet' constraint on output sits awkwardly with idempotentHint=true, so a repeat call apparently fails - a subtle inconsistency the description doesn't resolve, though not a hard contradiction.

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

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

Two sentences, front-loaded with the core action before the output-format and naming details. The parenthetical enumerations are dense but each carries useful content; nothing is redundant 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?

With an output schema present, return values needn't be explained, and annotations cover the safety profile. The description covers table types, output formats, and the naming constraint, leaving only minor gaps such as behavior on multi-page tables or overwrite handling.

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 75% (the format enum lacks a description), and the description compensates by explaining format-to-extension mapping and that xlsx produces one sheet per table. It reinforces the output naming rule, adding meaning beyond the schema's enum and minLength.

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 (find/extract tables in a PDF) and even enumerates the table types handled (ruled, shaded, borderless, vector charts). It also names the four output formats, so an agent can distinguish it from pdf_extract_structure and pdf_read_text 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?

Usage is implied (extract tabular data to a file) and the table-type breadth hints at coverage, but there is no explicit when-to-use or when-not-to-use guidance relative to siblings like pdf_extract_structure or pdf_read_text. The agent must infer that this is the tool for tabular data specifically.

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, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds real value beyond that by explaining the flatten side effect (values become part of the page and are no longer editable) and per-field-type value semantics. It doesn't cover auth or failure behavior, but the annotations make that omission tolerable.

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 dense sentences, front-loaded with the core action and immediately followed by the value-typing rule and the flatten consequence. No filler or restatement of the name/title.

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 need not be described. With annotations carrying the safety profile and the schema documenting paths and overwrite behavior, the description supplies exactly the missing operational semantics (field naming source, value typing, flatten effect).

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 baseline is 3. The description exceeds it by mapping value types to field kinds (text → text, check boxes → true/false, choices → one of their options), which the schema's generic string|number|boolean union does not convey.

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 (fill) and resource (form fields by name), which clearly distinguishes it from the many other pdf_* siblings that read, merge, split, or annotate. An agent can tell at a glance this mutates form field values rather than page content.

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?

Routes the agent to the correct discovery path with 'pdf_info lists them', which is a concrete prerequisite for finding valid field names. It stops short of naming explicit alternatives or when-not-to-use cases, so it's clear context rather than full routing guidance.

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

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds real behavioral context by explaining that form fields become baked into the page and permanently lose editability, which is the core consequence beyond what the annotations convey.

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

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

A single, front-loaded sentence that states the action and its consequence with zero wasted words. Nothing repetitive 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?

The tool is simple (2 fully-described params) and has an output schema, so return values need no explanation. The description covers the mutation's effect, and annotations carry idempotency; only edge behavior (e.g. a PDF with no form fields) is unaddressed, a minor 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?

Schema description coverage is 100%, so both 'input' and 'output' are fully documented in the schema, including the no-overwrite rule. The description adds no parameter-level detail, which is acceptable at this coverage level, giving the baseline of 3.

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

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

The description gives a specific verb ('Make form fields part of the page') and a precise resource (PDF form fields), with the resulting effect clearly stated. An agent can distinguish this from pdf_fill_form, though the description never names a sibling explicitly to route the choice.

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

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

Usage is only implied: the phrase 'so their values show everywhere and can no longer be edited' suggests this is used after filling a form to freeze values. There is no explicit when-to-use statement, no prerequisite (e.g. a filled form must exist), and no named alternative such as pdf_fill_form.

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 non-read-only, non-destructive, idempotent behavior, so the safety profile is covered. The description usefully adds that page count and ordering follow the input list, but says nothing about failure modes, the no-overwrite constraint, or the 200-image ceiling beyond what the schema states.

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

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

A single 16-word sentence with no filler, front-loading the action and then the two behavioral guarantees in the same breath.

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 need no explanation, and annotations cover the mutation/idempotency profile. The remaining constraints (allowed folders, non-existent output path, max items) live in the schema, leaving nothing an agent needs missing from the definition.

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?

With schema description coverage at 50%, the description does add meaning by clarifying that the order of the inputs array maps directly to page order. It adds nothing about the output path semantics (must not exist, no overwrite), though that is documented in the schema itself.

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 (make a PDF from JPG or PNG images) and adds the two defining behaviors: one page per image and input-order preservation. The image-only input format naturally distinguishes it from the pdf_from_office and pdf_from_markdown 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?

Usage is implied by the tool name and the format constraint, so an agent can infer it is the right tool when source material is a set of images. However, no explicit when-to-use or when-not-to-use guidance, and no alternatives are named.

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, idempotentHint=true, and destructiveHint=false, so the write-but-safe profile is covered. The description adds output-format context (A4/Letter pages, supported Markdown syntax) but says nothing about allowed-folder restrictions, permission needs, or failure modes. Adds modest value beyond the annotations, hence a 3.

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

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

A single front-loaded sentence with no wasted words; the parenthetical list of supported Markdown elements is informative rather than padding. It could still carry a routing clause, but on pure structure it is tight.

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 need not be explained, and the schema itself carries the 'must not exist / never overwrites' and allowed-folder constraints. For a straightforward converter the description covers the essential capability, leaving only usage routing unaddressed.

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 50%: input and output are documented in the schema, page_size is an enum with no description, and title is undocumented entirely. The description only echoes the A4/Letter page options and does not explain the title parameter or the input/output path constraints, so it adds marginal meaning over 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 ('typeset') and resource ('a Markdown file ... as a PDF'), and enumerates the supported Markdown constructs. It is clearly a conversion tool, though it never explicitly differentiates itself from the sibling pdf_from_office, which also produces PDFs from a source document.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternative tools. The usage is only implied by the tool name and the input being a Markdown file; an agent has to infer that pdf_from_office is the counterpart for non-Markdown sources.

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 the safety profile (readOnly=false, destructive=false, idempotent=true), so the bar is lower, and the description adds real value on top: the LibreOffice dependency and the specific failure mode ('fails with an install hint'). It does not add rate-limit or overwrite behavior beyond what the schema already states.

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: the conversion and supported formats are front-loaded, and the dependency/failure caveat follows. 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?

With an output schema present and annotations covering the safety profile, the description only needs to cover formats and the external dependency, both of which it does. An agent has everything required 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?

Schema coverage is 100%, so both parameters (input, output) are fully documented in the schema, including the allowed-folder and no-overwrite constraints. The description's format list loosely maps to the input parameter but adds no syntax or path-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?

The description states a precise verb+resource ('Convert ... to a new PDF') and enumerates the exact accepted source formats (.docx, .xlsx, .pptx, .odt, .ods, .odp). This distinguishes it cleanly from the other source-specific conversion siblings like pdf_from_images and pdf_from_markdown without needing to open 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?

It clearly establishes the context of use (an Office/OpenDocument file on this computer) and the prerequisite (LibreOffice installed), which routes the agent appropriately. It stops short of naming an alternative tool or stating when-not to use it, so it is clear context without explicit exclusions.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description contributes only the shape of the returned information, which is also partly covered by the output schema, so it adds limited value beyond structured fields.

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

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

A single front-loaded noun phrase with zero filler. It is efficient, though its telegraphic style omits a verb and reads as a field list rather than a complete statement of capability.

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 an output schema present and annotations covering safety, the description only needs to convey scope, which it does adequately for a one-parameter read tool. Nothing critical is missing, though a hint about when to reach for it over sibling inspection tools would round it out.

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 a single parameter ('input', a PDF path) and schema description coverage is 100%, so the schema fully documents it. The description adds nothing about the input path or its resolution rules, 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 names the specific resource (a PDF) and enumerates what is reported: page count, page sizes, form fields, and document properties. This distinguishes it from siblings like pdf_read_text or pdf_extract_tables, though it lacks an explicit verb (the title's 'Inspect' carries that load).

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 guidance on when to use this versus alternatives such as pdf_read_text, pdf_extract_structure, or pdf_outline. An agent can infer it is a pre-flight inspection step, but the description states no conditions, prerequisites, or exclusions.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds the non-recursive scoping constraint, which is genuine behavioral information, but nothing about return shape, ordering, empty-folder behavior, or permission failures; the disclosed return fields duplicate the output 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?

One sentence, front-loaded with the verb and resource, then the two constraints and the returned fields. Nothing redundant or 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?

An output schema exists, so return values need no explanation, and the single optional parameter is well covered. What remains thin is operational context: what 'allowed folder' means (configuration requirement) and whether the result is paged or ordered.

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 sole parameter is documented in-schema, including the omit-for-default behavior, so the description need not compensate. The phrase 'allowed folder' loosely reinforces the schema's constraint but adds no syntax or format detail beyond it.

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 (List) and resource (PDF files) plus scope qualifiers: non-recursive, inside an allowed folder, returning size and modification time. This clearly separates it from single-document siblings like pdf_info and pdf_read_text, though it never names an alternative tool.

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

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

Usage is only implied: an agent can infer this is the discovery step before reading/extracting, and 'not recursive' plus 'allowed folder' give scoping context. There is no explicit when-to-use or when-to-prefer-an-alternative statement, and no direction to pdf_info for single-file details.

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 the safety profile (destructiveHint=false, readOnlyHint=false, idempotentHint=true), so the bar is lower. The description adds that input order is preserved and that file count is unbounded, but it omits the important non-overwrite constraint and any failure behavior, which the schema carries instead.

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, front-loaded with the action, with no redundant or filler content. Every clause contributes either the operation, the ordering rule, or the size constraint.

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 need no explanation, and annotations cover the mutation safety profile. The description plus schema give an agent enough to call the tool correctly; only edge behavior on missing/unwritable paths is left implicit.

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 both parameters are already documented, including the ordering of 'inputs' and the non-overwrite rule for 'output'. The description only restates the ordering ('in the order given') and adds the unbounded-count detail, so 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 and resource ('Combine ... PDFs ... into one new PDF') plus the ordering semantic, so the operation is unambiguous. It does not name or contrast any sibling, but merge is unique among the listed tools so confusion risk is low.

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 operation itself ('combine 2 or more'), and the 'no upper limit' note hints at scale. There is no explicit when-to-use versus alternatives (e.g. pdf_extract_pages, pdf_split, pdf_from_images) and no mention of the preconditions such as the output file not existing.

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 the safe read-only, idempotent, closed-world profile, so the bar is lower. The description still adds real value by disclosing the heuristic source of the outline ('from bookmarks or detected headings'), warning the agent that results may fall back to inferred headings rather than authoritative bookmarks.

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

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

A single compact sentence that front-loads the resource and then the output form and contents. No filler; slightly dense but nothing wasted.

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 the description need not explain the tree structure, and annotations cover the safety profile. What remains — the input path convention and format choice — is covered between the schema and the description, leaving only sibling differentiation unaddressed.

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 50%: 'input' is documented in the schema but 'format' is not. The description compensates by enumerating the two output forms (Markdown list or JSON tree), which maps to the format enum, so it covers the gap adequately without adding syntax detail.

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 the concrete resource (the document's outline) and specifies both the source (bookmarks or detected headings) and the return shape (Markdown list or JSON tree with page ranges). It is clear and specific, though it does not explicitly distinguish itself from the adjacent pdf_extract_structure sibling, which an agent might plausibly confuse with an outline.

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?

There is no when-to-use guidance, no prerequisites, and no named alternative. With 30 siblings in the family, the absence of any routing hint (e.g., 'use pdf_info for metadata, this for the hierarchy') leaves the agent to infer selection entirely.

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 non-read-only, non-destructive, idempotent behavior. The description adds value beyond them by naming the cipher (AES-256), making clear that the result is a copy rather than an in-place mutation, and stating the observable outcome (password required to open). It omits anything about failure modes, permission needs, or what happens with an already-encrypted input.

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, and the core action and its effect are front-loaded before the safety constraint. Every clause carries 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 a rich annotation set and an output schema present, the description need not cover return values. It covers purpose, encryption strength, copy semantics, and password provenance; the only meaningful omission is behavior on already-protected inputs and any constraints on the source file.

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 67%: input and output are documented in the schema, but the password parameter has no description there. The description fills that gap by specifying the credential's provenance ('a password the user gave you for this purpose'), which is exactly the semantics an agent needs for that 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 and resource ('Encrypt a copy') plus the mechanism (AES-256) and the resulting behavior ('needs a password to open'), which makes it clearly distinct from pdf_unlock. It does not name or contrast with any sibling explicitly, so it stops short of the top anchor.

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?

'Only use a password the user gave you for this purpose' is a real usage constraint (do not invent, reuse, or repurpose credentials), which is more than nothing. However, there is no when-to-use guidance, no prerequisites (e.g. encrypted input, file permissions), and no reference to alternatives such as pdf_unlock or pdf_flatten.

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 readOnly/idempotent/non-destructive, but the description adds genuinely new behavioral facts: large documents are cut at max_chars and flagged truncated, continuation is done via the pages field, and the returned text is untrusted document content. The untrusted-content warning is behavioral guidance that appears nowhere in the structured fields.

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 core action and scoping. Each sentence carries distinct information (what it reads, the scanned-page caveat, the truncation/continuation rule plus the untrusted-content note); there is no 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?

Given a complete output schema, the description correctly omits return-value documentation and instead covers the failure mode (no text on scanned pages), the truncation contract, and the trust level of the content. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 67%, and the description fills the notable gaps: it explains max_chars' truncation consequence and the truncated marker, and it explains that the pages field is the mechanism for continuing past the cut. It adds meaning beyond the bare schema text for two of three 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?

Starts with a specific verb and resource ('Read the embedded text of a PDF, page by page') and qualifies it with 'embedded', which separates it from OCR-type or structure-extraction siblings such as pdf_extract_structure or pdf_info. An agent can pick this tool apart from its many siblings without opening the schema.

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

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

The description gives the key usage condition for this tool family: scanned pages have no text (has_text false), telling the agent when this tool will not deliver. It also explains how to continue reading (use the pages field after truncation). It stops short of explicitly naming an alternative tool for scanned documents, so it is clear context rather than full when/when-not 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 supply readOnlyHint=false, idempotentHint=true and destructiveHint=false; the description usefully confirms the non-destructive model ('write a copy') and, more importantly, enumerates the exact metadata fields removed (author, title, subject, keywords, creator, producer), which is context the annotations do not carry. It does not address other metadata carriers such as XMP or how existing output conflicts are handled, but the central behavioral trait — safe, additive stripping — is disclosed.

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

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

A single front-loaded sentence with the action and its exact effect, and zero filler. Nothing could be removed without losing 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 a simple two-parameter transform with a full output schema and safety annotations, the description plus structured fields cover what an agent needs. The only residual gap is what happens to non-listed metadata (e.g. XMP) and whether any permissions apply, neither of which blocks a correct call.

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%: both 'input' and 'output' carry full semantics, including allowed-folder constraints and the no-overwrite rule. The description adds no path, format, or constraint detail beyond that, so the 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 ('Write a copy') and resource (the document property set), and enumerates exactly which properties are stripped, so an agent can tell this apart from pdf_protect, pdf_flatten, or pdf_compare 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?

There is no when-to-use guidance, no mention of prerequisites, and no routing to any alternative or complementary tool among the 29 siblings. The only implied usage is 'you want metadata gone', which the name already conveys.

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=true, so the safety profile is covered. The description usefully clarifies that a NEW PDF is written (input is left intact) and adds the 'at least one page must remain' constraint, which is real behavioral context. It stops short of stating error behavior when all pages are requested or anything about output/path handling beyond the schema.

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

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

Two short sentences, zero waste, with the core action front-loaded and the constraint immediately after. 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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. For a simple, non-destructive, idempotent transformation with three fully documented parameters, the description plus structured fields give an agent everything needed to call 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?

Schema description coverage is 100% and all three parameters are well documented in the schema (path rules, page-range syntax, no-overwrite rule). The description adds no parameter-level meaning of its own. Baseline 3 applies when the schema carries the full load.

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 — 'Write a new PDF without the listed pages' — making the operation unambiguous. The negation ('without the listed pages') implicitly separates it from the sibling pdf_extract_pages, though that sibling is never named. Clear purpose, but no explicit sibling differentiation.

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

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

There is no explicit when-to-use statement or named alternative, but 'At least one page must remain' functions as a precondition that constrains valid invocation. Usage is implied by the verb+resource rather than guided. An agent must infer that pdf_extract_pages is the complementary tool.

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 the safety profile (destructiveHint=false, idempotentHint=true, openWorldHint=false), so the bar is lower. The description adds useful mechanism context — rebuilds the cross-reference table and emits a report of what was fixed — but says nothing about authorization/folder-permission requirements or how it behaves on unrecoverable files, which is the kind of detail a caller of a repair tool would want.

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 no filler; the core action ('rewrite a damaged PDF') is front-loaded and the secondary behavior (report of fixes) follows. 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?

With an output schema present, the description needn't explain return values, and annotations cover safety semantics. What it supplies — the rewrite plus xref rebuild and the reporting behavior — is sufficient to call the tool correctly, though a note on failure behavior for irreparable files would round it out.

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 two parameters (input, output) are fully documented in the schema, including the allowed-folder constraint and the no-overwrite rule. The description adds no parameter-level detail, which is the expected baseline when the schema does the work.

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 object: 'Rewrite a damaged PDF and rebuild its cross-reference table.' That is far more precise than the title alone and clearly distinguishes it from sibling operations like pdf_unlock, pdf_flatten, or pdf_extract_structure. It stops short of naming a sibling it could be confused with, so it falls just under the top mark.

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 'a damaged PDF' implies the trigger condition, but there is no explicit when-to-use statement, no when-not-to-use, and no routing to alternatives (e.g., use pdf_unlock for encrypted files or pdf_info to diagnose first). Usage is inferable but not 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?

Annotations already declare destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the safety profile is covered by structured data. The description adds the parameter ranges for crop vs scale but says nothing about what happens to the source file, output-file constraints, or processing behavior beyond what the schema already specifies.

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

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

A single sentence with zero filler, front-loading the two operating modes before their parameters. Every clause carries information the 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?

With annotations, an output schema, and near-complete schema descriptions, the remaining burden on the prose is small, and it covers both modes adequately. It omits any note on page selection behavior (the 'pages' parameter) or typical input/output expectations, but nothing essential to invoking the tool 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 coverage is 83%, so the baseline is 3, but the description goes further by explicitly binding mode=crop to margin (points) and mode=scale to factor (0.1–4), clarifying which parameter is live in each mode. That conditional mapping adds real meaning beyond the schema's simple '(crop)'/'(scale)' suffixes.

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 two specific operations—cropping a margin from each edge and scaling page content—and ties each to its mode value. This is a distinct verb+resource pair that no sibling (rotate_pages, extract_pages, add_watermark) performs, so an agent can identify it immediately.

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 mode/parameter mapping ('mode crop, margin in points' vs 'mode scale, factor 0.1–4') implies which mode to pick, but there is no explicit when-to-use-crop-vs-scale guidance and no mention of alternatives such as rotate_pages or add_watermark. Usage is inferable rather than 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds no additional behavioral context such as permission needs, rate limits, or what happens to the original file; it merely restates the core operation already present in the schema.

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

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

A single, front-loaded sentence with no wasted words. Perfectly sized for a simple operation.

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 tool is simple, and the schema plus annotations and output schema provide all necessary details. The description is minimal but sufficient, though it could mention that the operation creates a new file (otherwise covered by 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?

Schema description coverage is 100%, so the schema fully documents all parameters. The description repeats the rotation degrees and clockwise direction already covered by the schema and adds no new parameter semantics.

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 (rotate), resource (PDF), and the rotation degrees and direction. It is clear what the tool does, though it does not differentiate from other page-manipulation siblings like resize or flatten, and does not mention that only selected pages can be rotated.

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 guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description is purely a statement of function, leaving the agent to infer usage from context.

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, idempotentHint=true, destructiveHint=false. The description adds genuine value beyond them: sequential one-at-a-time processing, per-file failure isolation ('skipped and listed in failed... the rest continue'), and output naming convention. It doesn't cover permissions or output containment details, but the failure semantics are the important disclosure.

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

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

Three tight sentences, front-loaded with the core operation and bounds, followed by output location and failure behavior. Every sentence earns its place with no 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?

An output schema exists, so return details need not be explained, yet the description still highlights the failure/continuation semantics an agent needs. For a batch tool with fully covered parameters and annotations, 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 coverage is 100%, so all four parameters (inputs, steps, suffix, output_folder) are documented in the schema and nested step options are well described. The description adds only marginal meaning (that steps apply uniformly to every input, and output naming), which matches the baseline 3 when the schema carries the load.

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 ('Apply the same 1–10 pipeline steps to each of 1–50 PDFs') with explicit cardinality bounds. The batch scope implicitly but clearly distinguishes it from the sibling pdf_run_pipeline, which handles a single file.

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 1–50 file bound and 'one file at a time' framing make the intended use case clear: multiple files sharing one pipeline. It doesn't explicitly name pdf_run_pipeline as the single-file alternative or state exclusions, so guidance is contextual rather than 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?

Annotations already declare a non-read-only, idempotent, non-destructive write, and "write one new PDF" is consistent with that. The description adds the ordered-composition and 1–10 limit, but omits material behavior: whether the run is atomic when a middle step fails, whether the input file is left untouched, and any permission requirements.

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: the composition/limit/side-effect claim is front-loaded, followed by the action list and a single inline example. Nothing is repeated from 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 an output schema present, return values need no explanation, and input/output path rules are carried by the schema. What remains thin for a 9-action composite is failure semantics — what happens to earlier steps or the output file if a later step fails — which an agent composing long pipelines would want before committing.

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 would be 3. The description earns extra credit by surfacing the full action vocabulary and a concrete steps example ({"action":"rotate","options":{"pages":"1","angle":90}}), which orients the agent faster than parsing the oneOf const branches, though it adds no option semantics 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 ("Apply 1–10 steps in order and write one new PDF") and enumerates the valid step actions, which makes clear it is a composite of the per-operation siblings. It never names a sibling tool outright, so the routing distinction is inferable rather than stated.

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 1–10 ordered-steps framing implies this is for multi-operation workflows, but the description never says when to prefer this over calling pdf_rotate_pages / pdf_remove_pages / etc. directly, nor any exclusion (e.g. cannot be used with protected files). Usage is implied, not specified.

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 write semantics (readOnlyHint=false), idempotency and non-destructiveness, so the safety profile is covered. The description adds only the destination context ('Files are written to output_folder'), which the output_folder parameter description largely repeats; it says nothing about output naming, overwrite behavior, or what happens to pre-existing files in the target folder.

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 written sentences with the core action and both modes front-loaded; every clause carries information and nothing is redundant.

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 need no explanation, and the annotations cover the safety profile. The description covers the action, the two modes, and the output destination; the only meaningful omission is guidance on choosing this tool over pdf_extract_pages.

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 75%, and the description earns credit by explaining the enum values themselves ('one per comma-separated range' vs 'one per page'), which the bare enum in the schema does not define. It also clarifies the pages input as comma-separated ranges, matching the schema example.

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 (split) and resource (one PDF) and clearly enumerates the two output shapes: one file per comma-separated range or one file per page. It is distinguishable from pdf_merge, but it never contrasts itself with the close sibling pdf_extract_pages, so the differentiation is only partial.

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 mode semantics ('ranges' vs 'pages') implicitly tell the agent which behavior it will get, which is useful implied guidance. However, there is no explicit when-to-use/when-not statement and no pointer to alternatives such as pdf_extract_pages or pdf_remove_pages, so the agent must infer the choice.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds genuine behavior: preserved structure, OCR for scanned pages, and an explicit limitation that page layout and images are not reconstructed. Only the fact that the output file must not pre-exist is left to the schema.

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

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

Two tight sentences, front-loaded with the core conversion, followed by fidelity scope, OCR, and one limitation. Every clause carries information and none is redundant.

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 100% covered schema, full annotations, and an output schema (so return values need not be described), the description supplies the remaining behavioral context an agent needs: fidelity scope, OCR, and layout/image limitations. Only minor details like output-file pre-existence are left to 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%, so both required params and the pages param are fully documented in the schema; the description adds no syntax or semantics beyond that. Baseline 3 applies when the schema carries the parameter 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 verb (convert) and both the source and target resource (PDF → editable Word .docx), and enumerates what is preserved. It is clearly distinguishable from the many conversion siblings (pdf_to_pptx, pdf_to_epub, pdf_from_office) by output format.

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 conversion framing implies when to use it, and the note about OCR covers scanned-page inputs, but there is no explicit guidance on when to choose this over pdf_to_epub/pdf_to_pptx or other siblings. Usage is implied rather than 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?

Annotations declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, so the write/safety profile is already covered. The description usefully narrows the scope to 'a PDF's text', implying images and layout are not carried over, but it omits that the output path must not already exist and says nothing about failure modes or metadata handling.

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?

One tightly written sentence that front-loads the conversion and appends the splitting nuance. No filler, no restatement of the tool name.

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 need not be explained. For a 6-parameter converter the description is adequate but leaves gaps: it never warns that a text-only extraction loses images/layout, nor that the target file must not exist, both of which affect 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?

Schema description coverage is 50%, and the description only elaborates the 'split' behavior ('chapters at headings (or every few pages)'), which is genuinely helpful for interpreting the headings/pages enum. The title, author, and language parameters get no added meaning in either the description or 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 conversion ('Convert a PDF's text into an EPUB 3 e-book') and adds the chapter-splitting behavior. The destination format inherently separates it from pdf_to_docx and pdf_to_pptx, though it never names an alternative or scoping condition, so it lands just shy 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?

There is no when-to-use, when-not-to-use, or alternative routing guidance; the agent must infer that this is the EPUB path versus pdf_to_docx/pdf_to_pptx. The parenthetical about splitting at headings or every few pages describes behavior, not when to pick this tool over a sibling.

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 the safety profile (readOnly=false, destructive=false, idempotent=true), so the bar is lower. The description adds real value by describing the transformation output (slide-per-page, editable text boxes), but it omits the overwrite/pre-existence behavior implied by the schema, which is notable given idempotentHint=true.

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

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

A single front-loaded sentence with zero filler that states the conversion and the two most important output characteristics 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?

An output schema exists, so return values need not be explained, and all three parameters are schema-documented. The description covers purpose and output shape well; the only minor gap is the absence of any when-to-use context versus the other conversion siblings.

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 'input', 'pages', and 'output' are already fully documented in the schema. The description adds no parameter-level detail (e.g., accepted path syntax), 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?

Names a specific verb and resource (convert a PDF to a PowerPoint .pptx) and even specifies the output structure: one slide per page with editable text boxes. It does not explicitly differentiate itself from siblings like pdf_to_docx, so it falls 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?

There is no when-to-use guidance, no prerequisites, and no routing to alternatives such as pdf_to_docx or pdf_from_office. Usage is only inferable from the purpose statement, which calibration treats as insufficient for a 3.

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 and idempotentHint=true, so the safety profile is covered structurally. The description adds genuinely new behavioral context: it writes a *copy* (source is left intact) and it will never attempt password guessing, which explains the failure mode for an unknown password. It does not state what happens on a wrong password beyond that, but the added value is clear.

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, front-loaded with the action and outcome, and the second sentence carries the single most important constraint. No filler, no repetition of 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?

An output schema exists, so return values need no explanation, and the input/output path rules are fully specified in the schema. The description covers the essential behavioral facts (copy semantics, no guessing) for a 3-parameter mutation tool. A brief note on behavior when the password is wrong or when the PDF is unencrypted would make it 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 coverage is 67%, and the one parameter without a schema description is 'password' (also the only optional one). The description compensates by defining that the password must be one the user already knows and that the tool will not guess it, giving the agent the semantics the schema omits. The well-documented input/output path parameters are handled by the schema.

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

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

The description states a concrete verb+resource ('Write a decrypted copy') for a PDF, which maps cleanly onto the title 'Remove a PDF password'. It is unambiguous about the outcome, but it never names the inverse sibling pdf_protect, so the agent gets no explicit routing cue from the description itself.

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 clause 'using a password the user knows. Never guesses passwords' is a real usage boundary: it tells the agent this is only for PDFs whose password is supplied by the user, not for brute-forcing protected files. However, there is no explicit when-to-use guidance or reference to alternatives such as pdf_protect or how to detect that a PDF is encrypted in the first place.

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