stagenth · PDF 工具箱

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

The description mentions cost (1 credit/time) and automatic refund on failure, which are useful behavioral traits. However, with no annotations, it fails to disclose other important aspects like auth requirements or whether the tool is purely additive (non-destructive).

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 extremely concise (two sentences) with no fluff. It front-loads the main action and includes critical cost/refund info efficiently.

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?

Despite having 4 parameters and no output schema, the description omits important context like how the converted file is returned (e.g., new file ID) and how file_id is obtained. This leaves gaps for the agent.

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?

All parameters are fully described in the input schema (100% coverage). The description does not add additional meaning beyond what schema provides, meeting baseline but not exceeding.

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 tool performs image format conversion and compression (specific verb+resource). It is distinct from sibling tools like img_to_pdf and various PDF tools, though it does not explicitly differentiate.

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 mention of prerequisites, context, or 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?

No annotations provided, so description carries full burden. It discloses non-obvious behavior: cost (1 credit/use) and automatic refund on failure. Lacks details on output or side effects but sufficient for a simple tool.

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?

Single sentence with all essential information: purpose, ordering, cost, refund. 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?

Tool is simple (2 params, no output schema). Description covers purpose, cost, failure handling. No return value explanation needed. Sufficient for typical use.

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%, with parameter descriptions matching the description nearly verbatim. Description adds no additional meaning 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?

Description clearly states it combines images into a PDF (one per page, in order) and includes cost and refund policy. Distinguishes from siblings like img_convert and pdf_merge.

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?

Implied usage: when needing to convert images to PDF. No explicit 'when not to use' or comparison to alternatives, but the purpose is clear enough for an AI agent.

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

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

With no annotations provided, the description discloses important behavioral details: credit consumption (1 credit/time) and automatic refund on failure. This goes beyond a simple 'compress' statement, though it omits details like processing time or file size limits.

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

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

The description is a single, front-loaded sentence that conveys the core action, methods, and cost/refund policy efficiently. No extraneous 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?

Given the tool's simplicity, the description covers the core functionality, cost, and failure handling. However, it lacks details about the output (e.g., return value or success indicator) since no output schema is provided.

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% with both parameters described. The tool description does not add additional meaning beyond the schema's parameter descriptions, so a 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 clearly states the tool compresses PDF volume by cleaning redundancy and re-compressing streams, images, and fonts. It distinguishes itself from sibling tools like pdf_merge, pdf_split, etc., which perform different 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 mentions the credit cost and automatic refund on failure, implying usage conditions, but does not explicitly state when to use or not use this tool compared to alternatives. It relies on inferred context from sibling tool names.

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

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

The description discloses key behaviors: it is a mutation tool that removes the password, costs 1 credit per use, and gives a refund on error (wrong password). This goes beyond typical transparency.

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 efficiently conveys the purpose, output, cost, and error handling without extraneous 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 decryption tool with full schema coverage and no output schema, the description covers the essential aspects: function, cost, and error 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 100%, so the baseline is 3. The description adds no extra meaning beyond what is in the schema parameter descriptions.

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 specific action: decrypt a PDF with a known password and output a password-free version. It also mentions the credit cost and error handling, distinguishing it from sibling tools like pdf_encrypt.

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 should be used when a known password is available, but it does not explicitly state when to use it versus alternatives (e.g., encrypt) or mention prerequisites like the file must be encrypted.

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?

Description discloses encryption standard (AES-256), credit cost, and automatic refund on failure, which are beyond schema. However, it lacks details on file size limits, permission requirements, or error 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?

Description is extremely concise with one sentence covering action, security, cost, and refund. No unnecessary words, front-loads key 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?

Given the simple nature of the tool and 100% schema coverage, the description is adequate. It covers purpose, encryption, cost, and refund. Could mention output or success criteria but not critical.

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

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

Schema description coverage is 100% with basic descriptions for each parameter. The tool description adds no additional meaning beyond what the schema already provides.

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

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

