PDF.co MCP Server

Official

by pdfdotco

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.0
Disambiguation4/5
Most tools have clearly distinct purposes, especially the conversion tools which are differentiated by output format. However, some overlap exists: document_to_pdf covers many of the same inputs as csv_to_pdf and image_to_pdf, and fill_forms overlaps with the fields functionality in pdf_add_annotations_images_fields. These are minor ambiguities that descriptions mostly resolve.
Naming Consistency4/5
The naming is largely consistent, with conversion tools following a clear `source_to_target` pattern (e.g., pdf_to_json, excel_to_csv). Many operation tools use a verb_noun or object_verb pattern, but there are deviations like `read_pdf_forms_info` vs `pdf_info_reader` and the long compound name `pdf_add_annotations_images_fields`. Overall, the conventions are readable and predictable, with only minor inconsistencies.
Tool Count2/5
With 38 tools, the server exceeds the recommended range for a well-scoped MCP server. While the broad domain of PDF processing may justify many operations, the count feels heavy and includes some redundancy (e.g., document_to_pdf overlaps with csv_to_pdf and image_to_pdf). The set could be consolidated to reduce cognitive load.
Completeness3/5
The tool set covers major PDF workflows: conversion to/from many formats, forms creation and filling, text extraction, OCR, and password protection. However, there are notable gaps, such as no page-level editing (rotate, delete, reorder), no attachment management beyond extraction, and no form flattening or digital signature capabilities. These omissions could cause dead ends for some agents.
Average 3.3/5 across 38 of 38 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on July 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states a generic conversion action and omits critical behavioral traits such as asynchronous execution (evidenced by sibling wait_job_completion), how multiple files are handled, or any authorization requirements beyond the api_key parameter. No side effects or constraints are disclosed.
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 core description is a single, front-loaded sentence that is clear and efficient. The appended reference link provides optional documentation but is not directly actionable for an AI agent; however, it is not verbose enough to hurt the overall 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?
For a 6-parameter tool with no annotations and no output schema, the description is too sparse. It fails to mention important operational details like whether the conversion is asynchronous, whether multiple images are merged into one PDF, or what the return value looks like. The basic purpose is clear, but the overall context 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 description coverage is 100% with detailed parameter descriptions. The tool description adds no unique parameter insights; it merely restates the formats that align with the url parameter. Baseline of 3 is appropriate since the schema carries the semantic weight.
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' and clearly identifies the resource 'image formats (JPG, PNG, TIFF) to PDF', which directly distinguishes it from sibling conversion tools like document_to_pdf or pdf_to_image. The format list narrows scope effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 alternatives such as document_to_pdf or html_to_pdf. The description lacks any scenario-based context or exclusions, leaving the agent to infer usage solely from the tool name.
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 fails to disclose blocking behavior, polling mechanism, timeout handling, or return value. It only states the obvious.
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?
Single sentence is concise but lacks critical information like blocking behavior. It is not optimally informative for an agent.
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?
Description lacks details on return format, polling behavior, error handling, and effect of interval/timeout, leaving significant gaps for a 4-parameter 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?
Input schema has 100% coverage; description adds no extra meaning. Baseline score applies.
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 tool waits for job completion, but it doesn't differentiate from the sibling 'get_job_check' which likely checks status once.
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 like 'get_job_check'. The description does not provide any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 does not mention API key requirements, network access, file size limits, or any side effects. The statement is purely declarative and provides no insight into how the conversion is performed or what the agent should expect.
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 brief and front-loaded, immediately stating the core purpose. The reference link is a minor addition that does not add significant clutter. However, it could be structured to include essential usage hints without sacrificing conciseness.
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 lack of annotations and output schema, the description is insufficient for an agent to fully understand the tool's behavior, return values, or how to handle authentication and file access. The schema descriptions partially compensate, but the overall context is incomplete for a conversion tool with 7 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 100%, so the parameters are already well-documented. The description adds minimal value by naming the input formats (CSV, XLS, XLSX), which is already reflected in the 'url' parameter description. No additional syntax or nuance is provided 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 a specific action ('Convert') with a defined input resource ('CSV or spreadsheet files (XLS, XLSX)') and output ('to PDF'). This distinguishes it from siblings like pdf_to_csv or document_to_pdf, which have different input/output orientations.
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 about when to use this tool versus alternatives such as excel_to_pdf or document_to_pdf. The description merely states the function without any context for selection, prerequisites, or 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, the description carries full burden, but it only states the conversion outcome. It doesn't disclose behavioral traits such as requiring API keys, handling authentication, or returning a file. The reference link is not part of the description narrative.
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 with a useful reference link. It is front-loaded and efficient, though slightly under-specified in other dimensions.
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 simple conversion tool and lack of output schema or annotations, the description is sparse. It doesn't explain output format details, potential prerequisites, or behavior, making it incomplete for robust agent understanding.
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?
All 6 parameters have descriptive schemas with 100% coverage. The description itself adds no parameter information, so the baseline of 3 applies.
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 tool converts Excel files (XLS, XLSX) to TXT format, using a specific verb and resource. It distinguishes from sibling conversion tools by naming the exact output format, though it doesn't reference alternative tools for different formats.
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 alternatives like excel_to_csv or pdf_to_text. The description simply states the conversion without any context for 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 carries the full burden. It fails to disclose any behavioral traits such as authentication requirements, success/failure responses, rate limits, or side effects. The description is too brief to guide safe invocation.
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 with no wasted words, which is efficient. However, it could be slightly expanded to include essential context without becoming verbose. It is appropriately sized but lacks structure for additional guidance.
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 that there is no output schema and no annotations, the description should explain what the tool returns (e.g., a URL or job ID). It does not, leaving the agent without critical information for using the result. The description is incomplete for the tool's role as an upload step.
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 input schema has 100% description coverage, so the schema already documents both parameters (file_path and api_key). The description adds no extra meaning beyond the schema, but it is not necessary. A score of 3 is appropriate as the schema does the heavy lifting.
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 (upload) and the target (file to PDF.co API), providing a specific verb and resource. However, it lacks mention of what the upload accomplishes or returns, which could help differentiate it further from sibling tools that also involve file input.
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, such as prerequisites (e.g., must be used before processing tools like pdf_merge) or context like file size limits. The description does not help an agent decide to select this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. However, it only states the basic conversion fact and does not disclose that this is an API-based operation requiring authentication (as hinted by the api_key parameter), potential rate limits, side effects, or handling of temporary files. The reference link is not part of the behavioral description and provides no in-tool transparency.
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 sentence with no unnecessary words, front-loading the core function. It also includes a reference link for further documentation, adding value without bloat. Perfectly concise and well-structured for its 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?
The tool has six parameters, no output schema, and no annotations, yet the description only states the basic conversion. It omits mention of authentication, worksheet selection, when to use the http username/password parameters, or the fact that a URL must be accessible. This is insufficient for a tool of this complexity; a minimal viable description would at least hint at these operational aspects.
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 all six parameters already have descriptive titles and descriptions in the schema. The description adds no additional parameter semantics, which aligns with the baseline score of 3 for high schema coverage. It does not introduce new meaning or clarify usage edge cases beyond what the schema provides.
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 'Convert Excel(XLS, XLSX) to CSV' clearly states the action, input format, and output format. It distinguishes this tool from sibling tools like excel_to_json and excel_to_pdf by explicitly naming CSV as the target format, 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 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. It does not mention conditions, prerequisites, or exclusions, and offers no comparison with sibling tools such as excel_to_xml or excel_to_html. The agent is left to infer usage solely from the name.
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 offers valuable detail on header/footer placeholders but omits return format, authentication requirements, async behavior, or any side effects, leaving major behavioral unknowns.
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 well-structured with a clear opening, a reference link, and a focused breakdown of header/footer capabilities. The example is concise and helpful. No unnecessary 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?
As a conversion tool with no output schema and no annotations, the description lacks essential contextual information: what is returned (PDF binary/link), whether this is asynchronous, and how it differs from webpage_to_pdf for URL inputs. It covers only header/footer semantics.
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%, meeting the baseline of 3. The description adds substantial extra semantics for the header and footer parameters with usable classes, img support, and a concrete example, which goes beyond schema descriptions.
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 (Convert HTML to PDF) and resource (HTML input). It is distinctive by name and matches the tool, but it doesn't explicitly contrast with sibling tools like webpage_to_pdf or document_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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The main description gives no guidance on when to use this tool versus siblings. While the schema for the html parameter hints at using a different endpoint for links, the tool description itself lacks this context or any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral details are disclosed beyond the basic operation. The description does not mention output format, asynchronous processing, error handling, or authentication nuances. Since no annotations are provided, the description carries the full burden for transparency and fails to meet it.
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 appropriately concise at two sentences. The reference link adds little actionable value for an AI agent and could be omitted, but the text is otherwise free of fluff and front-loads the core purpose.
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 must explain what the tool returns or how to interpret results. It does not, leaving significant gaps about output format, error behavior, and usage nuances. The description is too minimal for a tool that lacks structured return 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 input schema already provides descriptions for both parameters (url and api_key) with 100% coverage, so the description adds no additional parameter semantics. The baseline of 3 applies because the schema handles parameter documentation effectively.
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 ('Extracts'), resource ('data from invoices'), and method ('using AI'). This distinguishes it from sibling tools like pdf_to_json or pdf_to_csv, which are generic converters and not invoice-specific.
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 context is implied by the tool name and purpose—use when invoice data extraction is needed—but there is no explicit guidance on when to use it versus alternatives, nor any 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 present, so the description carries the full burden of behavioral disclosure. It only says 'Convert email to PDF' and provides a reference link, without explaining whether it fetches remote URLs, how attachments are handled, authentication needs, or what the response looks like. This is a significant transparency gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the core action. The reference link is arguably not useful for an AI agent, but it does not add significant clutter. Overall, it is appropriately concise, though it lacks the structured context that would make it more valuable.
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 7 parameters and no output schema, yet the description does not explain what the tool returns (e.g., a PDF link, job ID) or how it fits into workflows with siblings like wait_job_completion. It also does not mention the upload_file prerequisite for local files, which is only found in the url parameter description. With no annotations or output schema, the description 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 description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning beyond the schema; all useful semantics are in the schema itself (e.g., URL sources, margins, paperSize, embedAttachments). The reference link does not contribute 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 clearly states the tool's function with a specific verb and resource: 'Convert email to PDF.' This distinguishes it from sibling conversion tools like webpage_to_pdf, html_to_pdf, and document_to_pdf. No ambiguity about what the tool does.
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, no prerequisites, and no exclusions. Sibling tools like document_to_pdf or webpage_to_pdf exist, but the description does not mention how to choose between them. Schema parameter descriptions offer some context (e.g., URL sources, upload_file), but the description itself carries no usage direction.
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 behavioral disclosure burden. It merely states the conversion without addressing important behaviors like asynchronous job handling, authentication requirements, or worksheet selection defaults.
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 core purpose. The reference link adds a minor extra element but doesn't detract from the concise 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 lacks an output schema and annotations, so the description must compensate. It fails to mention that this may initiate an asynchronous job, or what the response shape is, leaving critical context missing 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented. The description itself adds no parameter details beyond what the schema already provides, resulting in the baseline score of 3.
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 Excel (XLS, XLSX) files to JSON. This specific verb+resource+output combination distinguishes it from sibling tools like excel_to_csv or pdf_to_json.
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 guidance on when to use this tool or alternatives. It simply states the conversion action with no mention of prerequisites, typical scenarios, or comparison to other Excel conversion 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Convert' without revealing whether the operation is synchronous, requires authentication beyond api_key, handles large files, or returns a downloadable URL. The lack of any behavioral context beyond the basic conversion 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the main purpose and includes a reference link for further details. It is appropriately sized with no filler, though it arguably sacrifices useful detail for brevity.
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 6 parameters, no output schema, and no annotations, the description should explain return values or operational details. It does not mention what the tool returns (e.g., a PDF URL or job ID), nor does it describe required permissions or rate limits. The reference link is not a substitute for inline context. This is incomplete for an agent to confidently invoke and handle the result.
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 input schema has 100% coverage with descriptions for all six parameters, so the baseline is 3 even though the tool description adds no parameter-level detail. The schema already explains each parameter's purpose, and the description does not need to compensate. No extra semantic value is provided by the description.
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 tool converts Excel (XLS, XLSX) to PDF, with a specific verb and resource. It does not explicitly distinguish from sibling conversion tools like excel_to_csv or excel_to_json, but the output format (PDF) is inherently clear. It is not a tautology and provides enough clarity for basic selection.
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 PDF output is desired from Excel files, but it does not state when not to use it or mention alternatives. There is no explicit guidance on prerequisites (e.g., file accessibility) or comparisons with sibling tools. The reference link provides external info but is not part of the description's guidance.
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 does not mention that this is a read-only operation, potential API key requirements, rate limits, or what the output looks like. The operation 'extract' could imply file downloads, but side effects are not clarified.
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 very concise, with a single sentence plus a reference URL. It is front-loaded and wastes no words. It could be slightly more informative but remains appropriately short for a straightforward tool.
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 annotations and no output schema, so the description must compensate. It does not explain the return format, whether attachments are downloaded or referenced, or any error/edge-case behavior. This is inadequate for a tool that may return variable types of extracted data.
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 description coverage is 100%, so the parameters are already well-documented. The description adds no additional meaning to the parameters, but the baseline of 3 is appropriate because the schema handles the 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 tool's function: 'Extracts attachments from a source PDF file.' It uses a specific verb and resource, and is distinct from sibling tools like pdf_merge or pdf_split, 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 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, prerequisites, or alternatives. It simply states the action without context on when it is appropriate compared to other 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?
No annotations are provided, so the description carries the full burden. It only states the core action without disclosing side effects, permissions, output behavior, or whether the original file is modified. It does not contradict any annotations.
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 highly concise, with one sentence and a reference link. It is front-loaded but may be too minimal to be fully self-sufficient, though the link provides external context.
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?
No output schema or annotations exist, and the description does not explain the return value, file handling, or processing steps. The agent is left without crucial context about what happens after the password is removed.
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 adds no additional meaning beyond the schema's parameter descriptions; it does not compensate for anything missing.
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 'Remove password protection from a PDF file', using a specific verb and resource. It distinguishes itself from the sibling tool pdf_add_password, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. There is no mention of prerequisites, exclusions, or related tools, leaving the agent to infer usage solely from the name and the action described.
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, but it only states the core action. It does not mention that this is a cloud API operation, whether it creates output files asynchronously, requires an API key, or any side effects. The reference link hints at external details but is not inlined, leaving the agent without key context.
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 and front-loaded, with a single clear sentence followed by a reference link. It avoids unnecessary fluff, though the reference link could be considered extraneous but is harmless. The structure effectively conveys the primary purpose.
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 and no annotations, and the description only covers the basic split action. It fails to explain how output files are returned or stored, whether the operation is synchronous, or any job-related behavior that might be inferred from sibling tools like wait_job_completion. This leaves the agent with significant uncertainty about the workflow.
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 input schema already provides 100% coverage of all 7 parameters with detailed descriptions, including examples for the 'pages' parameter. The description adds no extra parameter information beyond restating the split method, so it neither enhances nor detracts from the schema's baseline.
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 'Split' and clearly identifies the resource 'a PDF' and the outcome 'multiple PDF files'. It also specifies the method 'using page indexes or page ranges', which distinguishes it from sibling tools like pdf_merge or pdf_to_text.
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 does not state when to use this tool versus alternatives, nor does it mention any prerequisites or conditions. While the purpose is obvious, there is no explicit guidance on replacement scenarios or exclusions, which is missing for a tool with many PDF-related siblings.
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 full responsibility for behavioral disclosure. However, it only says 'Convert PDF and scanned images into CSV representation' and does not explain how the conversion works, whether it is asynchronous, any performance implications, or output handling. The brief reference link is not a substitute for in-description 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 concise and front-loaded, stating the core purpose in one sentence and including a reference link. It avoids fluff but could be more structured with additional details. Still, it is appropriately sized for conveying the basic function.
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 (11 parameters, no output schema, sibling tools like wait_job_completion and get_job_check suggesting an asynchronous job model), the description is incomplete. It fails to mention job-based behavior, return values, or any needed follow-up steps, leaving the agent without sufficient context to use 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 input schema has 100% parameter description coverage, with detailed explanations for each of the 11 parameters (e.g., pages, rect, unwrap, line_grouping). The tool description itself adds no parameter-specific info, but the schema already does the heavy lifting, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 PDF and scanned images into CSV representation with layout, columns, rows, and tables. It specifies the verb 'convert', the resource (PDF/scanned images), and the output format (CSV), distinguishing it from sibling tools like pdf_to_json and pdf_to_text.
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 explicit guidance on when to use this tool versus alternatives. It does not mention any preconditions, exclusions, or alternative tools for other output formats. The only clue is the tool name and CSV output implication, but this is not clearly stated as usage guidance.
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 only states the conversion action and lists formats but does not disclose whether the operation is synchronous or asynchronous, how results are retrieved, any authentication requirements beyond the schema, or other side effects. The reference link is not a substitute for behavioral detail.
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—two sentences—and front-loaded with the core action. The reference link is arguably useful for deeper documentation but adds slight noise. Overall, it is efficient without being under-specified.
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?
Despite having 7 parameters and no output schema or annotations, the description provides minimal context. It does not explain the return value, whether the conversion is asynchronous (suggested by siblings like wait_job_completion), or any prerequisites beyond the URL. This leaves significant gaps for an agent to know how to use the tool effectively.
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 provides 100% coverage for all parameters, so the baseline is 3. The description adds meaningful value by expanding the supported file types in the 'url' parameter beyond what the schema lists (e.g., adding XLS, JPG, CSV, etc.), thereby enriching the understanding of the most important parameter.
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 tool converts various document types into PDF and explicitly lists the supported formats, which gives a specific verb and resource. However, it does not explicitly differentiate itself from sibling tools like csv_to_pdf or image_to_pdf, so it lacks direct 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the listed formats—if you have one of those formats, this tool can convert it. But there is no explicit guidance on when not to use it or mention of alternatives for specific formats (e.g., CSV to PDF, image to PDF), which would have made the guidance clearer.
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 carry the behavioral transparency burden. It fails to disclose important details like authentication requirements, output format/behavior, or error handling. The simple conversion statement adds no behavioral insight beyond the raw purpose.
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, containing a single sentence with the core purpose and a reference link. Every word contributes value, and the structure is front-loaded for quick comprehension.
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?
Despite full parameter schema coverage, the description lacks contextual completeness. It does not explain the conversion process, expected output, or how results are returned. With no output schema or annotations, these gaps are significant for a tool with six 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?
The input schema provides detailed descriptions for all six parameters, achieving 100% coverage. Since the description itself does not add any parameter-related information, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: converting Excel (XLS, XLSX) files to HTML. This specific verb+resource+format statement distinguishes it from sibling tools that convert to other formats like CSV or 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?
The description offers no guidance on when to use this tool versus alternatives, such as when HTML output is needed or how it compares to excel_to_csv/pdf. It also lacks any mention of prerequisites or use-case 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?
No annotations are provided, so the description must carry the full burden of disclosure. It mentions the tool finds tables and returns coordinates, but does not discuss whether it requires authentication, modifies the source file, or how the coordinates are formatted. The read-only nature is implied but not explicit.
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 the first directly stating the tool's function and the second providing a reference link. Every sentence serves a purpose and there is 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 is relatively simple, but there is no output schema or behavioral disclosure. The description states coordinates are returned but does not describe the structure, which is important for downstream use. The reference link is not a substitute for inline clarity, and no annotations compensate for the lack of safety or side-effect 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 input schema has 100% coverage with detailed descriptions for all parameters. The tool description itself adds no additional parameter context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Find tables in PDF') and a concrete output ('get their coordinates'). This clearly distinguishes it from sibling tools like find_text or pdf_to_csv, 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 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 alternatives, such as when coordinates are needed vs. when extracting table data as CSV is more appropriate. The description implies a use case but does not 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?
With no annotations, the description bears the full burden of behavioral disclosure, but only states the action without explaining side effects, output format, authentication requirements, or whether the operation is asynchronous. The presence of sibling tools like wait_job_completion and get_job_check suggests a job-based workflow, but the description remains silent on this.
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 sentence followed by a reference link. It is extremely concise, front-loaded with the core action, and contains 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?
Given the tool's complexity (17 parameters, no output schema, no annotations), the description is too minimal. It omits critical context such as the return value, the job-based workflow implied by sibling tools, and how to handle the generated output file.
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 all 17 parameters are already described in the schema. The tool description adds no additional parameter semantics beyond the general 'password protection' statement, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 password protection to a PDF file.' It uses a specific verb and resource, and the verb 'Add' explicitly contrasts with the sibling tool 'pdf_remove_password'.
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 usage context is provided beyond the action itself. There is no mention of when to use this tool vs. alternatives, prerequisites, or when not to use it. The description does not differentiate from other PDF manipulation tools like pdf_merge or pdf_remove_password.
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, and the description only states the basic function. It does not disclose OCR behavior, async execution, output format details, or authentication requirements. The external reference link is not part of the description itself.
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 one short sentence plus a reference URL, making it extremely concise and front-loaded. Every word earns its place; the URL provides additional documentation without cluttering the description.
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?
Despite full schema coverage, the description lacks critical context such as whether the operation is asynchronous (sibling wait_job_completion suggests it may be), what the output response looks like, and whether OCR is automatically applied. This is insufficient for a tool with 11 parameters and no output schema.
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 cover all 11 parameters, including URL, OCR language, and page ranges, so the schema carries the semantic burden. The description adds no additional parameter context, but the baseline of 3 is warranted due to full 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 converts PDF and scanned images to HTML format, using a specific verb and resource. This distinguishes it from sibling conversion tools like pdf_to_json or pdf_to_text.
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 pdf_to_text or pdf_to_image, nor any exclusions or prerequisites. The description merely states the function without situational 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 mentions layout preservation but omits key runtime behaviors such as asynchronous processing, API key requirements, output retrieval flow, or limitations for scanned documents.
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: one clear purpose statement and a reference link. It is front-loaded and contains no filler or redundant 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?
The tool has 11 parameters, no output schema, and no annotations, but the description does not explain the overall workflow, return value, or how to retrieve the converted text. Given the complexity, the description is too thin to fully guide an agent.
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 all 11 parameters already have explanatory descriptions. The tool description adds no additional parameter context, but the schema alone provides sufficient 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 tool converts PDFs and scanned images to text, with a specific verb ('Convert') and output resource ('text'). It distinguishes from sibling conversion tools (pdf_to_json, pdf_to_csv, etc.) by naming the target format.
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 does not explicitly state when to use this tool versus alternatives like pdf_to_json or pdf_to_html. There is no mention of exclusions, prerequisites, or scenarios where another converter would be preferred.
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 burden of behavioral disclosure. It does not mention output format, whether authentication is required, or any side effects; it only states a high-level extraction action.
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 concise sentences with no filler. It front-loads the primary purpose and includes a reference link for details.
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 an output schema, the description should clarify what information is returned, but it only says 'information about fillable PDF fields' without specifics. The tool has 5 parameters and no annotations, so the description is too thin for an agent to fully understand usage.
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 has 100% coverage of parameter descriptions, so baseline 3 applies. The description adds no additional meaning beyond the schema's parameter documentation.
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 'Extracts' and specifies the resource as 'information about fillable PDF fields from an input PDF file', clearly distinguishing it from sibling tools like fill_forms or create_fillable_forms.
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. It simply states its function without mentioning scenarios, exclusions, or alternative 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 only states the conversion and provides a documentation link, but does not disclose any behavioral traits such as how the output is returned, handling of multiple worksheets, limitations, or authentication requirements. The description is minimal and leaves significant behavior unstated.
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 extremely concise, containing two short sentences that directly state the purpose and provide a reference link. Every word earns its place, with no unnecessary fluff or repetition. It is appropriately sized for a simple conversion tool.
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 conversion tool with no output schema and no annotations, the description is adequate but has clear gaps. It does not mention what the user receives after conversion (e.g., a download URL or file), whether the operation is synchronous, or how to handle multiple worksheets. The reference link could fill these gaps, but the description itself is incomplete for full situational understanding.
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 input schema descriptions cover 100% of the parameters (url, name, api_key, httppassword, httpusername, worksheetIndex), so the schema already provides full parameter semantics. The description itself adds no additional parameter meaning beyond what the schema documents, which yields the baseline score of 3.
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 'Convert Excel(XLS, XLSX) to XML', providing a specific verb and resource with a clear target output format. This distinguishes it from sibling tools like excel_to_csv or excel_to_json by clearly naming the output as XML.
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 gives no guidance on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or provide comparison to other Excel conversion tools. The reference link may offer usage details, but the description itself lacks any when-to-use guidance.
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 not mention whether the operation is synchronous or asynchronous (sibling wait_job_completion suggests it may return a job ID), what the return value looks like, required authentication (beyond schema), or any rate limits. This is a significant gap for a tool that likely submits a job.
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 core description is a single efficient sentence stating the tool's purpose and accepted input types. The second sentence is a reference link, which is compact but not strictly inline content. 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?
The description is incomplete given the surrounding context. There is no output schema, so the description should explain what the tool returns. The existence of wait_job_completion suggests this tool may return a job ID for asynchronous processing, but the description never mentions this. An agent cannot reliably know how to consume the result without this 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?
Schema description coverage is 100%, so the baseline is 3. The description adds a small extra detail: support for ZIP files containing documents and images, which is not explicitly mentioned in the schema's list of supported types. No other semantic value is added 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 merges multiple file types (PDF, DOC, XLS, images, ZIP) into a new PDF. This specific verb+resource combination distinguishes it from siblings like pdf_split (splitting) and document_to_pdf (single document conversion).
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: use when you need to merge multiple files of various formats into one PDF. However, it does not explicitly state when not to use it or name alternatives (e.g., for converting a single file to PDF, use document_to_pdf instead). The guidance is 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.
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 hints at OCR via 'scanned images' but omits key behaviors such as output file generation, OCR language handling, password/HTTP auth support, page selection, and line grouping. The external references do not compensate for missing inline 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 concise and front-loaded with a clear main sentence, followed by documentation links. While the references are useful, they are not inline guidance, but the overall structure is efficient and free of fluff.
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 complex 12-parameter tool with no annotations and no output schema, yet the description only provides a basic conversion statement plus doc links. It lacks critical context about OCR, page selection, authentication, and expected output, making it insufficient for an agent to fully grasp the tool's capabilities.
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 input schema already describes all 12 parameters with 100% coverage, so the baseline is 3. The description adds no parameter-specific meaning beyond naming the output formats, which are already enumerated in the 'type' choices.
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') and clearly identifies the resource ('PDF and scanned images') and output formats ('JPG, PNG, WebP, TIFF'), which distinguishes it from sibling conversion tools like pdf_to_text and pdf_to_json. The purpose is immediately clear and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when converting PDFs to raster image formats, but it does not explicitly state when to choose this tool over alternatives or mention exclusions. It lacks direct guidance like 'use this for image output rather than pdf_to_text'.
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 only mentions conversion capability, omitting important details such as authentication requirements (API key), potential asynchronous job behavior (suggested by sibling tools like wait_job_completion), or expected output/response format. The reference to scanned images hints at OCR but doesn't explain 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 a single, clear sentence followed by a reference link, making it very concise and front-loaded. No unnecessary words, though the reference link might be more useful in a separate documentation field, but it doesn't detract significantly.
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 11 parameters and no output schema, and the description does not explain the overall workflow (e.g., whether it returns a job ID for asynchronous processing), what the XML output looks like, or preconditions for the source URL. The schema covers parameters, but the description fails to tie together operational context, leaving significant gaps for an agent to correctly invoke and interpret 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?
The schema provides 100% parameter description coverage with detailed explanations for all 11 parameters, so the baseline is 3. The tool description adds no extra parameter-specific information beyond what the schema already provides, so it neither helps nor hurts.
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 ('Convert') with a clear resource ('PDF and scanned images') and target format ('XML'), immediately distinguishing it from sibling tools like pdf_to_json or pdf_to_text. No ambiguity about what the tool does.
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 versus alternatives, nor does it mention exclusions or prerequisites. However, the explicit mention of 'XML format' implies it is the right choice when XML output is needed, providing minimal implicit guidance.
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 must convey behavioral traits, but it only mentions regex support and coordinate output. It does not disclose return format, pagination, error handling, or authentication requirements. The external reference link is useful but not directly embedded, so transparency is limited.
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 extremely concise: two sentences plus a reference link. It front-loads the core purpose and adds a key feature (regex) without redundancy. This is well-structured for a simple tool, though it sacrifices depth for brevity.
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 9 parameters, no annotations, and no output schema, the description is insufficient for complete understanding. It doesn't explain what the coordinates look like, how the tool behaves across pages, or what the response structure is. The schema helps but the description doesn't fill gaps like return values or potential limitations.
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 input schema has 100% coverage, so all parameters are described there. The description adds minimal value beyond the schema—it mentions regex support and coordinate output, but doesn't clarify parameter usage beyond what the schema already states. Baseline 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's function: finding text in a PDF and returning coordinates. It specifies the resource (PDF) and the action (find text), and mentions regex support, which distinguishes it from simple text search. It doesn't explicitly name sibling alternatives like find_table, but the purpose is 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 for locating text strings in PDFs, especially with regex needs. However, it provides no explicit guidance on when to choose this tool over siblings (e.g., find_table) or any exclusions. There is no mention of prerequisites or use cases, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. The use of 'Get' implies a read-only, non-destructive operation, and the list of returned information gives some insight. However, it does not disclose potential side effects, authentication requirements beyond the API key, rate limits, or error behavior. The description is transparent about output scope but not about 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 a single sentence that front-loads the primary purpose and lists key outputs. The reference link is auxiliary and not clutter. Every word contributes to understanding the tool's function, making it highly concise and well-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?
This is a relatively simple read tool with well-described parameters and no output schema. The description provides a clear inventory of what the tool returns, which is sufficient for an agent to select and invoke it. The only missing context is the return format (e.g., JSON structure) and whether any authentication beyond the API key is needed, but these are minor given 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 input schema has 100% description coverage for all 5 parameters, so the schema already documents each parameter's purpose. The description adds no extra semantic value for parameters. This meets the baseline but does not exceed it, as the description does not clarify parameter relationships or provide examples beyond what the schema gives.
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 tool's purpose: to get detailed information about a PDF document, listing specific data types (pages, metadata, security, form fields). This is specific enough to understand the resource and action. However, it does not explicitly differentiate from sibling tools like read_pdf_forms_info, which focuses on form fields specifically.
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. It does not mention that read_pdf_forms_info exists for form-specific extraction, nor does it suggest any preconditions or use cases. The reference link might provide context, but the description itself lacks usage direction.
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 behavioral burden. It reveals the output contents (preserved text, fonts, images, vectors) and the underlying endpoint, but does not disclose whether the call is asynchronous, whether an API key is strictly required, any side effects, or what happens with failures. This leaves critical behavioral gaps 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?
Two sentences, front-loaded with the main action, and includes a reference link for additional detail. No filler or redundant content—every part contributes to understanding the tool's purpose.
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 converter with 11 parameters and no output schema, the description is incomplete. It does not explain the return format or whether the tool returns the JSON directly or a job ID to poll via wait_job_completion, which is essential for correct invocation in this toolset. The high schema coverage helps but cannot compensate for the missing async/return 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?
The schema covers all parameters with descriptions, meeting the >80% threshold, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema; it neither clarifies parameter interactions nor highlights the most important inputs like url or lang.
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 (Convert PDF and scanned images) and the resource/output format (JSON representation with text, fonts, images, vectors, and formatting preserved). It distinguishes from sibling converters like pdf_to_text or pdf_to_csv by specifying the JSON output and preserved elements.
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 context is implied through the purpose: use when a JSON representation with full formatting (text, fonts, images, vectors) is needed. However, there are no explicit exclusions or comparisons to sibling tools like pdf_to_text or pdf_to_csv, so an agent must 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. It only states the conversion objective, omitting important behavioral details such as API key requirements, asynchronous job processing, OCR behavior, or how to retrieve the output. The reference link is not a substitute for in-description 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 a single sentence with a reference link, making it extremely concise and front-loaded. Every word serves a purpose, and no redundant information is included.
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 underspecified. It lacks crucial context about output format, job completion, error handling, and required credentials, making it insufficient for an agent to invoke the tool correctly without external documentation.
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 input schema provides descriptions for all 11 parameters, achieving 100% coverage. The description adds no additional parameter context beyond what the schema already states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 PDFs and scanned images to XLS (Excel 97-2003) format, a distinct output versus siblings like pdf_to_xlsx or pdf_to_csv. The verb 'Convert' and resource/format specificity 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 does not explicitly say when to use this tool versus alternatives like pdf_to_xlsx. The distinction is implied by the output format name, but there is no explicit guidance on choosing this tool or 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 carries the full burden of behavioral disclosure. It only states the conversion action, without mentioning API key requirements, async processing, return value format, or side effects. The reference link provides some direction but is not inline transparency.
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 stating the core action, followed by a reference link. It contains no redundant words or unnecessary detail, making it highly concise and well-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?
Despite rich schema coverage, the description lacks essential context for an 11-parameter conversion tool with no output schema: it does not describe return values, output file handling, prerequisites, or usage scenarios. The reference link hints at more documentation but the tool description itself 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?
All 11 parameters are fully described in the input schema (100% coverage), so the description does not need to add parameter details. The schema descriptions are detailed and self-sufficient, meeting the baseline for this dimension.
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 PDF and scanned images to XLSX (Excel 2007+ format), using a specific verb and resource. It distinguishes this from sibling tools like pdf_to_xls (Excel 97-2003) and pdf_to_csv 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when XLSX output is needed, but gives no explicit when/when-not guidance or alternatives. Sibling tools exist for other formats, but no comparison or selection criteria are provided.
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 carry the full burden of behavioral disclosure. It only states the action without detailing side effects (e.g., whether the original PDF is modified, output behavior, authentication requirements, or error handling). The example annotations format is helpful but does not disclose the tool's operational behavior beyond the input structure.
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 and includes a helpful example annotation format. It is front-loaded with the core purpose and then supplements with the example. The reference link is extra but not harmful. It earns its place without being overly verbose.
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 6 parameters, 2 required, and no output schema. The description does not explain what the tool returns (e.g., the generated PDF URL or job status), nor does it mention prerequisites like using 'upload_file' for local files. Given the complexity, the description is incomplete for an agent to fully understand the tool's behavior and results.
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 description coverage is 100%, so the baseline is 3. The description adds value by providing a concrete example of the 'annotations' parameter format, showing fields like 'text', 'x', 'y', 'size', 'pages', 'type', and 'id'. This goes beyond the schema's generic description and clarifies how to structure the form elements.
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 new fillable form elements in a PDF document.' This is a specific verb (create) + resource (fillable form elements in PDFs), and it distinguishes from similar siblings like pdf_add_annotations_images_fields by focusing on form elements.
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 a clear context (creating fillable forms) but does not explicitly mention when to use this tool versus alternatives. There is no exclusionary guidance or mention of prerequisites. It is implied that this is the right tool for adding form fields, but no explicit alternatives are 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?
No annotations are provided, so the description carries the full burden. It does not disclose whether the original PDF is modified or a new file is created, nor any side effects or authentication requirements beyond what the schema implies. The example format helps but is not enough 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 and front-loaded with the purpose. It includes a useful example and a prerequisite, but the reference link is optional and the structure could be slightly better organized.
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?
There is no output schema, so the description should explain return values or output behavior, but it doesn't. It also doesn't mention whether this tool triggers an async job or how results are delivered, leaving significant gaps for a complex 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 100%, so the schema already documents all parameters. The description's example format slightly clarifies the 'fields' nested structure, but it essentially repeats schema information without adding 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 'Fill existing form fields in a PDF document' with a specific verb and resource, distinguishing it from sibling tools like 'read_pdf_forms_info' (reading forms) and 'create_fillable_forms' (creating forms).
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 a clear usage prerequisite: 'Use read_pdf_forms_info first to get the fieldName values'. This guides the agent on how to prepare inputs, but it doesn't explicitly compare to alternatives 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently lists all possible statuses and their meanings, including 'working' for nonexistent jobs. Given no annotations, it carries the burden well, though it could mention it is a read-only operation with no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, front-loading the purpose, and each line serves a clear function. The list of statuses could be formatted for clarity, but overall it is 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?
The description adequately explains status outcomes but does not clarify what 'results' entails (e.g., return format). Since there is no output schema, more detail on what the tool returns would improve 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 coverage is 100%, so the schema already documents the two parameters. The description adds no extra meaning beyond the schema, such as format or constraints.
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 tool checks job status and results, listing possible statuses. However, it does not differentiate from the sibling tool 'wait_job_completion', which may be used for similar 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?
Usage is implied (when you have a job ID), but the description offers no guidance on when to use this tool versus alternatives like 'wait_job_completion', nor 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 bears the full burden of disclosing behavior. It does state the core mechanism—removing the text layer—which is a crucial destructive action. However, it does not elaborate on side effects, reversibility, or any permission requirements. The reference link is a positive addition, but the inline description remains thin on operational impact.
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 clear sentence followed by a reference link. It is front-loaded with the main action and method, with every word earning its place. There is no filler or repetition, making it highly efficient.
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 moderate complexity (7 parameters) and lack of annotations or output schema, the description is too sparse. It does not explain what the output looks like, how to retrieve the resulting PDF, or what the tool returns. The reference link may contain this info, but it is not inline. As a result, the agent would have to infer or investigate expected behavior, making this 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 description coverage is 100%, so the baseline is 3. The description adds no parameter-specific information beyond what is already in the schema. It does not clarify the meaning or format of any parameter, leaving the schema's descriptions to do the work. Thus, no added value is provided.
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 ('Make existing PDF document non-searchable') with the method ('removing the text layer'). It distinguishes this from the sibling tool pdf_make_searchable by naming the opposite outcome. The reference link provides additional detail without cluttering the description.
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 this tool (when you need a PDF to be non-searchable) but provides no explicit guidance on alternatives or exclusions. It does not mention whether to prefer this over other PDF processing tools, nor does it note prerequisites beyond the schema. The sibling tool pdf_make_searchable exists as an obvious alternative, but the description does not directly contrast them.
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 core behavior (OCR and invisible text layer) but omits operational details such as output format, job lifecycle, or how the result is retrieved. With no annotations to fill this gap, the transparency is moderate, making 3 appropriate.
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, with two sentences that front-load the purpose and core behavior. The documentation reference is an additional resource, not filler, resulting in an efficient, well-structured description.
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 does not explain return values or job-based execution, which is significant given the lack of an output schema and the presence of sibling wait_job_completion. The tool's behavior is partially described, but critical operational context is missing, making it incomplete for a tool with 8 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 100% for all 8 parameters, so the baseline is 3. The description adds no new parameter-specific guidance beyond the general OCR context already covered in the schema, providing no additional value here.
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: converting scanned PDFs or images into searchable PDFs via OCR. It also distinguishes itself from siblings like pdf_make_unsearchable by explicitly mentioning the addition of an invisible text layer, 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 implies a clear use case (working with scanned documents or images) but does not explicitly discuss alternatives or when not to use this tool. It provides context without exclusions, which aligns with a score of 4.
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 transparency burden. It provides substantive detail about header/footer HTML markup and placeholder classes, which is useful, but it does not disclose authentication requirements (e.g., API key), return output format, or any asynchronous/job 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 core one-sentence purpose is concise and front-loaded. The extended header/footer section is relevant and instructive, though the overall length is slightly heavy for a simple conversion tool. Every sentence serves a purpose, but the detail could be streamlined.
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 13 parameters, no annotations, and no output schema, the description is only partially complete. It does not explain the return value (e.g., PDF URL or job ID) or the authentication behavior in detail. The header/footer coverage is strong, but other operational aspects are left to the schema alone.
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 100%, so the baseline is 3. The description adds meaningful value by explaining valid HTML markup and the placeholder classes that can be used in the header and footer parameters, along with an example. This goes beyond the schema's minimal 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 opens with a clear, specific statement: 'Convert external webpage URL to PDF.' This identifies the action (convert), the resource (external webpage URL), and the output (PDF). It also distinguishes from sibling tools like html_to_pdf by specifying URL-based conversion.
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 mention when to use this tool versus alternatives, nor does it state exclusions or prerequisites. The name and phrase 'external webpage URL' imply the use case, but there is no direct comparison to siblings like html_to_pdf or document_to_pdf.
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 it can modify PDFs and scanned PDFs and notes output expiration, but it does not describe the return format, whether the source is modified or a new file is created, or any authentication/rate-limit considerations beyond the api_key parameter.
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 well-organized with a brief overview, numbered sections for each mode, and illustrative examples. Every sentence contributes meaningful information without redundancy. The length is justified by the tool's multi-capability nature.
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 (12 parameters, three operational modes, no output schema or annotations), the description does a strong job of covering the main usage scenarios and parameter properties. It lacks details about the return value/response structure, but the extensive examples and mode breakdown make it largely complete for 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?
Schema coverage is 100%, so the baseline is 3. The description adds value by grouping parameters into three modes, listing each property, and providing concrete JSON examples for annotations, images, and fields. This clarifies how parameters interact even though the schema already documents each one individually.
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 text, images, forms, other PDFs, fill forms, links to external sites and external PDF files.' It clearly identifies the tool's three main capabilities (annotations, images, fields) and distinguishes it from siblings like 'fill_forms' by covering a broader 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 provides clear context on when to use the tool by outlining three modes of operation with examples. However, it does not explicitly mention when not to use it or name alternatives like 'fill_forms' for form-only tasks, so it stops short of full exclusion guidance.
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:

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

Score Badge

Copy to your README.md:

[![pdfco-mcp MCP server](https://glama.ai/mcp/servers/pdfdotco/pdfco-mcp/badges/score.svg)](https://glama.ai/mcp/servers/pdfdotco/pdfco-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/pdfdotco/pdfco-mcp'

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