PDFWix

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

Annotations already cover mutability (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds that it 'stamps' numbers but does not disclose whether a new file is produced, whether the original is preserved, or any side effects. Minimal additional behavioral context beyond annotations.

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

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

A single sentence that front-loads the main action and summarizes the important options without filler. Every word contributes to understanding the tool's purpose and capabilities.

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

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

For a tool with 6 parameters, a nested file object, and no output schema, the description is adequate but relies heavily on the schema. It does not describe the return value or explicitly state that a new PDF is produced, though the schema and annotations fill most gaps.

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

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

Schema description coverage is 100%, so all six parameters already have meaningful descriptions. The description reinforces position, start_at, and format but adds no new meaning beyond what the schema provides. Baseline of 3 is appropriate.

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

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

The description uses a specific verb ('stamp') and resource ('sequential page numbers onto a PDF'), and lists the key configuration choices (corner, starting number, format). This clearly differentiates it from the sibling add_watermark, since page numbering is a distinct operation.

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

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

The description implies usage: you use it when you need page numbers on a PDF. However, it does not explicitly mention when to prefer this over alternatives like add_watermark, nor does it provide exclusions or conditions. Usage guidance is only implicit.

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?

It discloses the diagonal placement and configurable opacity/angle, which goes beyond the basic annotations. However, it does not state whether the original file is modified or whether a new output file is produced; with no output schema, that behavioral gap remains.

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 that front-loads the purpose and key controls without any filler. Every clause contributes useful information for tool selection.

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

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

Given the rich 100% schema coverage and clear purpose, the description is largely sufficient for an agent to call the tool correctly. It does not explain output/return behavior, but the schema already names output_filename and the overall intent is unambiguous.

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 parameters are already well documented. The description adds no meaning beyond mentioning opacity and angle, which aligns with the schema; baseline 3 is appropriate.

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

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

The description uses a specific verb ('stamp') and a clear resource ('text ... across PDF pages'), with concrete examples like 'CONFIDENTIAL' or 'DRAFT'. This clearly distinguishes it from sibling tools such as add_page_numbers or compress_pdf.

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

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

The description implies the tool is for adding text watermarks to PDFs, and the examples suggest common use cases. However, it does not explicitly state when to prefer this tool over alternatives or mention any exclusions, so usage guidance is only implied.

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 tool is not destructive and can be run multiple times. The description adds that it drops metadata and unused objects, which is useful context for users concerned about privacy or potential loss. It doesn't mention any side effects like quality trade-offs, but the annotations cover safety.

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

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

The description is a single sentence that is informative and front-loaded with the action and result. It avoids unnecessary details and gets straight to the point. However, it could be slightly more structured by separating the primary action from the side effects, but it's efficient.

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

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

For a moderately complex tool with 3 parameters and nested objects, the description covers the main behavior. The output schema is absent, but the description doesn't need to explain return values. It could mention potential limitations (e.g., no reduction for already-compressed PDFs) but overall it's sufficient for an agent 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 coverage is 100%, so parameters are fully explained in the schema. The description adds context beyond schemas by mentioning 'dropping metadata', which aligns with the 'strip_metadata' parameter, and 'keeping text sharp', which hints at quality control. This adds value without repeating schema details.

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

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

The description clearly states the verb 'Reduce' and the resource 'PDF file size' with a specific method (rebuilding compactly, dropping unused objects/metadata). It distinguishes itself from sibling tools like merge_pdfs or rotate_pdf by focusing on compression.

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

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

The description implies usage for reducing file size, and the tool fits within a suite of PDF manipulation tools. It doesn't explicitly state when not to use it (e.g., vs. repair_pdf) but the context is clear enough. No exclusions are mentioned, but the purpose is distinct.

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

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

Annotations already cover read-only, idempotent, and open-world behavior. The description adds valuable context beyond those hints: output is returned page by page, and the tool is ineffective on scanned or image-based PDFs. It does not state the exact failure mode for scanned pages, but it gives a clear limitation.

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, front-loaded sentences with no filler. Each clause contributes: the action, the output granularity, the use cases, and the critical scanned-PDF limitation.

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 full schema coverage and annotations that establish safety and idempotence, the description covers the key non-obvious constraint (text-based only) and hints at return shape via 'page by page'. An explicit return-format contract would improve completeness, but nothing essential is missing for invoking the tool correctly.

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

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

Schema description coverage is 100%, and the schema already explains the file object (url/base64/filename) and optional pages parameter. The description adds no parameter-specific detail, which is acceptable because the schema carries the semantic weight.

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

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

The description uses a specific verb ('Pull the text out') and resource ('a PDF'), and adds 'page by page' to convey granularity. It distinguishes itself from sibling PDF tools, none of which extract text content, and from get_pdf_info by focusing on text rather than metadata.

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 explicitly states when to use the tool (when PDF text needs to be read, summarised, or analysed) and when not to use it ('not on photos of pages'). It does not name a specific sibling alternative, but no sibling performs text extraction, so the guidance is sufficient.

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, and openWorldHint, so the safety profile is covered. The description adds useful context about which metadata fields are inspected, but 'without changing the file' largely restates the annotations rather than disclosing new behavioral traits such as error behavior or input limitations.

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

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

The description is a single, front-loaded sentence that packs the tool's purpose, scope, and non-mutating guarantee without wasted words. Every element 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 no output schema, the description appropriately lists the returned metadata fields, making the tool's observable result clear. Combined with the fully documented input schema and read-only annotations, an agent has enough information to select and invoke it, though error behavior for invalid or corrupt PDFs is not covered.

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 input schema already fully documents the file parameter and its url/base64/filename options. The description does not add parameter-specific meaning, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Read') with a specific resource ('a PDF') and enumerates the exact metadata returned: page count, title, author, page size, and password-protection status. The phrase 'without changing the file' clearly separates it from the mutating sibling tools like compress_pdf or rotate_pdf.

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

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

The description establishes a clear context: use it when you need metadata about a PDF without modifying it. It does not explicitly name alternatives or state when-not-to-use conditions, but the read-only framing and sibling tool names make the appropriate usage inferable.

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 indicate the tool is non-destructive, idempotent, and not read-only. The description adds meaningful behavioral context beyond that: it creates one page per image and preserves the given file order, which explains how the output PDF is structured. It does not mention details like return behavior or side effects beyond creating the PDF, but the annotation profile covers safety.

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

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

The description is a single, front-loaded sentence that covers the tool's main behavior, input format, output format, and ordering with no wasted words. Every phrase carries meaning and nothing is 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?

For a tool with five well-documented parameters, an output format stated in the description, and annotations covering idempotency and destructiveness, this description is sufficiently complete. It does not describe the return value, but since the tool produces a PDF and there is no output schema, the key call-time information is already covered by the schema and description.

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

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

Schema description coverage is 100%, so all five parameters are documented with their meanings and defaults. The description reinforces the 'files' ordering and the one-per-page layout but does not add substantial new parameter semantics beyond the schema, making the baseline of 3 appropriate.

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

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

The description states a specific verb and resource: converting JPG or PNG images into a single PDF, with the explicit behavior of one image per page in input order. This clearly distinguishes the tool from all listed siblings, which operate on existing PDFs rather than creating one from images.

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

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

The description clearly implies when to use this tool: when you have one or more JPG/PNG images and need a PDF. It also sets expectations about format support and ordering, giving an agent enough context to select it over PDF-only sibling tools, though it does not explicitly name alternatives or exclusion cases.

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 convey that this is a mutating (readOnlyHint=false) but non-destructive and idempotent operation. The description adds the behavior of preserving input order, which is useful but not extensive. No side effects, permissions, or limits are disclosed beyond what annotations provide.

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

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

The description is a single, concise sentence that captures the core functionality without any fluff. It is front-loaded with the action and result, making it immediately scannable and easy to parse.

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 straightforward merge tool with well-defined parameters and no output schema, the description covers the essential behavior. It does not mention edge cases like file size limits, but the schema handles constraints (minItems, maxItems, maxLength). Overall, the information is sufficient for an agent to use 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%, so both parameters (files and output_filename) are fully documented in the schema. The description's mention of order mirrors the schema's own statement about file order, adding no new meaning. Baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Combine' with resource 'PDFs' and specifies the output is a single PDF, while also emphasizing order preservation. It distinguishes from sibling operations like split, remove, or reorder, making its purpose unambiguous.

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

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

The description implies when to use it: whenever two or more PDFs need to be combined into one. It provides clear context but does not explicitly mention exclusions or alternatives. However, the tool's purpose is so specific that an agent would naturally select it for merging tasks.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful context about browser dependency and task limitations, but it does not clarify return behavior beyond 'Get a direct link' or describe any potential browser-interaction expectations.

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

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

Two sentences, both purposeful: the first states what the tool provides and lists representative uses, the second gives the usage condition. No filler or redundant restatement of the schema.

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

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

For a one-parameter, read-only, idempotent tool, the description covers the main invocation decision: when to use it and what it returns ('a direct link'). It is slightly ambiguous whether the tool actually opens the browser or returns a link for the user to open, but the overall guidance is sufficient.

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 single 'tool' parameter has a complete enum with its own description, so the schema carries the semantic weight. The description's capability list adds some context but does not materially explain how to choose among the enum values 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?

The description uses a specific verb ('Get a direct link') and names the exact resource (a PDFWix tool requiring the browser), followed by concrete capability examples such as password protection, signing, and redaction. It clearly distinguishes this tool from the automated sibling tools by emphasizing browser necessity.

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 explicitly says 'Use this when a task cannot be completed by the automated tools,' giving a clear applicability condition. It does not name specific alternatives or state when not to use it, but the reference to automated tools is sufficient given the sibling 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 carry idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds 'keep everything else' and a selection syntax example, but does not disclose output behavior or whether the original file is modified. No contradiction with annotations.

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

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

Two short sentences, front-loaded with the core operation and scope; the selection example earns its place and adds useful usage detail without waste.

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 3-param tool with no output schema, the description plus rich schema and annotations covers selection syntax, input file, and safety. It could mention that a new PDF is produced, but output_filename in the schema implies it; still complete enough for 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 coverage is 100% and the schema already documents pages with the same example '2, 5-7'. The description repeats that example without adding new semantics for file or output_filename, 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 ('Delete') and resource ('pages from a PDF'), and clarifies scope with 'keep everything else.' This clearly distinguishes it from siblings like reorder_pdf_pages or split_pdf.

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

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

The description implies use when unwanted pages should be removed, but it never names alternatives or exclusion conditions. With siblings like reorder_pdf_pages and split_pdf, explicit routing would help; as-is, guidance is only implicit.

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 provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that a complete new page order is required, which is useful. It doesn't detail failure modes or whether the original file is preserved, but annotations lower the burden.

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

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

The description is two sentences with the purpose front-loaded and a concrete example. Every clause contributes meaningful guidance without 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?

Given a nested file input, a required order parameter, and no output schema, this description is largely sufficient. It explains the operation, the complete-order requirement, and a clear invocation pattern. It doesn't describe the return value or invalid inputs, but the rich schema and idempotent annotation mitigate that 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 the baseline is 3. The description goes beyond the schema by emphasizing 'full page order' and giving an explicit example, which clarifies that the order must include all pages. File and output_filename semantics are already fully documented in the schema.

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

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

Description clearly identifies the operation ('Rebuild a PDF with its pages in a new order') with a specific verb/resource and a concrete use case. It doesn't explicitly name sibling tools to draw boundaries, so differentiation from rotated or removed pages is inferential rather than explicit.

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 example 'moving an appendix to the front' implies a common use case)Skip and 'Give the full page order' indicates what to supply. However, it doesn't explicitly state when to prefer alternatives or when not to use this tool, so usage guidance is mostly implied.

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

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

