pdf4me-mcp

Official

by pdf4me

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation2/5
Many tools have overlapping purposes, especially the 14+ process_* AI extraction tools and the multiple split_pdf_by_* tools. For example, split_pdf_by_barcode and split_pdf_by_swiss_qr both split by barcode, and process_invoice vs process_receipt may be ambiguous for similar document types. Descriptions are detailed, but the sheer volume of similar tools makes misselection likely.
Naming Consistency4/5
Tool names generally follow a consistent verb_noun pattern (add_*, convert_*, extract_*, process_*). Minor inconsistencies exist, such as merge_multiple_pdfs vs merge_pdf_overlay, and generate_document_single vs generate_documents_multiple, but overall naming is readable and predictable.
Tool Count1/5
With 92 tools, the server is extremely overloaded. The typical well-scoped server has 3-15 tools; 92 is far beyond any reasonable threshold and will overwhelm agents. This extreme count likely leads to context bloat and decision paralysis.
Completeness4/5
The tool set covers a comprehensive range of PDF, image, conversion, and AI extraction operations, including create, read, update, delete, transform, and metadata operations. Minor gaps exist (e.g., no page reordering, no generic text editing beyond find-and-replace), but the coverage is broad and most common workflows are supported.
Average 3.8/5 across 92 of 92 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description carries the full burden. It only mentions the API endpoint and parameter mappings, without disclosing actual behavior such as whether the original PDF is modified, what output files are produced, or how errors are handled. This is a significant gap for a splitting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single run-on sentence that mixes API endpoint details, parameter lists, and mapping notes, making it hard to parse. It is compact but poorly structured, lacking clear separation between purpose, parameters, and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no output schema, and no annotations, this description is inadequate. It lacks critical context about the output (e.g., split PDFs are written to output_dir), behavioral semantics, and parameter meanings, making it impossible for an agent to invoke the tool correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only lists parameter names and a few defaults. It does not explain the meaning of barcode_filter, barcode_type, or split_qr_page beyond enum values, and it omits output_dir and request_doc_name entirely. This is insufficient for an agent to set parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Split a PDF by Swiss QR' with a specific verb and resource, distinguishing it from generic split_pdf or split_pdf_by_text tools. However, it does not explicitly contrast with the sibling split_pdf_by_barcode, so it misses the full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The 'Swiss QR' qualifier implies a use case, but there are no explicit context indicators, exclusions, or alternative tool references, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It mentions 'via PDF4me /api/v2/Merge' hinting at an API call, but doesn't state whether it modifies inputs, requires network access, or creates output files and in what way. No details on permissions, overwriting behavior, or reversibility are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main action. It includes the input list and output path, but the API endpoint is extraneous for an agent. Overall, it is concise and easy to parse, earning a high score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema or annotations, so the description must explain return values and behavior. It does not mention what the tool returns, how output_dir and output_file_name interact, or any error conditions. Given the relative simplicity of a merge operation, the description is still incomplete for an agent to use it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions pdf_file_paths and request_doc_name, but 'output path' is ambiguous against the schema's separate output_dir and output_file_name parameters. It doesn't explain the purpose of request_doc_name or clarify the output parameter relationship, leaving the agent to rely on schema names alone. With 0% schema coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Merge multiple PDF files into one', providing a specific verb and resource. It is distinct from siblings like merge_pdf_overlay, though it doesn't explicitly differentiate from that overlapping tool. The mention of 'via PDF4me /api/v2/Merge' adds technical detail but doesn't obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 merge_pdf_overlay or split_pdf. The description only states the action without context or exclusion criteria, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does mention 'Saves cleaned PDF to disk,' which indicates a side effect, but it does not clarify whether the original file is overwritten or a new file is created, nor does it mention permissions, rate limits, or other operational considerations. For a delete-like tool, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and 22 words, front-loaded with the primary action. It is concise and every sentence contributes useful information (what it does, parameter hints, and output behavior). No wasted words, though it could be improved by adding a structured list of parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no output schema, the description is incomplete. It fails to explain the output_dir, output_file_name, and request_doc_name parameters, and does not specify return values or behaviors like file naming, overwriting, or error handling. The description covers only the core purpose but leaves significant gaps for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description must explain the parameters. It covers two of five parameters: pdf_file_path (the source PDF) and delete_page_option (with its enum values). However, it completely omits output_dir, output_file_name, and request_doc_name, leaving three parameters unexplained. This partial compensation is insufficient given the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete blank pages from a PDF') with a specific verb and resource, and importantly distinguishes this from sibling tools like delete_pdf_pages (which deletes specific pages, not blank ones). It also provides the API endpoint and relevant parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what parameters to provide (pdf_file_path and delete_page_option) but gives no explicit guidance on when to use this tool versus alternatives. With sibling tools like delete_pdf_pages, it would be helpful to mention 'use this for blank-page removal, not for deleting specific pages.' The usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states 'Find and replace text' but does not clarify whether it operates on the original file or creates a new one, whether it replaces all occurrences or only the first, or how the 'page_sequence' parameter affects the operation. The mention of an 'optional output path' hints at a new output file, but this is not explicit. Significant behavioral gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary function. The API endpoint reference ('via PDF4me /api/v2/FindAndReplace') is extra detail that could be omitted, but overall the text is efficient and avoids excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no annotations, no output schema, and a complex sibling set, the description is insufficient. It fails to explain return values, side effects, or all parameter meanings. A user would likely need external documentation to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names only four parameters (pdf_file_path, old_text, new_text, page_sequence) and vaguely references 'optional output path', omitting output_dir, output_file_name, and request_doc_name. It does not explain the format or meaning of page_sequence (e.g., comma-separated pages). The provided parameter list adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find and replace text in a PDF'. It uses a specific verb ('replace') and resource ('text in a PDF'), which distinguishes it from sibling tools like 'replace_text_with_image' (replacing text with images) and 'add_text_stamp_to_pdf' (adding text stamps). The inclusion of the API endpoint and key inputs reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. It does not mention exclusions or conditions, such as 'use this for text-to-text replacement; for replacing text with images, use replace_text_with_image instead'. The description merely lists inputs without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It fails to mention output behavior, file creation, authorization, or side effects. It only states the operation and parameter mapping, which is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler, immediately states purpose and then enumerates the action-specific parameters. Efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema and 8 parameters, this description is too sparse. It omits what the tool returns, how output files are named, and any prerequisites, and it ignores sibling tool differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage). The description explains that split_action_number is needed for the first two actions, split_sequence for SplitSequence, and split_ranges for SplitRanges, adding essential semantics. However, it leaves output_dir, file_naming, and request_doc_name entirely undefined, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Split a PDF via PDF4me SplitPDF' and enumerates the specific split modes, establishing it as a PDF splitting tool. It does not explicitly distinguish it from sibling tools like split_pdf_by_text or split_pdf_by_barcode, but the API reference adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to choose this tool over alternatives such as split_pdf_by_text or extract_pages_from_pdf. It does give clear instructions for parameter selection based on split_action, but that is operational rather than contextual.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only lists parameters and the API endpoint, but does not explain output behavior, file handling, permissions, or side effects. The operation is implied but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that mixes API endpoint with a parameter list. It is not well-structured and reads as a run-on, but it is reasonably concise and front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters, no output schema, no annotations), the description is insufficient. It lacks usage context, expected output, error handling, and relationship to sibling tools. It covers purpose and some parameter info but is not complete enough for an agent to invoke the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It lists the key parameter names and groups required vs optional (e.g., 'optional font size, colour, bold, opacity, rotation, position_x/y'). This adds some meaning beyond the schema, but it largely repeats parameter names without explaining formats, constraints, or default behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a text watermark to an image', with a specific verb and resource. It also names the API endpoint and distinguishes from sibling tools like 'add_image_watermark_to_image' (text vs image watermark).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as 'add_image_watermark_to_image' or 'add_text_stamp_to_pdf'. The description does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a concrete side effect: 'Saves classified_document.json' and references an external PDF4me API. However, it doesn't mention authentication, whether the input PDF is modified, or error behavior. Since no annotations exist, this limited transparency leaves gaps for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action, then lists parameters and the output file. Every phrase carries information, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, annotations, or parameter descriptions. The description provides minimal context, omitting details on classification result structure, use cases, and behavioral constraints, making it incomplete for an agent to fully understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description merely repeats parameter names from the schema ('pdf_file_path; optional request_doc_name and output_dir') without explaining their meaning or usage. With 0% schema description coverage, this is insufficient to guide correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Classify a PDF by content') and references a specific API endpoint. It distinguishes from siblings like process_invoice or parse_document by indicating generic classification, but doesn't elaborate on what classification outputs are produced.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as parse_document or process_*. It lacks use cases, prerequisites, or exclusions, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It names several parameters but does not explain how splitting behaves (e.g., page placement rules, multiple barcodes, output handling). The tool likely creates new PDFs, but this is not disclosed, and there is no information about side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary purpose and lists relevant parameters. It is efficient and free of fluff, though the parameter list could be better structured (e.g., grouping or formatting) to enhance readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, no annotations, and no output schema, so the description must provide substantial context. It fails to explain how the parameters interact, what output to expect, or any prerequisites. The description is a bare minimum that does not enable confident tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only lists some parameter names (barcode_string, barcode_filter, etc.) without explaining their meanings, relationships, or required values. Required parameters like pdf_file_path and output_dir are not even mentioned, leaving the agent without the necessary semantics to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool splits a PDF by barcode text, naming the specific API endpoint. This distinguishes it from sibling tools like split_pdf (generic split) and split_pdf_by_text (splits by text), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating the barcode-based splitting functionality, but it does not explicitly provide when-to-use guidance or compare with alternatives. No exclusions or alternative tool references are given, so 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the API endpoint and async mode, but fails to state side effects (e.g., whether inputs are modified), permissions required, return format, or error behavior. These are significant gaps for a tool that creates a new PDF.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that deliver the core operation and key inputs. However, the second sentence is a compressed list that includes the unclarified 'async mode', which slightly impairs clarity. Overall, it is efficient with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the medium complexity (5 parameters, no output schema, no annotations), the description is incomplete. It fails to explain the output of the operation, the meaning of the output parameters, or the implications of async mode. It would benefit from clarifying the result and differences from sibling merge tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It names base_pdf_file_path and overlay_pdf_file_path, but only vaguely refers to 'optional output naming' without distinguishing output_dir, output_doc_name, or output_file_name. Additionally, it mentions 'async mode' which is not present in the schema, creating ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Overlay') and resource ('one PDF over another'), which differentiates it from similar tools like merge_multiple_pdfs. It also names the underlying API endpoint, including the specific operation path, adding precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for overlaying PDFs, but it does not explicitly state when to use this tool versus alternatives, nor does it provide prerequisites or exclusions. The context is clear but lacks direct guidance on choosing this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It lists parameters to provide but does not explain what happens when the text is not found, how output files are named, whether the original PDF is modified, or any error behavior. The only behavioral hint is 'split_text_page (before/after)', which indicates placement relative to the matched text, but this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, readable sentence that quickly conveys the tool's purpose and key parameters. The inclusion of the API path is slightly extraneous for an agent, but it is not verbose or confusing. No unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, no annotations, and no output schema, the description is incomplete. It does not explain return values, output file behavior, error handling, or prerequisites (e.g., whether the PDF must contain searchable text). It also does not differentiate from sibling split tools, making it difficult for an agent to fully understand the tool's context and consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions four of six parameters (pdf_file_path, text, split_text_page, file_naming) and clarifies split_text_page values. However, it omits output_dir and request_doc_name, which are significant – especially output_dir, which determines where the split files are written. The description adds only marginal meaning beyond the schema's parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Split a PDF by matching text' – a specific verb + resource + method. It also references the underlying API endpoint, and the phrase 'by matching text' distinguishes it from sibling tools like split_pdf or split_pdf_by_barcode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrase 'by matching text', suggesting this tool is for splitting at text occurrences rather than page numbers or barcodes. However, it does not explicitly state when to use this tool over alternatives or provide any exclusion criteria, such as 'use split_pdf for page ranges instead'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. While it mentions optional behaviors like opacity, is_background, and show_only_in_print, it does not clarify whether the original PDF is modified or how the output path is used. This is a significant gap for a tool that modifies files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently packs essential information—purpose, required parameters, and optional categories. It is front-loaded with the primary action and remains concise despite covering many parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 parameters, no output schema, no annotations), the description is incomplete. It does not explain the output format or file handling, and it omits several parameters. The description provides a useful overview but is not sufficient for safe and accurate invocation without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains the purpose of key parameters (pdf_file_path, image_file_path, alignX, alignY) and summarizes optional groups (size, margins, opacity, etc.), but it omits several parameters (image_name, output_file_name, request_doc_name) and uses camelCase names that differ from the schema's snake_case, potentially causing confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Stamp or watermark a PDF with an image' and specifies the API endpoint. It is distinct from sibling tools like add_text_stamp_to_pdf and add_image_watermark_to_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by listing required inputs and optional parameters, but it does not explicitly state alternatives or when not to use it. The context is present but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only mentions that the API response is saved as JSON, but does not state required permissions, side effects of subscribing, reversibility, or behavior on failure. This is insufficient for a tool that performs a side-effectful operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource. Every word earns its place, with no redundant or vague filler. It is concise and well-structured for a tool of this simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description covers only a subset of parameters and does not explain the webhook subscription flow or the output file behavior. It is incomplete for an agent to correctly invoke the tool, missing critical details about output_dir and output_file_name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names only two required parameters (callback_url and doc_name) without explaining their meanings, and ignores output_dir and output_file_name entirely. This leaves 4 parameters largely undocumented, failing to provide necessary semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: subscribing a callback webhook via PDF4me WebhookSubscribe. It uses a specific verb ('Subscribe') and resource ('callback webhook'), and this is distinct from sibling tools that handle PDF operations, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: it tells the user to provide callback_url and doc_name. While it doesn't explicitly mention alternatives or when-not-to-use, the webhook subscription context is unique compared to sibling tools, so the usage is implicitly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal that the tool saves parsed_document.json to output_dir and mentions auto-generation of parse_id and doc_name fallback. However, it does not state safety traits (e.g., read-only, no modification of input) or error/edge-case behavior, which would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences, and front-loads the core action. The second sentence packs a lot of parameter details, but remains readable. It avoids unnecessary fluff, though the parameter listing could be better formatted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description covers the main inputs and output location, but omits details like default behavior for output_dir, error scenarios, and the structure of the parsed document. The parameter name mismatch further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description attempts to explain parameter semantics (e.g., doc_name fallback, template_id vs template_name, auto-generated parse_id) but contains a critical mismatch: it refers to 'doc_name' while the actual schema parameter is 'request_doc_name'. This could mislead the agent. Schema coverage is 0%, so the description must compensate, but the inaccuracy undermines its utility.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Parse a PDF with a PDF4me parse template' via a specific API endpoint. It identifies the resource (PDF) and distinguishes it from sibling tools like extract_text_from_pdf or process_* by mentioning the template-based parsing mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists required parameters but does not explain when to use this tool over alternatives such as extract_text_from_pdf or the process_* tools. There is no mention of exclusions or alternative tool references, leaving the agent without clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must disclose behavioral traits itself. It does mention async 202 polling and that the rotated image is saved to disk, which are useful. However, it omits whether the source file is modified, overwrite behavior, and authentication or rate-limit requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the core action and API, followed by a concise list of supported features and output behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 6-parameter tool with no annotations or output schema, the description covers the purpose, the async behavior, and the disk-saving behavior. However, it is incomplete because it does not mention the return value, error handling, or any prerequisites such as file format support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with descriptions for file_path, rotation_angle, background_color, and proportionate_resize. The description adds some context by noting 'optional output directory and file name' for the undocumented output_dir and output_file_name parameters, but it does not provide deeper parameter-level semantics beyond what the schema already includes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly gives the specific action 'Rotate a local image' using the PDF4me RotateImage API, which identifies the verb and resource unambiguously. However, it does not explicitly distinguish this from sibling tools like rotate_image_by_exif_data, so it rates a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as rotate_image_by_exif_data, resize_image, or flip_image. The only usage signal is the phrase 'Rotate a local image,' which implies the purpose but gives no exclusion criteria or alternative pointers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing side effects and return behavior. It mentions optional output directory/file name and sync/async processing, but does not specify whether the source file is modified, what the function returns (e.g., a file path or a boolean), or any network/API side effects. This lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loads the primary action ('Convert a local Visio file'). It packs key options into a compact list without unnecessary words, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and no annotations, the description is insufficient for an agent to fully understand invocation behavior. It does not describe the return value (e.g., what the PDF output is or how it is delivered), error conditions, or the effect of omitting output_dir/output_file_name. The schema covers parameter semantics but not the runtime contextual details expected from a conversion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the baseline is 3. The description summarizes parameter groups (compliance, page range, hidden pages, foreground/toolbar, auto-fit) which maps to actual parameters, but does not provide additional meaning beyond the schema's own descriptions. It does not elaborate on page range calculation or default behavior in a way that exceeds the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: convert a local Visio file (.vsdx/.vsd/.vsdm) to PDF using the PDF4me ConvertVisio API. It distinguishes itself from siblings like convert_to_pdf by specifying the exact file types handled, leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Visio files via the extension list, but does not explicitly state when to prefer this over generic alternatives like convert_to_pdf. No exclusions or alternative scenarios are mentioned, so an agent may need to infer when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions optional async polling, but does not explain what this entails, whether the original DOCX is modified, what happens to the output, or any failure modes. The description lacks key side-effect and safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and every sentence adds meaningful information. There is no wasted wording or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is insufficient for an agent to fully understand the tool's behavior. It lacks explanation of async polling, the lifecycle of the input/output files, and any example or error handling. The tool interacts with local files and an external API, so more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only file_path has a description). The description mentions 'file path' and 'output directory/file name', which partially covers the parameters. However, it introduces 'async polling' which is not a schema parameter, and gives no format or behavior details for output_dir/output_file_name. It compensates somewhat but not fully for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: converting a local Word document (DOCX) to a PDF form with fillable fields. This distinguishes it from sibling tools like convert_to_pdf or convert_pdf_to_word by specifying the fillable-form output. The verb 'Convert' and resource 'Word document' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 you need a PDF form with fillable fields) and provides a prerequisite (file path). However, it does not explicitly mention alternatives or when not to use it, such as when a plain PDF conversion would suffice instead. No exclusionary guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states 'Remove pages' but does not clarify whether the original file is modified or a new file is created, nor does it mention error behavior or permission requirements. Given output_dir/output_file_name, it implies a new output, but the destructive implications are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence covering action, API, and the four parameters without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is not fully complete: it omits the outcome of the operation (e.g., whether a new PDF is created, original preserved), and with no output schema or annotations, the agent cannot anticipate the tool's side effects or return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by giving an example format for page_numbers and naming output_dir and output_file_name, which have no schema descriptions. However, it does not explain the default behavior when these optional parameters are omitted, and file_path is already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Remove pages from a PDF', clearly stating the action on the resource. It differentiates from sibling tools like delete_blank_pages_from_pdf and extract_pages_from_pdf by specifying arbitrary page ranges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete examples of pageNumbers format ('2', '1,3,5', '2-4'), which guides invocation. However, it does not explicitly state when to prefer this tool over alternatives such as extract_pages_from_pdf or delete_blank_pages_from_pdf.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits such as side effects and output. It states inputs (file path, form data, optional output parameters) but does not clarify whether the original file is modified or a new file is created, nor how output_dir and output_file_name are used. This leaves significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the main action. The phrase 'using the PDF4me FillPdfForm API' is unnecessary implementation detail, but the overall structure is concise and to the point, with no significant wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema, the description provides the core inputs but omits output behavior, return value, and error handling. An agent would not know how to retrieve the resulting filled PDF or handle failures, which is a clear gap. It is adequate for a simple fill operation but incomplete for autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 50% coverage, with file_path and form_data described, but output_dir and output_file_name lack schema descriptions. The description repeats the first two and mentions 'optionally specify output directory and output file name', but does not explain their exact semantics (e.g., where the filled PDF is saved). It partially compensates for the gap but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fill form fields' and identifies the resource as a 'local PDF', which clearly differentiates it from sibling tools like add_form_fields_to_pdf (which likely creates fields) and extract_form_data_from_pdf. It explicitly states what the tool does, making intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for populating existing PDF form fields, but it does not provide explicit when-to-use guidance or mention alternatives. There is no exclusion of cases like PDFs without form fields or interaction with add_form_fields_to_pdf, leaving the agent to infer context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It mentions the PDF4me API but does not disclose whether the original file is modified, if a new file is created, or what the return value looks like. It gives input instructions but not behavioral outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the purpose, and includes essential examples without fluff. Every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema or annotations, the description should explain what the tool returns or changes. It omits the output file behavior, error handling, and prerequisites. The existence of sibling 'rotate_pdf' also demands more explicit differentiation, which is not provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by listing all five parameters, giving concrete examples for the page spec ('1', '1,3,5', '2-4'), and clarifying that output directory and file name are optional. This compensates for the two schema parameters lacking descriptions. The phrasing 'provide rotationType' slightly overstates its requiredness, but the schema default mitigates this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Rotate', the resource 'selected pages of a PDF', and scopes it to specific pages. It distinguishes from sibling 'rotate_pdf' by emphasizing 'selected pages' rather than the whole document, and names the underlying API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case through 'selected pages' but does not explicitly state when to use this tool versus alternatives like 'rotate_pdf' or 'rotate_image'. There is no exclusion or alternative mention, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the API endpoint and the side effect of saving extracted text and JSON metadata to disk, but it omits important traits like authentication requirements, rate limits, whether the source file is modified, and the exact structure of the returned response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and then listing key options and the side effect. There is no redundant or filler content—every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, no output schema, and nine parameters, this description is too sparse. It does not cover return values, file naming conventions, error handling, supported Word formats, or how the filtering options interact with each other. The disk-save behavior is mentioned, but the overall context for a complex tool is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It mentions page range and content filtering options (comments, header/footer, tracked changes) which map to some parameters, but it does not explain output_dir, output_file_name, request_doc_name, or the precise behavior of accept_changes and page numbering. This is insufficient for a nine-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Extract text'), the resource ('a Word document'), and the specific API endpoint. It distinguishes itself from siblings like extract_text_from_image and extract_table_from_pdf by focusing on Word documents and mentioning page range and content filtering options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Word documents and mentions filtering options, but it does not explicitly state when to use this tool over alternatives such as extract_text_by_expression or convert_word_to_pdf_form. There is no mention of exclusions or alternative tools for PDFs or other formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains the core transformation (content becomes static), which is valuable. However, it does not disclose whether the original file is modified, what the output defaults are (e.g., where the flattened file is written if no output_dir is given), or any potential side effects like loss of editability. This partial transparency is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, consisting of two sentences that front-load the purpose and then provide parameter instructions. Every sentence earns its place, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what the tool returns or how the result is indicated. It does not mention return values, error conditions, or the fate of the original file. Additionally, while the core action is clear, the lack of detail about output defaults and post-conditions leaves the agent uncertain about the tool's complete behavior. The description is adequate for a simple tool but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (only 33% for file_path). The description mentions all three parameters but adds little beyond their names: 'Provide the local file path' and 'Optionally specify an output directory and output file name.' It does not clarify how output_dir and output_file_name interact, what happens if output_file_name lacks an extension, or what the default output name/directory is. Given the low coverage, the description should compensate with more detail but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Flatten a PDF file') and the effect ('forms, annotations, and layers become static content'). This verb+resource+effect structure makes the purpose unambiguous and distinguishes it from sibling tools like merge, split, or rotate, none of which perform a flatten operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 PDF needs to be flattened) but does not explicitly state alternatives or exclusion criteria. For example, it doesn't mention that filling forms is a separate tool or that flattening is irreversible. The usage context is inferred from the tool's unique purpose rather than stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explains the core action and mentions the API, but it does not disclose whether the original PDF is modified or a new file is created, permissions required, side effects, or output behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences front-loaded with the main action. It includes necessary parameter guidance without redundancy. Slightly dense due to parentheticals, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, and the description covers the required inputs but lacks details about default output behavior, overwrite semantics, and return values. It is adequate for a simple API wrapper but leaves notable gaps for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains pdf_file_path and attachment_file_paths clearly, and it adds meaning for request_doc_name and "output path." However, it does not explicitly describe output_dir or output_file_name, leaving some parameters under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: "Embed one or more files as attachments into a PDF" — a specific verb and resource. It distinguishes from siblings like add_barcode_to_pdf and extract_attachment_from_pdf, which are different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear how-to instructions: "Provide the path to the source PDF and a list of local file paths to attach." It also clarifies optional parameters. However, it does not explicitly mention when to choose this over alternatives, nor does it state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions the API and optional output path without explaining side effects, whether the original file is modified, authentication requirements, rate limits, or what is returned. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, with the purpose front-loaded and no filler. Every phrase contributes to understanding the tool's function and key parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema or annotations, the description is insufficiently complete for a 6-parameter conversion tool. It omits what the tool returns, whether a new file is created, and how output_dir/output_file_name interact. The agent is left with gaps that could lead to incorrect invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes file_path, compliance, allow_upgrade, and allow_downgrade. The description adds an example compliance value and reinforces the local file path, but does not meaningfully elaborate on output_dir or output_file_name (only 'optional output path'). With 67% schema coverage, the description provides marginal added value but does not fully compensate for missing fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts a PDF file to PDF/A archival format, using the specific PDF4me PdfA API. This specific verb-resource pairing distinguishes it from sibling conversion tools like convert_to_pdf or convert_pdf_to_word.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by mentioning 'archival ISO format' and instructs the agent to provide the local file path, choose compliance, and set optional output path. However, it does not explicitly compare with alternative tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the output format ('Output is always DOCX') and references the PDF4me API, but does not disclose potential failure modes, file size limits, or side effects (e.g., whether the input PDF is modified). This is a significant gap for a conversion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—two sentences—with all essential information front-loaded. It avoids redundancy and effectively summarizes the tool's purpose, required input, optional parameters, and output format without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description provides a reasonable overview: it explains the core function, the key options, and the output format. However, it could be more complete by clarifying the exact return value (though 'Output is always DOCX' gives a hint) and any prerequisites or limitations, such as handling of unsupported files or performance implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, which is moderate. The description lists several options (quality, merge_all_sheets, language, OCR, output path) adding slight context beyond the schema, such as the 'Draft/High' values for quality and clarifying 'OCR when needed'. However, it does not explain output_dir and output_file_name in detail, and the schema already covers most parameter meanings, so the added value is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Convert') and resource ('PDF file to Word (DOCX)'), making it unambiguous. It also differentiates from sibling tools like convert_pdf_to_excel or convert_pdf_to_powerpoint by explicitly naming the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for using the tool (local PDF file, provide file path) and implies the use case (converting to Word). However, it does not explicitly mention when to choose this tool over alternatives (e.g., convert_to_pdf, convert_pdf_to_excel) or any exclusions, leaving the guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It reveals concrete output behavior: saving extracted_attachments.json for JSON, decoding outputDocuments to files, or saving/extracting ZIP archives. This goes beyond the schema and tool name, though it does not cover error handling, permissions, or whether the source PDF is modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences and no filler. It front-loads the core action and API endpoint, then packs output handling into the second sentence. The dense comma-separated clauses reduce readability slightly, but every word contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary operation and output handling adequately, but gaps remain: request_doc_name is unexplained, there is no usage guidance versus alternatives, and no output schema exists to describe return values. For a tool with three params and no annotations, it is serviceable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains pdf_file_path and output_dir (including the default behavior 'next to PDF'), but completely omits request_doc_name, leaving its purpose and use unclear. The partial coverage is useful but not fully sufficient for a schema with three undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's action: 'Extract embedded file attachments from a PDF', naming both the verb and the resource. It also includes the specific PDF4me API endpoint, making the purpose unambiguous and distinct from sibling tools like extract_pages_from_pdf or extract_text_from_pdf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus sibling extraction tools, nor any mention of alternatives or exclusions. The description focuses on mechanics (e.g., output_dir default) rather than selection criteria, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral implications. It states the action and endpoint but does not mention output behavior, file handling, overwrite semantics, or required permissions. As a result, the agent is left guessing about side effects and return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single sentence that leads with the purpose, then lists inputs and options. It is appropriately sized and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a relatively simple tool, but with no output schema and no annotations, the description should explain the result format and any side effects. It omits return value details and is vague about output file naming/destination. Given the tool's simplicity, the omissions are noticeable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description names key parameters (image_file_path, orientation, request_doc_name, output path) and gives the valid orientation values, adding meaning beyond the raw schema. However, it uses the vague phrase 'output path' and does not clarify output_dir versus output_file_name. Schema coverage is 0%, so this partial compensation is helpful but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Flip an image horizontally or vertically'), clearly distinguishing it from sibling image tools like rotate_image or crop_image. The mention of the PDF4me endpoint is concrete but does not confuse the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a clear use case for flipping images either horizontally or vertically. It does not explicitly name alternative tools or state when not to use it, but the operation is self-evident among siblings. This meets the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It adds some behavioral context by mentioning 'async polling' and supported input types, but it does not disclose auth requirements, output file behavior (e.g., overwriting), 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys the tool's purpose, API reference, and key supported features. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and no annotations, the description is too thin. It fails to clarify the 'async polling' mechanism (does the tool wait or return a job ID?), how to choose between document_data_file_path and document_data_text_path, or the meaning of required fields. The high parameter complexity demands more guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter already has a description. The description only summarizes categories (template file, document data text/file, output type) without adding new meaning or clarifying relationships between optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: generating a single document from a template, with the specific API endpoint. The word 'single' distinguishes it from sibling tool generate_documents_multiple.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies use for single-document generation but does not explicitly mention when to use alternatives (e.g., generate_documents_multiple for multiple documents) or provide exclusions. No explicit guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: isAsync true, 202 + Location polling, output file name, naming logic for docName, and required fields. Since annotations are absent, this carries the full burden, and it does so well, though it omits error scenarios and output content details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with no fluff, but the packed technical details could be better structured. It is concise enough, with each clause carrying meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with zero schema descriptions and no annotations, the description covers most operational aspects: input fields, async behavior, output file, and file types. However, it omits output_dir semantics, output JSON structure, and failure handling, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains fields and fields_csv (comma-separated, trimmed), mode (0 Standard/1 Strict), doc_name logic, document_type (omit if empty), profiles (sanitized), and pdf_file_path formats. However, output_dir is not mentioned, and the schema provides no descriptions, so this is a strong but incomplete compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'extract named fields via PDF4me POST /api/v2/ProcessUniversalDocument' with a specific verb ('extract'), resource (document), and scope (named fields). It distinguishes from sibling process_* tools by emphasizing 'Universal' and user-specified fields, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to choose this tool over alternatives like process_invoice or parse_document. The description is purely technical, providing API details but not strategic use cases or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal sync/async processing with 202 polling and long HTTP timeouts, which are useful operational details. However, it does not describe side effects (e.g., whether the original file is modified or a new file is created), return format, or error behavior, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences, each providing distinct value: the operation, API context, processing modes, input type support, and required/optional parameters. No wasted words; information is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but without an output schema or annotations, the description should explain the expected result and side effects. It covers input types and async behavior but omits what the agent should expect as a return value (e.g., success status, output file path) and whether the source file is preserved. This is a clear gap for invocation and result handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, so the description should compensate for the undocumented output_file_name and output_dir parameters. It only reiterates that output_file_name is required and output_dir is optional, without adding semantic context about their formats or meaning. The description does not clarify the purpose of these parameters beyond their names, which are self-evident but still need explicit definition for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Remove EXIF metadata tags from a local image', which is a specific action on a specific resource. It clearly distinguishes from sibling tools like get_image_metadata (which reads metadata) and rotate_image_by_exif_data (which uses EXIF for rotation) by stating the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via the verb 'Remove' and the mention of 'local image', but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. There is no direct guidance on when to prefer this over other image manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses that the tool adds interactive fields and saves the resulting PDF to disk, adding useful context. However, it does not explain output file behavior (e.g., whether original is modified), error conditions, or API authentication requirements, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently cover purpose, key inputs, and output behavior. No redundant words; front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no annotations, and no output schema, the description provides a solid overview but lacks critical invocation details such as pages spec format, size units, and whether the tool returns anything (e.g., saved file path). It is adequate for initial selection but insufficient for error-free invocation without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by naming the core parameters and clarifying that position_x/y are in PDF units and form_field_type restricts to TextBox/CheckBox. However, it leaves 'pages' and 'size' underspecified (format/units) and ignores optional parameters output_dir, output_file_name, and request_doc_name, so coverage is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool adds interactive form fields (TextBox or CheckBox) to a PDF, distinguishing it from sibling tools like add_text_stamp_to_pdf (static text) or fill_pdf_form (filling existing fields). The verb 'Add' and resource 'form field' are specific, and the API endpoint provides additional clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through its purpose statement and lists required inputs, but does not explicitly state when to choose this tool over alternatives or provide exclusions. No mention of fill_pdf_form or extract_form_data_from_pdf, leaving the agent to infer the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It mentions 'Uses async 202 polling when applicable,' which is a useful operational detail. However, it does not disclose whether the original file is overwritten, what the return value is, or any side effects. The optional output parameters imply file creation, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences to convey purpose, parameters, and a notable behavioral aspect. It is front-loaded with the core action and avoids redundancy. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations. The description covers the API endpoint, parameters, and async polling, but fails to explain the return value or the behavior of the optional output parameters. It is adequate but leaves gaps that an agent would need to infer or test.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all parameters and provides enum values for image_type and compression_level, which adds meaning beyond the bare schema. However, it does not explain the semantics of doc_name, output_dir, or output_file_name beyond calling them 'optional', leaving their purpose ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Compress an image via PDF4me CompressImage'. It specifies the verb ('compress') and resource ('image'), and includes the API endpoint. This distinguishes it from sibling tools like resize_image or convert_image_format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives, nor does it name any alternative tools. However, the purpose is obvious from the name and description, implying usage for image compression. The mention of 'async 202 polling' gives a hint about behavior but no explicit guidance on when this applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavior. It states the conversion action but does not specify what happens to the output (e.g., where the PDF is saved, whether it returns a file path or binary), nor any error conditions or side effects. This is a significant gap for a tool with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, front-loaded with the core purpose. It lists examples of input formats and the required parameters without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple conversion tool with 3 parameters and no annotations or output schema, the description covers the purpose and inputs but omits output/return behavior. It also does not mention limitations (e.g., file formats supported beyond examples) or prerequisites. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers only file_path with a description (33% coverage). The description compensates by naming the optional output_dir and output_file_name and their roles ('optional output directory and output file name'), but it does not explain default behavior when null or what happens if only one is provided. It adds some meaning beyond the schema but not full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts local document files (DOCX, PPTX, XLSX, images, text) to PDF using a specific API. It names the input resource (local file) and output (PDF), and differentiates from sibling converters like convert_html_to_pdf or convert_url_to_pdf by specifying 'local document file'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this is for local document files, implying it is not for URLs or HTML, but it does not explicitly mention alternatives or exclusions. Context is clear enough for an agent to choose this over siblings, but no direct 'use this instead of X' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose side effects: writes extracted_resources.json, extracted_text.txt, and image files, plus output_dir defaults. However, it does not mention permissions, overwrite behavior, network requirements, or failure cases, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences: main purpose, key parameters, and outputs. No filler or redundant information. The API endpoint is included but does not bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, 0% schema coverage, no annotations, and no output schema. The description covers the main behavior and outputs but omits request_doc_name and does not explain return values or error scenarios, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for pdf_file_path, extract_text, extract_images, and output_dir (defaults next to PDF), and describes output file behavior. However, request_doc_name is completely unmentioned, and schema coverage is 0%, so not all parameters are compensated for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts text and/or embedded images from a PDF, specifying the exact action (extract), resource (PDF), and content types. This distinguishes it from sibling tools like extract_pages_from_pdf or extract_table_from_pdf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the function description — if you need to extract text and images from a PDF, this is the tool. However, there is no explicit when-to-use vs alternative guidance, no prerequisites, and no mention of 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the API response is saved as JSON with a raw text fallback, which is useful behavioral information. However, it does not mention whether the original file is modified, what error handling occurs, or any prerequisites like network access or authentication. Some transparency is present, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, uses concise phrasing, and front-loads the core purpose first. Every sentence adds value: the first states the action and API, the second gives input/output specifics. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and zero parameter descriptions, the description is the only context for usage. It provides the basic workflow but omits important details such as the structure of the tracking changes data in the response, how output_dir and output_file_name interact, and any usage caveats. For a 4-parameter tool, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that word_file_path refers to a local .docx/.doc file and implies output_dir/output_file_name relate to saving the JSON response. However, it does not explain request_doc_name at all, and with four parameters, the description covers only about half of them, leaving the agent without meanings for the rest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Extract') and resource ('tracking changes data from a Word file'). It also distinguishes itself from sibling tools like enable/disable_tracking_changes_in_word and extract_text_from_word by focusing specifically on extracting tracking-change data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by specifying the input type (.docx/.doc) and the output behavior (saves API response as JSON). It doesn't explicitly name alternatives or say when not to use it, but the purpose is self-evident relative to the sibling tools, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits, but it only explains the general purpose and parameter usage. It does not state whether the original file is modified, what output is produced, where the result is saved, or if network/API authorization is required. This leaves significant ambiguity for a file transformation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short, focused sentences: purpose, required input, optimize_profile choices, and optional output parameters. Every sentence contributes distinct information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description gives a basic usage template but omits critical context: how to retrieve the resulting PDF, what happens if output_dir is omitted, what the different optimize_profile presets actually do (though referenced to docs), and any error conditions. It is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (file_path and optimize_profile are described, output_dir and output_file_name are not). The description repeats the optimize_profile values already in the enum and merely mentions output dir/name as optional without explaining default behavior or naming rules. It adds a little value but does not compensate fully for the uncovered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Linearize' with a clear resource 'PDF file' and states the purpose 'for faster web loading and progressive display'. It distinguishes from sibling tools by calling out the web-loading benefit, which no other PDF tool explicitly offers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (for faster web loading and progressive display) and provides direct invocation steps. However, it does not explicitly name alternatives (e.g., compress_pdf) or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It fails to mention whether the original file is overwritten, whether API authentication is required, or what happens on success/failure. For a mutating operation this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The main action and API are front-loaded, and optional parameters are listed succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all input parameters and notes optional output via output_dir and output_file_name. However, without annotations or an output schema, it omits critical contextual details like side effects, required credentials, output behavior when no directory is specified, and error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description maps to all five parameters: file_path, password, pdf_permission, output_dir, and output_file_name. It adds the concrete example 'All' for pdf_permission and clarifies that output directory and file name are optional, which is beyond the partial schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb 'Password-protect' targeting a 'local PDF' via the PDF4me Protect API. This clearly distinguishes it from sibling tools like unlock_pdf, compress_pdf, and conversion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear operational instructions ('Provide the file path, open password, and pdf_permission') but never explicitly states when to choose this tool over alternatives such as unlock_pdf. Usage context is implied by the verb but no exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden; it discloses async 202 polling, saving to disk, and support for page ranges, alignment, size, margins, and opacity. However, it does not explain return values, error behavior, or whether the operation creates a new file or modifies the original in place.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, then options, then output behavior. It contains no filler and every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters, no output schema, and no annotations, the description covers the core purpose and output location but omits return value details, async polling specifics, and parameter units. It is adequate for a quick overview but leaves notable gaps for a complex API wrapper.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 44%, and the description adds semantic grouping for page ranges, alignment, size, margins, opacity, and output directory/file name. Yet it does not clarify units (mm vs px), boolean flag effects, or the relationship between paired margin/width/height parameters, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Add') and resource ('signature image to a PDF'), and names the underlying PDF4me SignPdf API. This distinguishes it from sibling tools like add_image_stamp_to_pdf or add_text_stamp_to_pdf by focusing specifically on signing with an image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (signing a PDF with an image) and gives input requirements, but it does not explicitly state when to use this tool over alternatives or mention exclusions. There is no when-not or alternative guidance, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It adds useful context such as opacity range (0.0–1.0), position enums, custom x/y, rotation in degrees, and optional output path, but it does not explain whether the source image is modified, the output file format, or potential side effects. This leaves some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. It front-loads the core purpose and then enumerates required and optional parameters efficiently. It could be slightly better structured (e.g., separating required vs. optional), but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter tool with no output schema and no annotations, the description covers most parameter semantics and gives some ranges, but it lacks important contextual information: what the output looks like, whether the original file is overwritten, any prerequisites (e.g., file formats, permissions), and how it fits with sibling tools. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly names most parameters (image_file_path, watermark_image_file_path, position, opacity, offsets, position_x/y, rotation, output path) and adds meaning beyond the schema: it lists all allowed position values, clarifies that position_x/y are for 'custom', and gives an opacity range. Some output-related parameters (doc_name, output_dir, output_file_name, watermark_file_name) are only vaguely covered by 'output path'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool overlays a watermark image on a source image, using a specific verb ('Overlay') and resource ('watermark image on a source image'). It also names the API endpoint. This distinguishes it from sibling tools like add_text_watermark_to_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for image watermarks and lists all required parameters and position options, but it does not explicitly state when to use this tool versus alternatives such as add_text_watermark_to_image or add_image_stamp_to_pdf. There are no clear exclusions or alternative pointers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the operation 'Saves the stamped PDF to disk' and references the API field isItalics, offering some transparency. However, it does not clarify whether the original PDF is modified or a new file is created, nor does it mention permissions, rate limits, or side effects. This is a moderate gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. Three sentences cover the purpose, key parameters, and output behavior. The example for pages ('all, 1, 1-3') is practical. No redundancy or filler—every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (24 parameters, no annotations, no output schema), the description is insufficiently complete. It does not explain how the output file is named/determined, what the function returns, or any prerequisites (e.g., API key). It also fails to mention many parameters, leaving the agent to guess their semantics. A more comprehensive description is needed for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate. It names key parameters like pdf_file_path, stamp text (presumably 'text'), pages, alignX/alignY, font and margin settings, giving some meaning beyond the schema. However, it uses informal names (alignX/alignY instead of align_x/align_y) and leaves many parameters (rotate, opacity, transverse, etc.) completely unexplained. Partial compensation, but far from complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add a text stamp or watermark to a PDF.' It specifies the resource (PDF) and the action (adding text), and distinguishes it from sibling tools like add_image_stamp_to_pdf and add_text_watermark_to_image by the 'PDF' and 'text' qualifiers. Mentioning the underlying API endpoint adds specificity without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: it is for adding text stamps/watermarks to PDFs, with an example of pages syntax. It does not explicitly name alternatives or exclusions, but the context is specific enough that an agent can infer it applies to PDF text stamping rather than image stamping or other formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral details such as long HTTP timeouts and the default output filename pattern. It does not mention potential side effects like overwriting existing files or whether the source is modified. The fragment 'complete.' appears to be an incomplete thought, reducing clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains a typo with a double space and the unexpected fragment 'complete.', which appears to be a leftover sentence. This makes the text feel unfinished and less concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description explains how to invoke the conversion and where the output is saved. However, it does not state what the function returns or any error handling. The incomplete 'complete.' sentence suggests missing content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes file_path and output_dir, and the description reinforces these. It adds the default naming behavior for output_file_name, which the schema lacks, providing extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts a local Markdown file to PDF using the PDF4me API. This specific verb+resource combination distinguishes it from sibling tools like convert_html_to_pdf or convert_to_pdf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates the tool is for local .md files and requires file_path and output_dir. However, it does not explicitly mention alternatives or when not to use it, but the use case is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: the API request body composition, and that a 202 response triggers polling of the Location URL until the PDF is ready. However, it does not mention error handling, whether the original file is preserved, or authentication requirements, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-sentence but each sentence contributes useful information: purpose, parameters, API details, and polling behavior. It is front-loaded with the main purpose and remains appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, API behavior, and polling, but lacks details on return values (no output schema) and default behavior for output file naming/directory when not provided. Given the tool's complexity (6 params, no annotations, no output schema), it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, covering language, file_path, quality_type, and ocr_when_needed. The description adds 'local path' to file_path and identifies the optional output directory/file name, but provides no further detail on their behavior or defaults. It also maps parameters to API fields, adding some meaning beyond the schema, but not fully compensating for the missing output_dir/output_file_name docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts a PDF to a searchable, editable PDF using OCR, which distinguishes it from sibling conversion tools like convert_to_pdf or convert_pdf_to_word. The verb 'convert' and specific resource (PDF via OCR) make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for PDFs that need OCR to become searchable/editable, but it does not explicitly mention alternatives or when not to use it. It provides clear context for its intended use case, though no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that output is always XLSX and lists controllable options (quality, merge_all_sheets, language, OCR, optional output path), which gives some transparency. However, it does not mention possible side effects such as file overwriting, external API dependencies/limits, or what happens when optional output path is omitted. These gaps prevent a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, two sentences, with the first sentence front-loading the core purpose and the second summarizing options. It avoids excessive detail and is easy to scan. It loses one point because the list of options is a run-on phrase rather than structured, making it slightly harder to parse quickly, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no output schema, and no annotations, so the description carries a heavy burden. It covers the main conversion purpose and parameter options, but it does not explain what the return value is (e.g., the output file path, success/failure), where the output is written if no output path is given, or prerequisites like file accessibility. These missing details reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71% (5 of 7 properties have descriptions). The description adds meaning by translating parameter names into plain language (e.g., 'quality (Draft/High)' clarifies the enum, 'OCR when needed' connects to ocr_when_needed, 'merge_all_sheets' is restated). It also introduces the concept of an 'optional output path,' which maps loosely to output_dir/output_file_name. However, it does not clarify the distinction between output_dir and output_file_name, and these two parameters remain under-explained. Thus, some but not full semantic value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Convert a local PDF file to Excel (XLSX) using the PDF4me ConvertPdfToExcel API.' This includes a specific verb (convert), resource (PDF), target format (Excel/XLSX), and even names the API. It distinguishes effectively from sibling conversion tools like convert_pdf_to_word or convert_pdf_to_powerpoint by specifying the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: whenever a user needs to convert a PDF to Excel, and it sets context by stating the required input ('Provide the file path to the PDF'). It does not explicitly name alternatives or exclusions, but the intended use is clear from the purpose, giving the user unambiguous context without needing further guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the input is remote (web_url), no local file is read, and the output defaults to output.pdf. However, it does not mention what the tool returns (e.g., file path, status), whether existing files are overwritten, or network/API error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary purpose, then required input, then optional categories. Every sentence adds meaningful information without redundancy, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters and no output schema, the description covers core usage (required URL, optional settings, save location) but omits what the tool returns or whether it returns a file path. It also lacks information on error scenarios or prerequisite API configuration, which is a notable gap for a complex tool with no annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 73%, so the schema already documents most parameters. The description adds useful context like 'no local file path is read' and the default output filename 'output.pdf', which is not in the schema. However, it groups parameters without adding detail on margin formats or display_header_footer, so it only partially compensates for the uncovered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Convert a web page to PDF' and names the exact API ('PDF4me ConvertUrlToPdf API'). It clearly distinguishes from sibling tools like convert_html_to_pdf by stating the required input is web_url and explicitly saying 'no local file path is read'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying that only a web_url (https://...) is accepted and no local file path is read, implying this tool is for converting web pages rather than local files. However, it does not explicitly name alternative tools or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It does mention the API endpoint, that the input is sent as Base64, the docName default, and that it saves a Word output file. However, it does not disclose whether the original file is modified, permission requirements, or potential side effects. It adds meaningful context but lacks deeper operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every sentence adds value (API endpoint, input details, output). No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation (disable track changes), no output schema, and no annotations, the description covers the main input, process, and output. It does not fully explain the optional output parameters, but these are likely self-evident based on naming. The description is fairly complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains `word_file_path` (local .docx/.doc path) and indirectly `request_doc_name` (defaults to input filename), but it does not explain `output_dir` or `output_file_name`. This adds meaning for the critical parameter but leaves some parameters undocumented, making it only partially compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool disables track changes in Word documents, with a specific verb ('Disable') and resource ('Track Changes in Word'). It distinguishes itself from siblings like 'enable_tracking_changes_in_word' and 'get_tracking_changes_in_word' by explicitly naming the action and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to remove track changes from a Word file) and provides context about input and output, but it does not explicitly state when to use this tool versus alternatives (e.g., enable_tracking_changes_in_word) or mention any exclusions. There is clear context but no explicit guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the process (file sent as Base64, docName defaults to input filename) and that it saves a Word output file. However, it does not disclose potential side effects, permission requirements, or error behavior, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose. It includes useful technical details (API endpoint, Base64) without excessive verbosity, though the first sentence is dense and could be split for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description provides most core details: purpose, input, default naming, and output. However, it does not describe the return value format or where the output file is saved, leaving some gaps for a tool with 4 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains word_file_path as a local Word file path with allowed extensions, and that request_doc_name defaults to the input filename. It does not clarify output_dir or output_file_name semantics explicitly, though their names are self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific function: 'Enable Word Track Changes' via the PDF4me API. It distinguishes itself from siblings like disable_tracking_changes_in_word and get_tracking_changes_in_word by specifying the exact action and output (a Word file with track changes enabled).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: input is a local Word file path (.docx/.doc), and it saves an output file. It does not explicitly mention alternatives or when not to use it, but the purpose is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output artifacts (extracted_tables.json, table_N.json, table_N.csv) and the default output directory behavior (defaults next to PDF), which gives useful clarity. It doesn't mention failure modes or whether the original PDF is modified, but the extraction scope 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the purpose, API endpoint, key parameters, and output files with no redundant or vague wording. Every clause adds value, making it extremely efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and output behavior, but it fails to explain one input parameter (request_doc_name) and offers no usage guidance relative to sibling tools. Given no output schema and no annotations, the description is functional but not fully complete for an agent deciding whether to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains pdf_file_path and output_dir (including its default behavior), but omits request_doc_name entirely. The third parameter is completely unexplained, leaving a significant gap for an agent trying to invoke the tool with all parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Extract tables from a PDF' and even names the underlying API endpoint (ExtractTableFromPdf). This clearly distinguishes it from sibling tools such as extract_text_from_pdf or convert_pdf_to_excel, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied by the name and description (extracting tables from PDFs), but there is no explicit guidance on when to choose this over alternatives like convert_pdf_to_excel or extract_text_by_expression. No when-not-to-use or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It discloses output behavior (saves JSON, text, CSV) and explains page_sequence options. However, it doesn’t state whether the original PDF is modified or mention any prerequisites, limits, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and includes the API endpoint and key parameters without fluff. It’s concise, though the first sentence is a bit dense with parameter names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description covers the core invocation and outputs but leaves gaps: request_doc_name is unexplained, and the format/content of the generated JSON/CSV files is not detailed. It’s adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are 0%, so the description is the only source. It explains page_sequence with examples, identifies expression as a regex, and marks output_dir optional, but it omits any explanation of request_doc_name, leaving a parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts text from a PDF based on a regex, naming the specific API endpoint. It distinguishes itself from siblings like extract_pages_from_pdf and extract_text_from_image by focusing on regex-based text extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when the tool is appropriate (extracting text matching a regex from a PDF) and includes practical parameter examples for page_sequence. It doesn’t explicitly name alternatives, but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the asynchronous HTTP flow ('202 + Location poll'), the output file ('saves process_health_card.json'), and the required IsAsync=true flag. It also explains doc_name extension fallback behavior. This goes well beyond a minimal description, though it omits error behavior and auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with no redundant filler; every sentence adds technical value. It front-loads the core purpose. Minor redundancy appears in 'no customFieldKeys or CustomFieldKeys' (likely a case-variant typo), slightly reducing polish.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main invocation path, async behavior, and output file, which are essential for a tool with no output schema. However, it leaves output_dir unexplained, does not describe the structure of the extracted data, and lacks guidance on error handling or prerequisites. For a simple 3-param tool, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains pdf_file_path (local .pdf/.png/.jpg/.jpeg as Base64) and doc_name (optional, defaults to basename, .jpeg fallback). However, output_dir is completely undocumented in both schema and description, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: 'extract structured data from a health card image/PDF'. It specifically names the document type (health card), distinguishing it from other process_* siblings. The mention of the PDF4me endpoint adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for health cards through its title and first sentence, and it gives operational constraints (only docContent/docName/IsAsync, no customFieldKeys). However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or alternative tools for non-health-card documents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses the async nature (202 + Location poll), the IsAsync=true requirement, the conditional omission of CustomFieldKeys, file format constraints, default doc_name behavior, and that output is saved to process_pay_stub.json. Missing details like auth, rate limits, and error handling prevent a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but each clause adds value: purpose, endpoint, key body constraints, file handling, async behavior, and output file. It is front-loaded with purpose and then provides operational details. The single run-on structure is slightly awkward, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers core behavior well (async, polling, file naming, side-effect output). Yet it omits output_dir semantics and any outline of the structured data returned, leaving gaps that could cause incorrect invocation or misinterpretation of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning for pdf_file_path (local file, Base64, allowed extensions), doc_name (defaults to basename, .png fallback), and custom_field_keys (PascalCase, omit when empty). However, output_dir is completely absent from the description, leaving a meaningful parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'extract structured data from a pay stub image/PDF' via a named API endpoint (PDF4me POST /api/v2/ProcessPayStub). This is a specific verb+resource pairing that distinguishes it from sibling tools like process_invoice or process_receipt by focusing on pay stubs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('extract structured data from a pay stub'), but it does not explicitly state alternatives or exclusions. It provides technical usage context (async, polling, accepted file types) but stops short of saying 'use this instead of process_invoice' or listing prerequisites beyond a file path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses async support and the API endpoint, which is useful context. However, it does not state whether the original PDF is modified in place or a new file is created, and it does not describe the return value or output format. The mention of 'Optional output directory and file name' implies a new output file but does not confirm behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that conveys the main action, required inputs, page sequence format, async behavior, and optional output. It is not overly long and contains no filler, but the run-on structure could be improved for readability. Every piece of information is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, 3 required) and no output schema, the description covers the core purpose and inputs but leaves gaps: it does not explain what happens after the operation (return value, output file details), whether the original is preserved, or how to handle the 202 Location polling result. It also does not clarify which file formats are accepted for the image beyond the schema's PNG/JPG hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (6 of 8 parameters have descriptions). The description repeats the parameter list and adds page sequence examples that are already in the schema description. It mentions 'image width/height in pixels,' which the schema already states. The description references 'isAsync' but this parameter is not present in the schema, adding confusion rather than clarifying parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Replace occurrences of a text string in a PDF with an image.' This is a specific verb+resource combination that distinguishes it from sibling tools like find_and_replace_text (text-only replacement) and replace_text_with_image_in_word (Word documents). The mention of the PDF4me API endpoint adds technical specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by listing required inputs (PDF path, image path, text to replace) and page sequence examples (all, 1, 1,3,5, 2-5). It also mentions async support via isAsync and 202 Location polling, which helps the agent know how to handle long-running operations. However, it does not explicitly name alternative tools or when-not-to-use scenarios, though the purpose implies when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses the HTTP method, endpoint, payload fields, and return format, which is helpful. However, it does not mention potential failures, authorization requirements, or file size limits, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and includes only relevant technical details. There is no wasted text, and every sentence contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without an output schema, the description adequately covers purpose, API details, request payload, and return value. It could mention relationship to subsequent tools or storage constraints, but given the low complexity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents file_path with 100% coverage, so the baseline is 3. The description adds that the payload includes docName and docContent, but it does not explain how file_path maps to these fields, so it provides only marginal additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload'), the object ('a local file'), and the destination ('PDF4me storage'), while referencing the specific API endpoint. This distinguishes it from all sibling tools, none of which focus on uploading a local file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (upload a local file to cloud storage before using PDF operations) but does not explicitly state when to use this tool versus alternatives, such as when a file is already stored in PDF4me. Usage is implied rather than spelled out with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses important format constraints (html_content is plain HTML, not base64), the meaning of pages (empty string = all), and mentions optional parameters like skip_first_page and margins. However, it does not state whether the operation modifies the input PDF in place or creates a new output file, nor does it mention authentication, rate limits, or side effects like overwriting files. Some behavioral context is provided, but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and lists key parameters without fluff. Every sentence carries information, and it avoids excessive detail or repetition. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no annotations and no output schema, the description is not fully complete. It covers the main required and some optional parameters, but leaves several parameters unexplained (output_dir, output_file_name, request_doc_name) and does not describe expected behavior on failure or output format. The description gives a good starting point but would benefit from more detail to ensure correct invocation in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds significant meaning for key parameters: html_content format, header_footer_location enum values, pages default to all, skip_first_page, pixel margins, and output path. However, it does not fully clarify all 12 parameters, especially the distinction between output_dir, output_file_name, and request_doc_name, or the specific margin parameter names. It provides substantial value beyond the bare schema, but leaves some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: adding HTML as a header, footer, or both to PDF pages. It names the specific API endpoint (AddHtmlHeaderFooter), and the verb-resource combination ('Add HTML as header, footer, or both on PDF pages') distinguishes it from sibling tools like add_page_number_to_pdf or add_image_stamp_to_pdf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining what the tool does and key parameters, but it does not explicitly state when to use this tool over alternatives or provide exclusions. For example, it does not mention that this tool is for custom HTML content rather than simple page numbers or stamps, or that it might not be suitable for other header/footer needs. The context is clear enough for an agent to infer, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions using the PDF4me API and optimization profiles, but it does not clarify whether the original file is overwritten or a new file is created, whether network access is required, or what the output behavior is. This leaves significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose and followed by concise usage instructions. Every sentence adds value with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and parameters but leaves out important context: no output schema is provided, yet the description does not mention what the tool returns (e.g., success message, output file path). It also omits details about error handling, default output behavior, and the dependency on an external API. While simple, the missing behavioral specifics make it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions (0% coverage), so the description must compensate. It explains file_path as the local PDF path, optimize_profile with its three options and their meanings, and output_dir/output_file_name as optional. This adds meaningful context beyond the raw schema, though it does not state default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Compress a PDF file') and the resource ('PDF'), distinguishing it from sibling tools like compress_image. The mention of optimization profiles further specifies the tool's unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear instructions on how to use the tool: provide a local file path, choose an optimization profile, and optionally specify output details. It implies when to use (when reducing PDF file size is needed) but does not explicitly exclude alternatives or mention 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry the full burden of behavioral disclosure. It does state that this uses an API (implying network access) and lists configurable options. However, it does not disclose default output behavior (where the PDF is written if output_dir/output_file_name are not set), whether existing files are overwritten, what the API returns (if anything), or error handling. The description is partially transparent but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It consists of two sentences: the first states the core purpose, and the second lists configurable options and output settings. Every sentence carries relevant information, with no filler or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no output schema, and no annotations, the description covers the main functional aspects: input file, configuration options, and output naming. However, it lacks important contextual details such as return behavior (whether the PDF is returned or just saved), error conditions, network/auth requirements (beyond 'API'), and default output directory/file name behavior. The description is adequate for basic use but not fully complete for an API-driven tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, and the description partially compensates by listing major parameter groups (layout, page format, scale, margins, print background, header/footer, output directory/file name). However, it does not explain units, defaults, or allowed values beyond what the schema already provides. For example, margins are mentioned but the description doesn't specify that they are in pixels (as seen in schema defaults like '40px'). The description adds an overview but not deep semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Convert a local HTML file to PDF' with a specific verb (Convert), resource (local HTML file), and output (PDF). It distinguishes from sibling tools like convert_url_to_pdf (which handles URLs) by explicitly stating 'local' and 'Provide the file path'. The mention of 'PDF4me ConvertHtmlToPdf API' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool: when you have a local HTML file and need a PDF. It says 'Provide the file path to the HTML document', which implies local input. It doesn't explicitly exclude remote URLs or mention alternatives, but the context emphasizes local file handling, so a clear usage context is provided without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions the API and lists options, but does not state what happens to the output (e.g., where the Excel file is saved, default output directory), whether it returns a result, or potential side effects. The phrase 'optional output path' hints at output but lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and API name, then a compact list of options. Every sentence earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should explain the output behavior more clearly. It mentions 'optional output path' but does not specify default locations or return values. However, the schema covers most parameter details, and the core purpose is clear. This is a minimum viable description but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, so the baseline is 3. The description adds grouping and context: it summarizes options like 'worksheet_name, title formatting, number/date conversion and formats, ignore_null_values, first_row/first_column' and clarifies that first_row/first_column are 1-based. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Convert a local JSON file to Excel (XLSX)' with a specific verb ('Convert') and resource (JSON to Excel). This distinguishes it from sibling tools like convert_pdf_to_excel. The mention of 'PDF4me ConvertJsonToExcel API' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this tool is for local JSON files, implying use when you have a .json file to convert to Excel. It does not explicitly mention alternatives or exclusions, but the context is clear enough. The phrase 'Provide the file path to UTF-8 JSON' gives actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the output is always PPTX and mentions the availability of options, but it does not explain side effects (e.g., whether the input file is modified), output handling when no path is given, or network/API behavior. Some context is added beyond the schema, but significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. Each sentence contributes useful information: purpose, how to specify the input, available options, and guaranteed output format. There is no wasted language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 7 parameters, the description provides a clear overview but lacks detailed semantics for output placement (output_dir, output_file_name) and what happens on successful conversion. It states the output format but does not describe where or how the result is returned. Adequate for a basic understanding, but incomplete for fully confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 71% of parameters with descriptions. The description restates several option names (quality, language, OCR, merge_all_sheets) and mentions an optional output path, but it does not provide extra detail about the two undocumented parameters (output_dir, output_file_name) or their defaults. It adds marginal value over the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts a local PDF file to PowerPoint (PPTX), using a specific verb and resource. It distinguishes from sibling conversion tools (e.g., convert_pdf_to_excel, convert_pdf_to_word) by explicitly targeting PPTX output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario: converting PDF files to PowerPoint. It provides context by mentioning the file path and output format, but does not explicitly name alternatives or exclusions. The purpose is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It explains parameter meanings but does not state whether the operation mutates the original file, where output is saved, or what the response contains. The lack of output schema and side-effect information is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it opens with the core action, then explains the two modes and their respective parameters in a compact format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, no output schema, no annotations), the description covers the essential crop logic but leaves several parameters undocumented (image_file_path, doc_name, output_dir, output_file_name). It is adequate for understanding the main functionality but incomplete for a fully autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds significant meaning by grouping parameters according to crop_type: border-related params (left/right/top/bottom_border) and rectangle-related params (upper_left_x/y, width, height). It also clarifies units (pixels). However, it does not explain required params like image_file_path or output options, so it falls short of full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Crop an image' with a specific verb and resource, and goes on to distinguish the two crop modes (Border vs Rectangle). This differentiates it from sibling image tools like resize_image, rotate_image, and flip_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when cropping is needed) and provides explicit guidance on which parameters apply to each crop_type. However, it does not explicitly exclude alternatives or mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits like side effects and output. It only mentions the API endpoint and input format, but does not state whether the original file is modified, what the output is, or any authentication requirements. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and followed by parameter details. It is concise, with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description covers input parameters but misses output behavior, error conditions, and side effects. It also lacks context about prerequisites like API keys. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema description coverage, the description compensates by explaining pdf_file_path and page_numbers with concrete examples, and mentioning optional request_doc_name and output path settings. It covers all parameters, though it could be more explicit about output_dir and output_file_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Extract selected pages from a PDF' with a specific verb and resource, making it easy to understand the core function. It distinguishes from sibling tools like delete_pdf_pages or split_pdf by focusing on extracting a subset of pages, not deleting or splitting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for extracting specific page ranges from a PDF into a new document, and the parameter examples provide clear context. However, it does not explicitly contrast with alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It reveals the async behavior ('202 + Location poll'), the output file ('saves process_order.json'), and nuanced parameter handling such as doc_name not being overwritten by the server and profiles being trimmed/omitted/wrapped. These are non-obvious traits that go well beyond what the schema conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and well-structured, front-loading the purpose and then detailing the JSON body, parameter behaviors, and response handling. Every sentence provides non-obvious implementation details, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter documentation, the description is largely complete: it covers input requirements, request body construction, polling behavior, and the saved output file. However, it does not clarify output_dir semantics or describe the structure of the extracted order data, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly explains doc_name (sent as docName or defaulted from pdf_file_path), pdf_file_path (local file types accepted), and profiles (trim, omit, wrap logic). However, output_dir is never mentioned, leaving its purpose and relationship to the saved file ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'extract structured order data via PDF4me POST /api/v2/ProcessOrder', which is a specific verb+resource pair. This differentiates it from sibling process_* tools like process_invoice or process_receipt by focusing on 'order data', though it does not elaborate on what constitutes an order or the exact output structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling process_* tools. The description gives detailed invocation instructions but omits any decision context, such as 'use for purchase orders' or exclusions relative to alternatives like process_invoice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it uses the PDF4me API and returns structured JSON, but it does not explain implications like network usage, file size limits, or error handling. The mention of '(payload key isAsync)' is cryptic and could confuse users about synchronous behavior. With no annotations, the description only partially covers behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise and front-loaded with a clear purpose. However, the parenthetical '(payload key isAsync)' is unclear, adds noise, and does not earn its place. Otherwise, the rest is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool, the description covers the essential usage (image path, optional type) and specifies the return format (JSON). Since there is no output schema, this is sufficient. It lacks details on edge cases, but the tool is low-complexity, so this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters (file_path and image_type). The description merely repeats 'image path' and lists the same enum values, adding no new semantic detail. Therefore, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads barcodes and QR codes from a local image, using a specific verb ("Read") and resource (image). It distinguishes itself from sibling tools like 'read_barcodes' by explicitly noting 'from a local image' and requiring an image path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you have a local image path and want to extract barcodes/QR codes. It does not explicitly mention alternatives or exclusions, but the focus on 'local image' implies a distinction from other tools. No explicit when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully mentions async 202 polling and that the output is saved under output_dir, which adds behavioral context. However, it omits important edge behaviors such as what happens when EXIF metadata is missing, file overwriting rules, or the exact return value, leaving transparency incomplete for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the core purpose, then adds key behavioral notes (async polling, output directory requirement). Every sentence contributes useful information without redundancy or fluff, achieving an ideal size for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main behavior (rotation, output location) and a technical detail (async polling), but lacks information about return values and error cases, especially given there is no output schema. It is reasonably complete for a straightforward tool, but should have explained what the caller receives and how missing EXIF data is handled to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with output_file_name lacking any schema description. The description reinforces the semantics of output_dir ('saves the rotated image under that directory') but adds little to file_path and nothing to output_file_name. It provides some value beyond the schema, but does not fully compensate for the undocumented optional parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool rotates a local image based on EXIF orientation metadata, using a specific verb ('rotate') and resource ('local image ... EXIF orientation metadata'). This distinguishes it from sibling tools like rotate_image and flip_image by naming the specific rotation trigger (EXIF) and the local input requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: automatically rotating an image using EXIF orientation data. It also notes the requirement for output_dir. However, it does not explicitly state when not to use it (e.g., images without EXIF metadata) or name alternatives like rotate_image for manual rotation, so it falls short of full 'when/when-not/alternatives' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It reveals the API dependency and the uniform application to all pages, but does not state whether the original file is modified, what the default output behavior is, or any permission/network implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences totaling ~30 words, front-loaded with the primary action and directly followed by required input details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations or output schema, and the description leaves ambiguity about output file behavior and return values. It also does not acknowledge the closely related rotate_pdf_page tool. While the essential invocation parameters are covered, the description falls short of fully contextualizing the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents file_path and rotation_type, but output_dir and output_file_name are only shown as nullable strings. The description confirms all four parameters and lists rotation_type's enum values, but adds no new semantic detail for the output parameters. With only 50% schema coverage, the description partially compensates but leaves behavior of output parameters unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Rotate') and resource ('all pages of a PDF') and explicitly states that rotation is applied uniformly, distinguishing it from sibling tools like rotate_pdf_page that target specific pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly describes the tool's purpose (rotate all pages uniformly) and mentions optional output parameters, but does not explicitly name alternatives or state when not to use it. The phrase 'all pages' implicitly contrasts with page-specific rotation, but the description stops short of explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses async behavior via isAsync and 202 Location polling, and states it saves the updated PDF to disk. Yet it does not explain file overwriting behavior, permissions, or that isAsync is not present in the input schema, which is a gap given there are no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes useful API details. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, API endpoint, async support, and save action, but omits details about output file path handling (output_dir, output_file_name) and does not clarify the isAsync mismatch with the schema. Given no output schema and 10 parameters, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so the schema already documents most parameters. The description lists the required fields in CamelCase, but does not add much semantics beyond naming them, except implying all fields are needed together. It does not explain relationships between parameters or the missing isAsync parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates hyperlink annotations in a PDF, names the specific API endpoint, and lists the relevant update fields. This distinguishes it from sibling tools like find_and_replace_text, which targets text rather than hyperlinks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for updating hyperlink annotations in a PDF, requires a local path and all update fields, and supports async. However, it does not explicitly state when to use it over alternatives or mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It mentions sync/async processing and optional output settings, but does not explain return behavior, file system side effects, or error conditions. It adds some value beyond the schema but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, and contains no redundant or filler text. Every sentence adds relevant detail about scope, formats, and processing options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple file conversion tool with a small schema and no output schema, the description covers the essentials: operation, file source, supported formats, processing modes, and output options. It does not describe return values, but that is less critical here. A minor gap is the lack of guidance on parameter defaults for current_image_format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, and the description clarifies the roles of current/new format and output options, which maps to the schema parameters. However, it does not compensate for the undocumented output_dir and output_file_name semantics in detail, and merely restates defaults already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Convert a local image between formats'), names the resource (local image), and lists supported formats. This distinguishes it from sibling image tools like resize_image or compress_image, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use the tool: for converting local images between specified formats using the PDF4me API. It does not explicitly mention alternatives or exclusions, but the purpose is specific enough that no confusion with sibling tools is likely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses the key side effect: 'Saves the file and returns the path.' It also specifies PNG output. It does not cover overwrite behavior or error cases, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, and no wasted words. It balances examples and behavior disclosure efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 5 parameters, and the description covers the main action and return value. However, the parameter naming mismatch and omission of output directory/file name options mean the agent may not correctly invoke all parameters, especially since there is no output schema to clarify return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description covers text, barcodeType, and hideText, but uses camelCase names that do not match the schema's snake_case properties (e.g., barcodeType vs barcode_type, hideText vs hide_text). It omits output_dir and output_file_name entirely, leaving 2 of 5 parameters unexplained. Since schema description coverage is 0%, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Create a standalone barcode or QR code image (PNG)'. It identifies the resource (barcode/QR image) and distinguishes from sibling tools like add_barcode_to_pdf by using the word 'standalone'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when a standalone image is needed) and contrasts with adding barcodes to PDFs. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses that the tool calls an external API and saves a file (extracted_form_data.json), which is useful behavioral context. It does not mention potential side effects like overwriting files, but the core behavior is adequately described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and directly states the action, input parameters, and output artifact. No wasted words, information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main inputs and output side-effect, but with no output schema it does not elaborate on the JSON response structure or the meaning of request_doc_name. It is adequate for a straightforward extraction tool but leaves some semantic gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the three parameter names and marks two as optional, but does not explain the purpose of request_doc_name. Only output_dir is indirectly described via the saved file. The description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts all PDF form fields and values, naming the specific API endpoint. This distinguishes it from sibling tools like extract_text_from_image or extract_pages_from_pdf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on what inputs are used and that it saves a JSON file, but it does not explicitly state when to use this tool over alternatives. The focus on 'PDF form fields' implies the use case, though no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behaviors: async execution ('202 + Location poll'), output persistence ('saves process_receipt.json'), parameter defaults, docName resolution, and customFieldKeys merging rules. It omits auth/rate limit details but provides substantial behavioral context 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but presented as a long run-on paragraph with many parenthetical clauses, making it harder to scan. It repeats the tool name and packs several distinct concerns into one sentence, reducing structural clarity despite every part having substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 10 parameters and no output schema or annotations, the description is largely complete: it covers purpose, key parameters, execution flow (202 + Location polling), and the output artifact. Missing details like output_dir semantics and exact return payload are gaps, but the overall context is robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by mapping API field names, explaining customFieldKeys camelCase and CSV merging, providing receipt_type examples, and stating boolean defaults. It leaves output_dir unexplained, but the majority of the 10 parameters receive meaningful semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'extract structured receipt data via PDF4me POST /api/v2/ProcessReceipt.' This differentiates it from sibling document-processing tools by targeting receipts and structured extraction. The redundant title phrase is a minor issue but does not obscure purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the receipt use-case through 'extract structured receipt data' and the list of receipt_type examples, but it never explicitly states when to choose this tool over related siblings like process_invoice or process_universal_document. There is no mention of exclusions or alternative tools, leaving usage guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose that a local file path is required and that it uses a remote API, but it says nothing about whether the source PDF is modified, where the output file is written, or what the API response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences with no filler. The main verb and target come first, followed by required parameters and then optional parameters, making it well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool with 22 parameters and no annotations or output schema. The description covers input semantics and API context well, but it misses output-file behavior and alternative-tool guidance, which are important for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description is essential. It adds meaning by enumerating barcodeType, pages, alignX/alignY, hideText, opacity, size/margins in MM or points, displayText, showOnlyInPrint, and isTextAbove, with concrete examples. It omits output_dir, output_file_name, and request_doc_name, but the core parameter meanings are well covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Draw a barcode or QR code onto PDF pages.' It clearly differentiates from sibling tools like create_barcode or read_barcodes by targeting an existing PDF and naming the underlying PDF4me API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the prerequisite ('Requires local pdf_file_path') and gives concrete allowed values for barcodeType, pages, alignX, and alignY, making the intended use case clear. It does not explicitly mention alternatives or exclusions, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the side effect of saving the resulting PDF to disk and references the PDF4me API, implying an external call. However, it omits details about potential file overwrites, error behavior, or network requirements, leaving some behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, followed by additional usage details. Every sentence contributes value without repetition or fluff, achieving high conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no annotations, and no output schema, the description is not fully complete. It covers the core functionality and main parameters but leaves gaps around request_doc_name, output file naming behavior, error handling, and exact output location. It is adequate but not thorough for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must add meaning. It explains the key parameters: 'local PDF path' for pdf_file_path, and 'optional margins in millimeters (margin_left/right/top/bottom, 0-100)' for the four margin parameters, including a range. It also indirectly suggests output_dir/output_file_name via 'Saves the resulting PDF to disk.' However, request_doc_name remains unexplained, preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Add margins to a PDF.' It distinguishes itself from sibling tools (e.g., add_attachment_to_pdf, add_barcode_to_pdf) by focusing solely on margin manipulation, leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it specifies the input (local PDF path) and the optional nature of margins, implying when to use this tool (when PDF margins need adjustment). However, it does not explicitly mention alternatives or exclusions, though the sibling tools are sufficiently distinct to avoid confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the API call, output saving, and that docContent/document.Name are derived from the file. It does not mention authentication, side effects like overwriting, or error conditions, but it provides reasonable insight into the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose and API, followed by key usage caveats and output behavior. Every sentence adds value with no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main workflow but has gaps: it does not explicitly state that invoice_xml_data is required for XML input, invoice_json_data for JSON, etc., nor does it describe the structure of the returned metadata. With 12 parameters and no output schema or annotations, more detail would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 meaningful relationships: it explains that source_pdf_path is used to derive docContent/document.Name for XmlWithPdf mode, and clarifies inputFormat/outputMode options. This goes beyond the schema's per-parameter descriptions, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a ZUGFeRD e-invoice via a specific API endpoint, which is a specific verb+resource action. It distinguishes this tool from sibling tools (none of which mention e-invoice creation) and gives a precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool: for creating ZUGFeRD e-invoices with options for input format, output mode, and conformance level. It also gives a concrete usage requirement for XmlWithPdf (provide source_pdf_path). However, it does not explicitly mention alternatives or exclude other tools, though the specialized nature makes this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses OCR usage, async processing with polling on 202, and the return format (structured_content and text summary). This is useful behavioral context, though it doesn't cover error handling or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence but packed with essential details: API endpoint, OCR, async processing, and return structure. It is efficient and front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no annotations, and no output schema, the description adequately explains the tool's behavior (async/polling) and return content. It could mention file format constraints but those are in the schema, so completeness is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter file_path is fully described in the schema (100% coverage). The description adds only 'local' but not additional detail beyond the schema, so it meets the baseline without adding significant new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts text from a local image using OCR via the PDF4me API. It distinguishes from siblings like extract_text_from_word and read_barcodes_from_image by specifying the image input and OCR capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies 'local image' and OCR, implying appropriate use for extracting text from image files. However, it doesn't explicitly state when not to use it or mention alternatives among the many sibling tools, missing an opportunity for clearer differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the async polling behavior (202 + Location poll), the output file (process_bank_cheque.json), and the specific request body casing requirements. It does not cover error handling or authentication, but provides substantial behavioral context beyond mere inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then provides dense technical details. It is logically structured but slightly long; all sentences contribute value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main operational aspects: async flow, file output, parameter formats, and casing. Given no output schema or annotations, it is quite complete, but lacks explicit mention of output_dir's purpose and the JSON response structure beyond 'full API JSON'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Three of four parameters are explained: pdf_file_path (Base64, accepted formats), doc_name (logical name, optional with default), and custom_field_keys (non-empty list, omitted if unused). However, output_dir is not described, leaving a gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'extract structured data from a bank cheque', using a specific verb and resource. It clearly distinguishes from sibling process_* tools by targeting bank cheques specifically and also references the API endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for bank cheque extraction and warns against confusing its parameter casing with AI-Invoice Parser, but it does not explicitly state when to use this tool vs alternatives or list exclusion criteria. Sibling tools for other document types are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behavior: only docContent/docName/IsAsync are sent, IsAsync must be true, the API returns 202 with a Location to poll, and the result is saved as process_contract.json. It does not cover errors or auth, but the core async behavior and side effect are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and informative, front-loading the purpose and then giving params and async flow. There is minor redundancy/confusion around 'customFieldKeys or CustomFieldKeys', but overall it is well-structured for a tool with no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 params, no annotations, and no output schema, the description covers the endpoint, the only params it sends, supported input formats, async behavior, and the saved output file. Missing output_dir semantics and return structure keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains pdf_file_path (local file, formats, Base64) and doc_name (logical name, optional, defaults to basename), but says nothing about output_dir. Since schema coverage is 0%, this leaves one of three parameters undocumented, so it is useful but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'extract structured data from a contract via PDF4me POST /api/v2/ProcessContract', which names a specific verb, resource, and target document type. This clearly distinguishes it from sibling process_* tools for invoices, receipts, and bank statements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: this is for contracts, takes a local file path, and uses an async polling flow. However, it does not explicitly say when not to use it or name alternatives like process_universal_document, so it misses the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though no annotations are provided, the description discloses key behavioral traits: the operation is asynchronous ('202 + Location poll'), it 'saves process_mortgage_document.json' as a side effect, and empty optional fields are omitted. It also warns about API parameter casing ('isAsync' vs 'IsAsync'). It does not cover failure modes or the exact JSON schema of saved output, but this is above-average transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but each sentence provides value, starting with the core purpose. It is well-structured, moving from API endpoint to request body to input specifics and finally async behavior. The note about 'camelCase isAsync (true), not IsAsync' is a minor distraction but adds implementation clarity. No redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and five parameters, the description covers the purpose, API details, input constraints, async workflow, and output file. The main gap is output_dir, which is not explained, but the rest is sufficiently complete to allow correct invocation. The description compensates well for missing structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning to several parameters: pdf_file_path ('local .pdf only, must be a PDF file'), doc_name ('optional (basename)'), document_type ('hint, e.g. loan—omitted when empty'), and custom_field_keys ('PascalCase only when non-empty'). However, output_dir is never mentioned in the description and remains undocumented, leaving a gap for that parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'extract[s] structured data via PDF4me POST /api/v2/ProcessMortgageDocument', naming the specific domain (mortgage documents) and a clear action. This distinguishes it from sibling process_* tools like process_bank_cheque or process_invoice by focusing on a unique document type. The verb 'extract' and resource 'structured data' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear input constraints: 'pdf_file_path (local .pdf only, must be a PDF file)' and notes doc_name is optional basename. However, it does not explicitly compare to alternative tools or state when not to use this tool. With many process_* siblings, naming alternatives would have strengthened this dimension, but the domain-specific context implies usage for mortgage documents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral transparency burden. It discloses that the tool uses an external API and that output can be customized via directory/file name, but it does not disclose whether the original file is modified, whether authentication is required, or what the tool returns. This is a minimal level of disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and includes only essential information. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no annotations and no output schema, the description should at least indicate the outcome (e.g., whether a repaired file is saved and where). It mentions output options but not the return behavior or side effects, leaving a gap in contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers only file_path (33% coverage), but the description adds meaning to all three parameters: explicitly identifies the file path, and clarifies that output_dir and output_file_name are optional with clear roles. This compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Repair a damaged or problematic PDF' using a specific API. This is a specific verb+resource pairing that distinguishes it from sibling tools like compress_pdf or linearize_pdf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying when to use it (for damaged or problematic PDFs) and how to invoke it (provide local file path, optionally specify output). However, it does not explicitly mention alternatives or exclusionary cases, so it stops short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool saves the resized image to disk, which is an important side effect. However, it does not mention whether it overwrites existing files, what happens if the output directory doesn't exist, supported image formats, or error behavior. With no annotations, these gaps leave behavioral transparency partially incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and about 35 words, front-loaded with the core purpose. Every sentence contributes essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main workflow (path, mode, options, output) but lacks any mention of return values, error handling, or limitations like supported file types or overwrite behavior. Since there is no output schema and no annotations, the description should carry more of this burden to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining that the 'image path' maps to file_path, 'resize mode' to image_resize_type, and 'percentage or width/height' to resize_percentage or width/height. It also clarifies that output directory and file name are optional, which is especially helpful since the schema does not describe those two parameters. This compensates for the 75% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly says 'Resize a local image' with a specific verb and resource, and distinguishes from sibling tools like compress_image or crop_image. It also mentions the API and the two modes (Percentage or Specific), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: provide image path, resize mode, and options. It explains the two modes and optional output settings, but it does not explicitly mention when to use this tool versus alternatives (e.g., compress vs resize) 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It reveals that this is a mutation (removing protection), operates on a local file, and can save output to a different directory/name. However, it does not disclose whether the original file is overwritten, what happens if the password is incorrect, or any rate limits/API nuances. These gaps prevent a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: three short sentences that front-load the primary purpose, then specify required and optional inputs. Every sentence contributes value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description covers the core operation and parameter roles, but lacks important context such as return value, error handling, whether the original file is overwritten, and any API-specific constraints. It is adequate for a simple operation but has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only file_path and password have descriptions). The description compensates by narratively explaining all four parameters: 'Provide the file path and the current open password. Optionally specify output directory and file name.' This adds meaning for the two undocumented optional parameters (output_dir and output_file_name), clarifying their purpose and optionality, though it does not provide detailed constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Remove password protection from a local PDF using the PDF4me Unlock API.' The verb 'Remove' and resource 'password protection from a local PDF' are specific, and it distinguishes from siblings like protect_pdf. The mention of 'local PDF' adds necessary scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: you need a local password-protected PDF and the current open password. It also indicates optional output parameters. However, it does not explicitly state when not to use it or mention alternatives (e.g., protect_pdf for adding passwords), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool calls a POST endpoint, requires a local pdf_file_path, and writes output next to the source file. However, it does not state whether the original file is preserved, what the return value is, or any error/rate-limit behavior, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and then provides a necessary deep-dive into page_number_format, which justifies its length. Each sentence adds value, though the API endpoint detail is somewhat redundant given the tool's name and could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter tool with no annotations or output schema, the description covers the key aspects: purpose, format syntax, parameter constraints, and output location. The main gaps are explicit return-value documentation and error handling, but the guidance provided is substantial and sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes all 13 parameters, but the description adds crucial non-obvious semantics: the literal meaning of '#' and '{1}' in page_number_format, with concrete rendering examples ('# of {1}' -> '1 of 10'). It also gives explicit ranges for margin and font size, going well beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Add page numbers to a PDF via PDF4me POST /api/v2/AddPageNumber.' It clearly distinguishes this tool from siblings like add_text_stamp_to_pdf or add_html_header_footer_to_pdf by focusing on page numbering and naming the exact API endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description frames the context ('Add page numbers to a PDF') and provides direct guidance on how to prepare the page_number_format parameter, which is essential for correct use. It does not explicitly name alternative tools or exclusion conditions, but the operational guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full safety and side-effect burden. It clearly states that the tool writes one file per page to output_dir (defaulting to the input directory), and explains the nuanced page-selection behavior (top-level pageNrs vs imageAction.PageSelection.PageNrs). This goes beyond the schema and adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying unique information: API identity, controllable parameters, and output behavior. No redundant loops over the schema descriptions. It is dense but well-structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 params, no output schema, and no annotations, the description covers the core behavior (output files, default dir) and the most complex parameter interaction (page selection). It does not explain return values, but since there is no output schema, this is not required. It might benefit from a mention of overwriting behavior, but overall it is sufficiently complete for a conversion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% and the schema already describes each parameter, but the description adds important cross-parameter semantics: it explains how page_number maps to both top-level pageNrs and imageAction.PageSelection.PageNrs, and the special 'all' behavior. It also clarifies that width_pixel and image_extension map to imageAction fields, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Render PDF pages to image files', which clearly distinguishes this tool from siblings like convert_pdf_to_word or extract_pages_from_pdf. It also names the exact PDF4me API endpoint, leaving no ambiguity about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (you can create images from PDF pages), but it does not explicitly state when to use this tool versus alternatives like convert_pdf_to_pdfa or extract_pages_from_pdf. No exclusions or alternative recommendations are given, so it remains at an 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to lean on, the description discloses key behavioral details: pdf_file_path is used to read the source PDF and convert it to base64, document_name overrides the default file basename, output defaults to 'swiss_qr_bill.pdf' saved next to the source unless output_dir is set, and isAsync/202 polling is available. It doesn't cover error handling or return values, but it provides substantial transparency for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, leading with the purpose in the first sentence and then covering required inputs, enums, defaults, and output behavior in a compact format. The mention of 'required inputs per OpenAPI' adds some complexity, but every sentence provides useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 27-parameter tool with no annotations or output schema, the description covers a lot: input mapping, enums, output naming, and async option. However, there are gaps: the meaning of isAsync/202 polling is unclear, the 'required inputs per OpenAPI' list conflicts with the schema's required fields, and no return value or error behavior is described. It's functional but leaves room for confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 27 parameters with 0% description coverage, so the description must compensate. It maps backend-required inputs (docContent, document.Name) to actual schema fields (pdf_file_path, document_name), lists enums for address, currency, language, referenceType, and separatorLine, and clarifies that all other fields are optional. However, it does not explain obscure fields like av1_parameters, av2_parameters, billing_info, or unstructured_message, so it only partially bridges the parameter gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create the Swiss QR bill payment part on a PDF using the PDF4me CreateSwissQrBill API.' It also names the specific endpoint and distinguishes itself from sibling tools like read_swiss_qr_bill and split_pdf_by_swiss_qr, making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for creating Swiss QR bill content on a PDF, which directly implies when to use it. It doesn't explicitly list alternative tools or exclusions, but the purpose statement is explicit enough to guide selection, and details like the API endpoint and optional async behavior add operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and adds value by disclosing the underlying API endpoint, support for async polling on 202, and how outputs are saved from outputDocuments[].streamFile. This reveals non-obvious behavior beyond the name, though it does not cover all possible side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words, front-loading the purpose and then providing essential technical details about the API and async behavior. It is appropriately concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, async API, no output schema), the description covers the API endpoint, async polling, and output saving mechanism, which is valuable context beyond the schema. It does not explicitly address return values, but the lack of an output schema makes that less critical. Slightly more detail on data input options would be helpful, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add specific parameter semantics beyond the schema, only broadly mentioning 'template and data'. Thus it neither enhances nor detracts from the schema's already complete parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Generate multiple documents from one template and data using PDF4me GenerateDocumentMultiple API'. This is a specific verb+resource statement that distinguishes it from siblings like generate_document_single by specifying 'multiple documents'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by indicating this tool is for generating multiple documents from a template, which implicitly differentiates it from generate_document_single. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses async behavior (202 + Location poll until JSON), the side effect of saving JSON to process_invoice.json, and the returned key fields. It also notes that empty custom_field_keys are omitted. It does not cover failure modes or rate limits, but core behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: each sentence adds essential information—purpose, async flow, parameter usage, and output behavior. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-param tool with no annotations or output schema, the description covers input handling, async polling, file output, and return fields. The missing output_dir parameter and lack of error-handling details keep it from being fully complete, but it is sufficiently rich for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains pdf_file_path (accepted file types, Base64 reading), doc_name (optional, defaults to basename), and custom_field_keys (omit when no custom keys). However, output_dir is completely undocumented while schema coverage is 0%, leaving one of four parameters without semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'extract structured invoice data from a document' and names the exact PDF4me endpoint. This clearly distinguishes it from sibling tools like process_receipt and process_universal_document by focusing on invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear operational context: when extracting invoice data, supply pdf_file_path, with optional doc_name and custom_field_keys. It does not explicitly name alternatives or exclusion criteria, but the invoice-specific scope makes usage clear; slight deduction for no 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does mention 'Uses isAsync with 202 Location polling' and 'Saves the modified Word file to disk', which are useful traits. Yet it omits potential side effects, error handling, or whether the original file is overwritten, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and around 50 words. It front-loads the primary action, then lists the key parameters, and touches on async and output behavior. Every sentence adds necessary context with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, async behavior, no output schema), the description covers the core flow: input files, search text, pages, first-page skip, async polling, and output saving. However, it does not explicitly mention how output_dir/output_file_name control where and what the saved file is named, which is a minor gap for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes most parameters (71% coverage), and the description adds value by providing an example for PageNumbers ('e.g. 1 or 1,2') and rephrasing 'is_first_page_skip' as 'optional first-page skip'. This helps clarify usage beyond the schema, though it does not compensate for the undocumented output_dir/output_file_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Replace placeholder text in a Word document with an image', clearly distinguishing this from siblings like 'replace_text_with_image' which target other formats. It also names the exact API endpoint, leaving no ambiguity about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes the tool's context: it's for Word documents (.docx/.doc), which distinguishes it from PDF-focused siblings. However, it does not explicitly state when not to use it or name alternative tools for scenarios like PDFs, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that the tool returns structured metadata JSON including image properties and available EXIF details, implying a read-only operation. It does not explicitly state side-effect-free behavior, but the extract/return language makes it clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no redundant information. Every phrase earns its place, specifying input and output in a compact manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description adequately explains what the tool does, what input is required, and what the return format is. There are no critical gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters clearly. The description mentions 'file path' and 'JPG or PNG' which aligns with the schema but adds no significant beyond-schema meaning. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts metadata from a local image, with a specific verb ('Extract') and resource ('metadata from a local image'). It distinguishes itself from siblings like get_pdf_metadata by specifying JPG/PNG images and EXIF details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by instructing the user to provide a file path to a JPG or PNG image. However, it does not explicitly mention when to use this tool versus alternatives like get_pdf_metadata, though the image-specific scope is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verbs 'extract' and 'returns' strongly imply a read-only operation with no side effects. It also discloses the kind of metadata returned, adding transparency. However, it does not explicitly state that the PDF is not modified, though this is a reasonable inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the action and resource. Every sentence contributes useful information without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, the description adequately sets expectations by listing the types of metadata returned (title, author, page count, size, dates, security properties). It is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents file_path with 100% coverage, providing a full description ('Local path to the PDF file'). The description's 'Provide the file path to the PDF' adds no additional semantic meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Extract metadata'), the resource ('a local PDF'), and the expected output (title, author, page count, etc.). It distinguishes from sibling tools by focusing specifically on PDF metadata, unlike PDF modification or extraction tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 you need metadata from a local PDF. It provides clear context but does not explicitly contrast with alternatives like get_image_metadata or mention when not to use it. No exclusions are given, but the PDF-specific focus is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses key behavioral aspects: the API call is asynchronous (isAsync: true, 202 + Location poll), it saves output to process_shipping_label.json, and it explains docName resolution logic. It does not mention auth or error handling, but it provides substantial behavioral context beyond what structured fields offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that efficiently packs the endpoint, request body, parameter rules, and asynchronous behavior. While it could benefit from bullet points for readability, every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must cover the essentials. It does: purpose, API endpoint, parameter semantics, async flow, and output file location. This is sufficient for an agent to invoke the tool correctly, though it does not describe the content of the resulting JSON, which is acceptable given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for its 4 parameters, so the description must compensate. It explains doc_name resolution (uses doc_name if set, else file basename), profiles formatting (trim, omit if empty, wrap in outer braces), and pdf_file_path extensions. output_dir is not explicitly addressed, but its purpose is inferable from the output file mention.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'extract structured data via PDF4me POST /api/v2/ProcessShippingLabel' from a shipping label. It uses a specific verb and noun, and distinguishes itself from sibling process_* tools by explicitly naming the document type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for shipping label extraction) and provides concrete usage constraints such as requiring a local pdf_file_path with specific extensions (.pdf/.png/.jpg/.jpeg). It does not explicitly mention alternatives, but the context is unambiguous as this is the only shipping-label-specific extraction tool among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the operation is a read (implying non-destructive), mentions the PDF4me API (suggesting external processing), and discloses the output format as structured JSON. This gives sufficient behavioral transparency for a simple read tool, though it omits details like file permissions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with purpose stated first and parameter + output in the second. Every word earns its place; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 required parameter, no output schema, no annotations). The description covers the purpose, the required input, and the return format, making it complete for the agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes file_path as 'Local path to the PDF file' (100% coverage). The description merely repeats this instruction without adding extra constraints, formats, or examples, so it adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and identifies the exact resource ('Swiss QR bill data from a local PDF'), also naming the underlying API. This clearly differentiates it from sibling tools like create_swiss_qr_bill or split_pdf_by_swiss_qr.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the primary use case obvious: extracting Swiss QR bill data from a PDF. It provides clear context but does not explicitly mention when not to use the tool or suggest alternatives, which keeps it just below an explicit 'when/when-not' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well by disclosing the async processing behavior (isAsync true, polling on HTTP 202) and the JSON return format. It does not cover errors or permissions, but the key behavioral traits are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: three sentences cover purpose, inputs, and behavior without fluff. Every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with only 3 parameters and no output schema. The description covers the async workflow, return format, and inputs, making it sufficient for most use cases. Missing detail on error handling is a minor gap, but the description is complete enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 value with example barcode types (all, qrCode, dataMatrix, code128) and reiterates the required inputs, which helps the agent construct valid calls beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads barcodes and QR codes from a local PDF, which is a specific verb+resource combination. It also distinguishes itself from the sibling tool read_barcodes_from_image by explicitly noting the PDF input source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this tool is for PDF barcode reading, which gives strong context. However, it does not explicitly mention when not to use it or point to alternatives like read_barcodes_from_image for image inputs, so it falls short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses the API endpoint, camelCase JSON field naming, isAsync=true behavior, async polling via '202 + Location poll', output file name, and nuanced handling of custom_field_keys, custom_field_keys_csv, and profiles. This is rich behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but not bloated; it front-loads the purpose and then provides necessary technical details. It is a single long paragraph rather than structured bullets, which hurts readability slightly, but every sentence adds valuable information. It earns a 4 rather than a 5 due to the lack of visual structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, no output schema), the description covers most critical context: endpoint, file types, API field naming, async behavior, custom field handling, and saved output. The main gap is the missing output_dir parameter, which is relevant for controlling where process_bank_statement.json is saved. Overall, it is fairly complete but not fully exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It explains most parameters in depth: pdf_file_path accepted formats, doc_name default behavior, bank_name optional omission, custom_field_keys/csv merging and dedup, analyze_patterns default true, and profiles wrapping logic. However, output_dir is entirely omitted from the description, leaving its purpose and usage ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'AI-Process Bank Statement (processBankStatement): extract structured data via PDF4me POST /api/v2/ProcessBankStatement', using a specific verb, resource, and endpoint. It clearly distinguishes itself from sibling process_* tools by naming bank statements as the target document type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the context clear: this tool processes bank statements, which differentiates it from process_invoice, process_receipt, and other sibling document processors. However, it does not explicitly state when not to use it or list alternative tools for other document types, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses async polling with 202 + Location, required IsAsync=true, conditional omission of CustomFieldKeys, and the .png extension fallback. This is substantial behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with purpose; every clause conveys required information. It is somewhat run-on, but economical for the amount of technical detail provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description covers the endpoint, async semantics, file type constraints, naming behavior, and result file. This is sufficient for an agent to invoke it correctly, with only the minor omission of output_dir.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description details pdf_file_path accepted file types and Base64 encoding, doc_name defaults and extension behavior, and custom_field_keys conditional inclusion/PascalCase. The only omitted parameter is output_dir, so this is not a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'extract structured data from a credit card image/PDF', and names the PDF4me endpoint. This clearly differentiates it from sibling tools like process_receipt and process_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It defines the exact input domain (credit card image/PDF) and conditions for custom_field_keys, giving clear context for when to use the tool. It does not explicitly mention alternative tools or when not to use it, so it misses a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It reveals that the operation is asynchronous (IsAsync true, 202 + Location poll), that VerifyAuthenticity and CustomFieldKeys are conditionally included, that the output is saved to process_marriage_certificate.json, and that names without extensions get .pdf. This goes well beyond the schema and provides essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused paragraph. Each sentence adds distinct information: the API endpoint, base body, conditional fields, file input requirements, and the output behavior. There is no wasted wording, and the most important purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and any schema property descriptions, the description is quite complete. It covers the input requirements, conditional parameters, async polling, and output file. The only notable omission is the output_dir parameter, which is not explained. But for a tool with this complexity, the description provides enough operational detail 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains pdf_file_path (local file types), doc_name (optional, basename, extension default), verify_authenticity (only sent when true), and custom_field_keys (only when non-empty, PascalCase). However, output_dir is not mentioned at all, leaving a gap for one of the five parameters. Overall, it adds meaningful semantics to most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'extract structured data via PDF4me POST /api/v2/ProcessMarriageCertificate.' It identifies the specific resource (marriage certificate) and the action (process/extract), which distinguishes it from sibling tools like process_invoice or process_bank_cheque. The tool name and description align perfectly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: it requires a local pdf_file_path, explains that doc_name is optional and defaults to .pdf, and describes the async flow (202 + Location poll). However, it does not explicitly mention alternatives or when not to use it, though the specialized name implies its use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so excellently. It reveals exact docName handling (trimmed, default fallback, never replaced by local basename), isAsync=true, taxModel omission rules, customFieldKeys camelCase merging, profiles sanitization, polling behavior on 202 + Location, and the output file name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and packed with essential operational details in a single paragraph. It is front-loaded with purpose and then flows through request body, parameters, and output. While a bit run-on, every clause adds value and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, no output schema, no annotations), the description provides a remarkably complete picture: request construction, parameter semantics, file input requirements, polling behavior, and output artifact. The only minor omission is explicit output_dir semantics, but overall it is fully sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must document parameters itself. It thoroughly explains doc_name, tax_model with examples, custom_field_keys/CSV merging, profiles, and pdf_file_path formats. However, output_dir is not explicitly described, and 'profiles (sanitized)' is vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('extract structured tax data') and resource (PDF4me POST /api/v2/ProcessTaxDocument), and is unambiguous about its tax-document scope. This distinguishes it from sibling tools like process_invoice or process_contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this is for tax documents by naming tax_model examples and describing the extraction workflow. However, it does not explicitly mention when not to use it or point to alternative tools for other document types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pdf4me-mcp MCP server](https://glama.ai/mcp/servers/pdf4me/pdf4me-mcp/badges/card.svg)](https://glama.ai/mcp/servers/pdf4me/pdf4me-mcp)

Score Badge

Copy to your README.md:

[![pdf4me-mcp MCP server](https://glama.ai/mcp/servers/pdf4me/pdf4me-mcp/badges/score.svg)](https://glama.ai/mcp/servers/pdf4me/pdf4me-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pdf4me/pdf4me-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server