Description explicitly states the tool sets an open password for PDFs, specifies AES-256 encryption, and mentions cost and refund policy. It clearly distinguishes from siblings like pdf_decrypt and other PDF tools.

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

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

No guidance on when to use this tool versus alternatives like pdf_decrypt or when not to use it. No context about prerequisites or limitations.

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

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

With no annotations provided, the description adds value by disclosing cost (1 credit) and automatic refund on failure. However, it does not state whether the original file is modified or a new file is created (though the optional filename parameter implies a new file). Side effects and behavioral details are limited.

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 extremely concise: one main sentence stating the core function plus a second sentence about refund. It is front-loaded and wastes no 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?

Given the simple tool with 4 parameters and no output schema, the description covers the key action, cost, and failure handling. It could mention that the output is a new PDF file (implied by optional filename), but overall it is sufficiently complete for an agent to understand the tool's purpose.

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?

All parameters are described in the schema (100% coverage). The description reinforces the purpose (e.g., 'semi-transparent' relates to opacity) but does not add new details beyond the schema. 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 action (placing an image watermark), its placement (centered on each page), transparency (semi-transparent), and cost/refund policy. It naturally differentiates from the sibling 'pdf_watermark' by specifying 'image' in both name and description.

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 explicit when-to-use or when-not-to-use is given, but the tool name and sibling list imply it is for image watermarks versus the text-focused 'pdf_watermark'. Prerequisites like the image file ID being already uploaded are assumed from the schema 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?

No annotations are provided, so the description carries the burden. It discloses that the operation is local and costs 1 credit, with automatic refund on failure. However, it does not mention other behavioral aspects like whether the original files are modified, the output location, or any side effects.

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 very concise, consisting of two short sentences that are front-loaded. Every part is essential and there is no redundant 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?

The description explains the basic operation but lacks details about the output (e.g., where the merged file is saved, format, naming). With no output schema, the description should provide more context about the result of the action, but it is adequate for a simple merge tool.

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

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

Schema description coverage is 100%, and the parameter descriptions in the schema are already informative (file_ids as list of IDs, filename as optional). The tool description adds no additional parameter-specific meaning beyond the schema, so a 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 clearly states it merges multiple PDFs in order into one file, with a specific verb 'merge' and resource 'PDFs'. It distinguishes from sibling tools like pdf_split, pdf_compress, etc., which perform 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 implies when to use: when needing to combine PDFs sequentially. It does not explicitly state when not to use or mention alternatives, but the purpose is clear enough for an AI agent given the sibling tool names.

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

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

The description discloses pricing (1 credit) and failure behavior (auto-refund), and notes language support. However, it does not clarify if the original file is modified or a new file is created, nor other behavioral aspects like idempotency or side effects.

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: first sentence captures core functionality, second adds pricing and failure policy. Extremely concise and front-loaded with key 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?

Given the tool's simplicity and full schema coverage, the description provides sufficient context for a basic understanding. It omits minor details like output file handling but is largely complete for a straightforward addition tool.

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

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

Schema coverage is 100%, so the schema already explains all parameters. The description adds no additional parameter semantics beyond summarizing the optional elements (prefix, suffix, header).

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 tool adds page numbers to each page of a PDF, with optional prefix/suffix and header. The verb 'add' and resource 'PDF' are specific, and it distinguishes from sibling tools like pdf_merge or pdf_convert by focusing on numbering.

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 mentions cost and refund policy but does not provide explicit guidance on when to use this tool versus alternatives, such as when to avoid it or prerequisites.

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?

No annotations are provided. The description partially compensates by disclosing the credit cost ('1 credit/次') and the automatic refund policy ('失败自动退款'). However, it does not mention that deleting pages is destructive or irreversible, nor does it cover authentication or rate limits. Thus, it adds some behavioral context but leaves gaps.

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 extremely concise, consisting of a single sentence that front-loads the purpose and key constraints. Every element ('整理 PDF 页面', '旋转指定页/删除指定页', '1 credit/次', '至少给一个操作', '失败自动退款') is necessary and informative, with no redundant 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?