Annotations already cover idempotency and non-destructiveness, so the description's additional recovery semantics are valuable: pages are retained only if still parseable, and a clean output file is produced. This adds behavioral context beyond the structured annotations and does not contradict them.

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

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

The description is a single sentence with no filler, front-loading the key scope ('every page that can still be parsed') and the outcome ('writing a clean file'). Every phrase earns its place.

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

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

For a one-parameter repair tool with no output schema, the description states the input use case and the produced artifact. File-supply details are already covered by the schema, so nothing essential for 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?

The single file parameter is fully documented in the input schema, including url, base64, and filename with descriptions, giving 100% schema coverage. The description adds no parameter-specific detail, which is acceptable at the baseline.

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

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

The description uses the specific verb 'Rebuild' with the resource 'corrupt or unreadable PDF' and states the expected outcome: recovering parseable pages and writing a clean file. This clearly distinguishes repair_pdf from siblings like compress_pdf or split_pdf, which address different PDF operations.

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

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

The description gives clear usage context: use it when a PDF is corrupt or unreadable. It does not explicitly name sibling alternatives or state when not to use it, so it falls short of a 5 but is still effective.

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 signal non-read-only, non-destructive, non-idempotent behavior. The description adds 'permanently,' which clarifies that rotation is baked into the output rather than a transient view. This is still a bit ambiguous about whether the original file is replaced or a new file is produced, and it does not describe result delivery.

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 and degree options come first, and the useful context appears second. Every phrase earns its place.

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

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

