pdf-toolkit-mcp

by AryanBV

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation5/5
Each tool has a clearly distinct purpose, targeting different PDF operations (creation, manipulation, extraction, forms, etc.). Overlaps like multiple creation tools are differentiated by input format (text, markdown, template), so no ambiguity exists.
Naming Consistency5/5
All tools follow a consistent 'pdf_verb_noun' pattern in snake_case (e.g., pdf_add_page_numbers, pdf_extract_text). The naming is predictable and each verb clearly indicates the action.
Tool Count5/5
With 22 tools, the set covers a broad range of PDF operations without being excessive. Each tool addresses a specific need, and the count is well-suited for a comprehensive PDF toolkit.
Completeness4/5
The toolkit covers creation, manipulation, extraction, forms, search, comparison, and encryption. Minor gaps exist (e.g., no tool to update metadata, remove encryption, or compress), but core workflows are well-supported.
Average 4/5 across 22 of 22 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on May 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This repository includes a glama.json configuration file.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds no behavioral context beyond annotations, so baseline score is 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?
Extremely concise, two sentences with no wasted words. The action is front-loaded and all subsequent information is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description lacks details on return values, error handling, or file constraints. It is adequate but not fully complete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes all parameters. The description briefly mentions configurable attributes but does not add meaning beyond the schema, meeting the baseline.
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 verb 'Add page numbers' and identifies the resource (PDF). It lists configurable attributes, making the purpose specific. However, it does not explicitly differentiate from sibling tools like pdf_add_watermark, so a very high score is not warranted.
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 versus alternatives (e.g., pdf_add_watermark) or when not to use it. The description only states what it does, not usage context or prerequisites.
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 adds behavioral context beyond annotations by specifying default positioning (centered, rotated diagonally) and page range application. Annotations are not contradicted. However, it does not detail side effects, performance, or file impact, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no wasted words. It front-loads the essential action and resource, then adds key default information. Ideal structure for quick comprehension.
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 8 parameters, 100% schema coverage, and existing annotations, the description sufficiently covers default behavior and page range handling. It does not explain the output or side effects, but the output path is self-explanatory. Overall, it is complete for a watermarking tool with good schema support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters are fully described in the input schema (100% coverage). The description adds context about defaults and page range behavior (e.g., 'Applies to all pages if no page range is specified'), but this largely reinforces existing schema info. Thus, the description adds marginal semantic value beyond the schema.
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 ('Add a text watermark') and resource ('PDF pages'), and includes default behavior (centered, rotated diagonally). It effectively communicates the tool's purpose, though it does not explicitly differentiate from siblings.
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 minimal usage guidance, only mentioning that it applies to all pages if no page range is specified. There is no discussion of when to use this tool versus alternatives or exclusions, which is a gap for an 8-parameter tool.
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?
Annotations indicate idempotentHint=true and destructiveHint=false, so the description's mention of filling fields aligns. It adds that flatten can make fields non-editable and notes font requirements for non-Latin text. However, it does not disclose behavior like overwriting existing field values or error handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, followed by key details (supported field types and font requirement). Every sentence is essential; no fluff.
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 5 parameters, complete schema coverage, and no output schema, the description adequately covers key aspects: supported field types, required font for non-Latin text, and flatten effect (via parameter). Missing: output path requirements or error scenarios, but schema covers the former.
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 baseline 3. The description adds that field values can be strings or booleans (matching schema) and mentions list-box multi-select fields (not fully captured in schema type constraints). Does not explain parameters like outputPath or flatten beyond what 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 clearly states the action ('Fill form fields in a PDF') and specifies supported field types (text, checkbox, dropdown, radio, list-box). It distinguishes itself from sibling tools like pdf_get_form_fields (which reads fields) and pdf_flatten (which only flattens without filling).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It implies usage for filling forms but does not mention prerequisites (e.g., the PDF must have form fields) or when not to use it (e.g., for flattening alone, use pdf_flatten). No comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations providing readOnlyHint=false and destructiveHint=false, the description adds context about supporting custom positioning and scaling. However, it does not mention that the tool creates a new output file or any potential side effects like performance with large files.
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 effectively communicates the tool's purpose and key capabilities without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description does not need to explain return values. It adequately describes the action and key capabilities, though it could mention that the output is written to the specified outputPath.
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 parameters. The description does not add additional semantic meaning beyond what is in the schema, achieving the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it embeds PNG or JPEG images into a specific PDF page, mentioning custom positioning and scaling. This distinguishes it from sibling tools like pdf_add_watermark or pdf_embed_qr_code.
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 embedding images but does not explicitly state when to use this tool versus alternatives like pdf_add_watermark. No guidance on 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains how AcroForm fields are handled on extracted vs omitted pages and describes the flatten parameter's effect. Annotations only provide idempotentHint, so this info fills gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose. Every word adds value, no filler.
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?
Covers key aspects: purpose, form behavior, and flatten option. Could mention that the original file is unchanged, but overall sufficient for a tool with moderate complexity and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description goes further by explaining the flatten parameter's impact on form fields, adding nuance not in the schema.
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 extracts specific pages into a new PDF, using a specific verb and resource. While it doesn't explicitly distinguish from siblings like pdf_delete_pages, 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 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 versus alternatives such as pdf_delete_pages or pdf_merge. The description only states what it does, not the context or exclusions.
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?
Description correctly states rotation is additive, but annotations claim idempotentHint=true, which is contradictory. Multiple identical calls would produce different results due to additivity, violating idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First covers purpose and key behavior, second covers default. No fluff.
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?
Covers core behavior, default, and additive nature. Missing potential error conditions or output path considerations, but adequate for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions. Description adds context about additive rotation and default page behavior, enhancing understanding beyond 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?
Clear verb 'rotate' and specific resource 'pages in a PDF' with angles. Differentiates well from sibling tools like delete, reorder, etc.
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?
States default behavior when no page range is specified. Lacks explicit when-not-to-use guidance but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive behavior. The description adds context about target page and coordinates, but does not clarify output file handling (e.g., overwriting) or required permissions.
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, front-loading the core purpose and listing supported barcode types efficiently. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not mention return value, success indication, or error cases. It provides minimal context beyond what is in the schema and annotations.
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 description adds no additional meaning beyond the schema parameter descriptions. The listed barcode types are already defined by the enum.
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 embeds a QR code or barcode into a specific PDF page at coordinates, and lists supported formats. It is distinct from sibling tools like pdf_embed_image or pdf_add_watermark.
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 embedding barcodes but does not explicitly state when to use this tool over alternatives (e.g., pdf_embed_image for images) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: automatic line wrapping, page overflow handling, and fontPath for non-Latin support. Annotations already indicate it's a write (readOnlyHint=false) and idempotent (idempotentHint=true), so the description complements well without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three succinct, front-loaded sentences covering core function, page size support, and fontPath guidance. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main behavior and constraints. With full schema coverage and annotations, the description is sufficient for a tool of this complexity. Could mention whether outputPath overwrites existing files, but idempotentHint implies safety.
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 each parameter is described. The description reinforces the fontPath parameter's purpose for non-Latin text but adds little new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Create a new PDF from text content' with automatic line wrapping and page overflow. Mentions supported page sizes and fontPath for non-Latin. Differentiates from siblings like pdf_create_from_markdown and pdf_create_from_template by focusing on plain text input.
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?
Implies usage for plain text via 'from text content', and hints at alternatives through sibling tool names, but does not explicitly state when to use this vs others or mention any exclusions.
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?
Annotations provide idempotentHint=true and destructiveHint=false. The description adds value by detailing supported Markdown features (CommonMark + GFM elements), which helps the agent understand output fidelity and constraints. However, it does not disclose behavior for unsupported elements.
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 concise sentence followed by a list of supported features. It is front-loaded with the main action and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (Markdown to PDF with multiple features), the description covers the supported syntax adequately. No output schema exists, but the tool's purpose (file creation) implies a file at outputPath. Missing details on return values or error handling reduce completeness slightly.
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% with descriptions for all parameters. The description does not add further explanation beyond what the schema provides, so baseline score 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 'Create a rich, high-fidelity PDF from Markdown', specifying the verb (create), resource (PDF), and source format (Markdown). It also lists supported syntax elements, distinguishing this tool from siblings like pdf_create (generic) and pdf_create_from_template.
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 Markdown content is available but lacks explicit guidance on when to use this tool versus alternatives (e.g., pdf_create for other inputs). No when-not-to-use or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that data is validated against the template's schema, a useful behavioral trait. However, with no annotations providing safety profile (all false), the description does not cover potential side effects like file overwriting, permissions, or error handling. It adds some value but lacks full transparency for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the primary action and provide essential detail on data requirements. Every word is purposeful; no redundancy or filler. The structure efficiently conveys the core function without unnecessary elaboration.
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 rich input schema and explicit field lists, the description adequately prepares an agent to use the tool. The absence of an output schema is acceptable. Minor gaps like file overwrite behavior or return value are not critical, and overall the description feels complete for the task.
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 input schema already covers all three parameters with descriptions (100% coverage). The description goes further by enumerating the required fields for each template (invoice, report, letter), adding meaningful context beyond the schema, especially for the complex data object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a PDF from a named template (invoice, report, or letter), using a specific verb and resource. This directly distinguishes it from siblings like pdf_create or pdf_create_from_markdown, as it focuses on templates rather than blank documents or markdown.
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 a named template and matching structured data are available, but it does not explicitly state when to use this tool versus alternatives (e.g., pdf_create, pdf_fill_form). No exclusions or when-not guidance is provided, leaving the selection mostly to the agent's inference.
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?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description builds on this by detailing that the tool bakes current values, removes interactivity, and copies form-less PDFs unchanged. This adds concrete behavioral context without contradicting annotations. However, it does not disclose potential permissions or error handling, preventing a top score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences precisely covering the core operation and an edge case. Every sentence adds value with no redundancy, making it ideal for quick comprehension.
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 low complexity (2 required params, no output schema, no nested objects), the description sufficiently covers the main effect and a key edge case. It does not describe return values or error conditions, but for this simple tool, the provided information is largely adequate. The presence of many siblings suggests a need for more differentiation, but the purpose clarity already helps.
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 both filePath and outputPath having clear descriptions in the schema. The tool description adds no additional parameter-level meaning beyond the schema, so a baseline score of 3 is appropriate as per guidelines.
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 'Flatten a PDF's form fields, baking their current values into the page content and removing interactivity.' It uses a specific verb 'flatten' and resource 'PDF's form fields', clearly distinguishing from sibling tools that handle forms differently (e.g., pdf_fill_form fills but may keep interactivity). The added note about form-less PDFs being copied unchanged further clarifies 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's effect but does not provide explicit guidance on when to use it versus alternatives like pdf_fill_form or pdf_get_form_fields. Given the large set of sibling tools, this omission leaves the agent to infer the appropriate context, resulting in a baseline score.
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?
Annotations already mark the tool as read-only and idempotent. The description adds value by specifying the return behavior for PDFs without forms ('Returns hasForm: false'), which is not in annotations. This provides useful context beyond safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The first sentence front-loads the primary action and return details. Every word adds value, and the description is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema) and supportive annotations, the description covers the essential behavior. It explains the return for PDFs without forms. However, it omits potential error cases or file validation, which might be needed for a complete 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?
Schema description coverage is 100% (filePath described with maxLength). The description adds no additional parameter semantics; it does not mention file path format, file existence requirements, or error handling. Baseline score of 3 is appropriate since schema already covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'form fields in a PDF', and specifies the returned data (names, types, current values, required status). It also mentions a special return case for PDFs without forms, which distinguishes it from sibling tools like pdf_fill_form or pdf_flatten.
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?
No explicit guidance on when or when not to use this tool. The description implies usage for inspecting form fields, but does not reference alternatives or prerequisites. Minimal guidance for an agent to decide between this and other PDF tools.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's behavioral burden is lower. It adds value by listing the specific metadata fields returned (title, author, etc.). This goes beyond annotations by specifying output content, which helps the agent understand what to expect. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the action and lists the metadata. Every word earns its place. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, clear annotations, and no output schema, the description is fairly complete. It lists the metadata fields returned. However, it could be slightly improved by noting that the tool does not modify the file (already implied by annotations) or handling missing files (but not required). Overall, sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter 'filePath' is 100%, with a clear schema description: 'Absolute path to the PDF file'. The tool description does not add any additional meaning or constraints beyond what the schema already provides. 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 purpose: retrieving metadata from a PDF file, and explicitly lists the specific fields (title, author, subject, page count, dates, producer). This is a specific verb+resource combination that distinguishes it from sibling tools like pdf_extract_text or pdf_get_form_fields.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for read-only metadata retrieval, but does not specify when not to use it (e.g., for text extraction) or mention alternative tools. The sibling tool list provides context but no direct comparison.
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 adds behavioral context beyond annotations, such as allowing duplicates, preserving AcroForm fields, and explaining the flatten option. This helps the agent understand side effects and capabilities.
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, front-loads the purpose, and provides necessary details without superfluous text. It is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: reordering action, page order format, duplicate allowance, AcroForm preservation, and flatten option. However, it does not explicitly state that the original file is left unchanged, which could be inferred from the output path requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add significant parameter information beyond what the input schema already provides, which includes detailed descriptions for each parameter including format and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reorder pages in a PDF' and provides explicit details about the page order format, distinguishing it from sibling tools like rotate or delete pages.
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 compare to sibling tools or state when to use this tool over others. It implies usage through its purpose statement but lacks guidance on alternatives or exclusion criteria.
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 adds valuable behavioral context beyond annotations: it specifies that AcroForm fields are preserved and auto-renamed on collision, and describes the flatten option effect. Annotations indicate idempotentHint true, which is consistent, but the description provides non-obvious details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, directly states the main purpose, and front-loads the essential behavior. Every sentence adds value without unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, full schema coverage, and no output schema, the description sufficiently covers key behaviors (form field handling, flattening). It provides enough context for an AI agent 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% description coverage for all parameters, so the description adds little new meaning. It repeats the flatten behavior but does not enhance understanding of filePaths or outputPath beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: merging multiple PDF files into one. It uses specific verbs and resources, and the behavior (preserving AcroForm fields, flatten option) distinguishes it from sibling tools like pdf_split or pdf_create.
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 explains how to use the tool (merging, preserving AcroForm, flatten option) but does not provide explicit guidance on when to use this tool versus alternatives. It lacks comparisons to siblings like pdf_add_page_numbers or pdf_fill_form.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond annotations: it states that AcroForm fields on remaining pages are preserved, explains the flatten option's effect ('bake field values into static content'), and adds the constraint 'Cannot delete every page.' This provides valuable context that annotations (which are minimal) do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each earning its place: first sentence gives purpose, second adds behavioral note on forms, third introduces flatten and constraint. It is front-loaded with the core action and contains no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action, key behaviors, and constraints. It does not explicitly state that the original file is left unmodified (implied by outputPath) or error conditions. For a tool with 4 parameters and no output schema, it is largely sufficient, though a brief note on side effects could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the flatten parameter's effect on form fields and the limitation that not all pages can be deleted. However, for filePath and outputPath, it adds nothing beyond the schema. The 'pages' parameter description in schema already includes examples.
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 'Delete specific pages from a PDF, keeping the rest in their original order,' which is a specific verb and resource. It distinguishes from siblings like pdf_split (which splits into separate files) and pdf_reorder_pages (which changes order). The added note 'Cannot delete every page' further differentiates it.
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 scenarios where pdf_split or pdf_reorder_pages might be more appropriate. There are no explicit when-to-use or when-not-to-use instructions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, and the description adds context: it reveals AES-256 encryption, default owner password behavior, and that a user password is required. It does not contradict annotations. However, it could mention that the original file is not modified (output to separate path) or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with no redundant information. It is front-loaded with the main action and efficiently conveys key details.
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 moderate complexity (4 parameters, no output schema), the description covers the main purpose and key behavioral aspects. It lacks details about error handling, prerequisites, or side effects, but is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for all parameters. The description adds extra meaning by specifying AES-256 encryption and that ownerPassword defaults to userPassword. This goes beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool encrypts a PDF with AES-256 password protection, specifying both user and owner password roles. It distinguishes from sibling tools like pdf_merge or pdf_split by focusing on encryption.
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 tell when to use or not use this tool compared to alternatives. While it implies use for password-protecting PDFs, it lacks guidance such as 'use for securing PDFs; for removing encryption, see pdf_decrypt' (not present in siblings). No alternative names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining the default page limit and rationale. Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool is safe. The description further clarifies behavior (returns text, limited pages) without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences. The first sentence states the core purpose, and the second provides essential details about defaults and parameter usage. There is no extraneous information; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of full schema coverage and annotations, the description is complete. It covers purpose, default behavior, and parameter usage. It does not specify the output format (e.g., plain text), but that is implicitly clear. For a non-complex tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are well-documented in the schema. The description reinforces the purpose but does not add new semantic meaning. It mentions the default for 'pages' which is also in the schema. Score is baseline due to high 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 action 'Extract text content from a PDF file', which is a specific verb and resource. It distinguishes from sibling tools like pdf_add_page_numbers or pdf_merge, which have different purposes. The default behavior of returning first 10 pages is also noted, adding clarity.
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 explains when to use the default (first 10 pages) and how to use the 'pages' parameter for more control. It provides context about avoiding LLM context limits, but does not explicitly mention when not to use this tool or suggest alternatives. Overall, it gives clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true, readOnlyHint=false), the description discloses that the tool writes files and returns paths, and explains inline behavior with max pages and DPI cap. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently cover the main purpose and a key option (inline). No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and a major variant (inline). It lacks details on return format for non-inline, error conditions, or file naming, but for a rendering tool with good annotations and schema, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds only marginal value for the inline parameter (max pages, DPI cap). The baseline of 3 is appropriate since the schema already documents all parameters adequately.
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 renders PDF pages to images for vision-capable clients, specifying the use case (scanned or image-only PDFs). The verb 'render' and resource 'PDF pages to images' are specific, and the purpose is distinct from sibling tools like pdf_extract_text.
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 indicates when to use the tool ('so a vision-capable client can read scanned or image-only PDFs') and mentions the inline option. However, it does not explicitly exclude scenarios or suggest alternatives among the listed sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by revealing search behavior: literal substring matching, default case-insensitivity, and return format (snippet and page number). Annotations already indicate safe, read-only, idempotent operation, and the description complements this without contradiction.
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 that front-load the main action and key behaviors. Every sentence adds value, no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's functionality for a simple search operation with 4 parameters. It lacks detail on snippet length or formatting, but given the straightforward nature, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description reiterates parameter details (case-insensitive default, page range). However, it adds context about return values (snippet and page number), which is not in the schema, enhancing understanding despite no output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and resource 'PDF', specifying that it returns matches with a snippet and page number. It distinguishes from siblings like pdf_extract_text (which extracts all text) and pdf_to_markdown (which converts format), focusing on targeted search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding specific text in a PDF, including case-insensitivity and page range, but does not explicitly state when to avoid this tool or mention alternatives like pdf_extract_text for extracting all text. The guidance is clear but lacks exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint, etc.), the description discloses that diffs are based on content-stream order, returns identical and truncated flags, and that large diffs are trimmed. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences front-load the purpose and output, then cover limitations and edge cases. Every sentence adds necessary information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a comparison tool with no output schema, the description covers purpose, output flags (identical, truncated), and key limitations. It could be more specific about the output format, but given the complexity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds context about 'absolute page index' and 'page by page', enhancing understanding of the pages parameter, but the schema already covers the basics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'compare', the resource 'two PDFs', and the method 'page by page by absolute page index', which distinguishes it from other PDF tools that do not perform comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that the tool is best for same-layout documents, warns about noisy diffs with reflowed or multi-column PDFs, and explains the effect of inserting/deleting pages. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, destructiveHint, idempotentHint. Description adds details on column reconstruction, heading inference, list detection, table treatment, and page defaults. No contradiction.
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?
Single well-structured paragraph front-loading purpose, then details, then limitations. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers most aspects: output format (Markdown), page handling, limitations. Could be more explicit about return type (e.g., string), but good for a tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context: page range format examples and default behavior (first 10 pages). FilePath requirement is clear.
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 to Markdown for LLMs, with specific details on column handling, heading inference, list detection, and table behavior. It distinguishes from sibling tools like pdf_render_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states best use case (clean digital PDFs), warns about scanned PDFs and complex layouts, and recommends pdf_render_pages as alternative for scanned PDFs.
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:

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

Score Badge

Copy to your README.md:

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

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