Given the tool's relative simplicity and the absence of an output schema, the description covers the core functionality (rotate/delete), usage constraints (at least one operation), cost, and failure handling. It could be more complete by mentioning what the output is (e.g., a new file_id), but the schema's parameter descriptions help fill some 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 the schema already documents each parameter. The description adds value beyond the schema by clarifying the requirement that at least one operation (rotate or delete) must be specified, and by noting the credit cost and refund policy. This helps the agent understand the usage constraints.

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 tool's purpose: organizing PDF pages by rotating or deleting them. It uses specific verbs ('旋转' and '删除') and specifies the resource ('PDF 页面'). This distinguishes it from sibling tools like pdf_merge, pdf_split, etc., which handle other 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 implies usage context by stating '至少给一个操作' (at least one operation), indicating that users must provide either rotate or delete parameters. However, it does not explicitly specify when to use this tool versus alternatives, nor does it mention when not to use it. The context is implied through the sibling tool names.

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?

No annotations provided; description adds cost and auto-refund info but does not disclose other behaviors like file modification (original unchanged) or limits.

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

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

Single sentence with two clauses, no wasted words, purpose front-loaded.

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

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

Given the simple tool (3 params, no output schema), the description covers purpose, cost, and failure handling; could mention that original file remains unchanged, but overall 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 100% so baseline is 3; description adds credit cost but no parameter-specific context beyond what schema already provides.

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

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

The description clearly states the action (抽取指定页另存为新 PDF) and resource (PDF pages), and implicitly distinguishes from sibling tools like pdf_merge or pdf_compress.

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 (extracting pages) but gives no explicit guidance on when not to use or alternatives among sibling tools.

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

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

With no annotations, the description carries the full burden. It mentions pricing and automatic refund on failure, which are behavioral traits. However, it does not disclose any destructive actions, required permissions, or side effects beyond the refund policy.

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 extremely concise—a single sentence and a short additional note. It is front-loaded with the primary action, with 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?

The description mentions the output is a ZIP file, but it does not explain the return value format, error cases beyond refund, or how to handle large PDFs. With 4 parameters and no output schema, more context could be helpful but is not severely lacking.

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?

All four parameters are described in the input schema (100% coverage), so the description adds no additional meaning beyond what the schema already provides. The baseline score of 3 applies.

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

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

The description clearly states the tool's action: 'Render each page of PDF into images and package into ZIP'. It also provides additional context like pricing and refund policy, making the purpose unmistakable.

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 is given on when to use this tool versus alternatives like 'img_to_pdf' or 'pdf_image_watermark'. The description does not mention prerequisites, exclusions, or conditions for use.

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

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

With no annotations, the description discloses key behaviors: adds watermark to every page, centered at 45°, semi-transparent, costs 1 credit, and auto-refund on failure. Missing details on output format or file mutation, but sufficient for basic understanding.

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?

Single sentence includes all critical information: action, style, cost, and failure handling. No redundant words, front-loaded with core functionality.

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 no output schema and moderate complexity, the description covers the tool's primary purpose and key details. Could mention that original file is not modified or what the output is, but overall sufficient for agent 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 descriptions cover 100% of parameters. Tool description reinforces text and file_id roles but doesn't add new semantic details beyond the schema. Baseline 3 is appropriate as schema already adequately explains 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?

Description clearly states the tool adds a centered, 45°, semi-transparent text watermark to every page of a PDF, and mentions cost and refund policy. It effectively distinguishes from image watermark sibling by specifying 'text watermark'.

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 explicit guidance on when to use this tool vs alternatives like pdf_image_watermark. While the description implies it's for text watermarks, it lacks context for when to prefer it over other PDF manipulation tools.

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