The schema documents all parameters, and the description provides a clear use case. The main omission is an explicit note about the return value or whether the input file is replaced, but the output_filename parameter implies a resulting 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 description coverage is 100%, so the baseline is 3. The description mostly restates what the schema already says about angle (90, 180, 270 clockwise) and adds no extra meaning for file, pages, or output_filename.

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

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

The description uses a specific verb-resource pair ('rotate pages of a PDF') with exact degrees and direction. It is inherently distinguishable from siblings like reorder_pdf_pages, remove_pages, and split_pdf.

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

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

The description gives a clear use case: 'sideways or upside-down scans.' It does not explicitly name alternatives or say when not to use the tool, so it stops short of full routing guidance.

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

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

Annotations already provide destructiveHint=false and idempotentHint=true, and the description adds useful context about preserving order and the accepted selection syntax. However, the phrase 'out of a PDF' is ambiguous about whether the original file is modified, and the description does not explicitly say the source remains unchanged.

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 concise sentences with no wasted words. The main action is front-loaded, and the second sentence provides a concrete, useful selection example without elaboration.

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

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

Given the simple operation and thorough schema, the description is nearly complete for invoking the tool correctly. It clearly states the output is a new PDF and gives a practical selection example, though it could additionally clarify original-file behavior and differentiate from remove_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 description coverage is 100%, so the schema already documents file, pages, and output_filename in detail. The description contributes only the page-selection example, which mostly mirrors the schema's pages parameter description, adding little new semantic value.

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

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

The description uses a specific verb and resource: 'Pull selected pages out of a PDF into a new PDF.' It also clarifies that page order is preserved, which distinguishes it from reordering tools. The purpose is immediately clear and not a tautology.

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

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

The description implies when to use the tool: when a subset of pages needs to be extracted into a new PDF. However, it does not explicitly contrast this with sibling tools like remove_pages or reorder_pdf_pages, nor does it state when not to use it.

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

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

Annotations already mark the tool as non-read-only, idempotent, and non-destructive. The description adds valuable context beyond that: the password is used once and never stored, and the result is an unrestricted copy rather than an in-place modification.

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

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

Two compact sentences with the main action and condition front-loaded. The security note is expressed in a single short clause, and there is no filler or redundant restating of the schema.

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

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

For a simple unlock operation, the description, fully documented schema, and annotations cover the essential usage. It doesn't detail error behavior or return format, but the 'unrestricted copy' phrasing and absence of an output schema keep this acceptable.

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

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

Schema description coverage is 100%, so the schema already documents file, password, and output_filename thoroughly. The description doesn't add parameter-level detail, but it doesn't need to; baseline 3 is appropriate.

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

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

The description uses a specific verb ('Remove') and resource ('a PDF'), and adds the crucial condition 'you know the password for' plus the outcome 'unrestricted copy.' This clearly distinguishes it from sibling PDF tools like repair_pdf or compress_pdf.

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

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

It clearly implies when to use it: when you have the password and want an unrestricted PDF copy. It doesn't explicitly name alternatives or exclusion cases, but the condition is concrete enough for an agent to select it correctly.

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