pdf-toolbox-mcp

by twoer

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Every tool targets a distinct PDF operation or resource, from extraction to redaction to form filling. Even the close pair `tool_redact` and `tool_redact_text` is clearly separated by geometry-based vs content-based workflows, and `tool_is_searchable` acts as an explicit router rather than an overlapping duplicate.
Naming Consistency3/5
The consistent `tool_` prefix and snake_case casing keep the set readable, and most tools follow a verb_noun pattern like `extract_text`, `split_pdf`, and `fill_form`. However, several names break the pattern with verb-only or noun-only forms such as `tool_linearize`, `tool_sanitize`, `tool_redact`, and `tool_dependency_status`, creating noticeable inconsistency.
Tool Count4/5
At 24 tools this is on the heavier side, but each tool maps to a distinct and meaningful PDF capability rather than duplicating another. For a broad PDF processing toolbox, the count feels slightly high but still scoped and purposeful.
Completeness4/5
The surface covers the core PDF lifecycle well: inspect, extract, OCR, edit, secure, split, merge, repair, redact, optimize, and form-fill. A few minor gaps exist such as creating PDFs from scratch, deleting individual pages directly, or flattening forms, but agents can generally achieve their goals with workarounds.
Average 3.6/5 across 24 of 24 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the core behavior—checking structure and, when repair=true, rebuilding a repaired output file. However, it omits important behavioral traits such as whether the original file is modified, what happens without repair, and whether overwrite is required or destructive.
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-loads the main purpose. It contains no filler or redundant phrasing. It could be slightly improved by adding minimal context around output and overwrite, but as a concise summary it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no annotations, and no output schema, this description is incomplete. It does not explain the output file behavior, overwrite semantics, failure modes, or when to prefer this tool over similar siblings. An agent would still need to infer or discover important calling conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the four parameters, but it only clarifies repair=true. The meanings of path, output, and overwrite are left entirely to the schema's types and defaults. This is insufficient given the lack of 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 states a specific action—structural inspection of syntax/stream encoding—and mentions an optional repair mode that rebuilds a repaired output file. This is clear about the resource and operation, but it does not explicitly distinguish it from sibling tools like tool_sanitize or tool_linearize, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as tool_sanitize, tool_linearize, or tool_pdf_info. The description implies it is for structural health checks and repairs, but there is no explicit condition, prerequisite, or exclusion to help an agent select it correctly.
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 does reveal one useful behavior: unmatched fields are returned in 'missing' rather than throwing an error. However, it does not state whether the source file is modified, how 'overrite' and 'output' interact, or what happens for unsupported field types — significant gaps for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every clause adds information: the operation, the target, and the unmatched-field behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, nested structures, and no annotations, the description is too thin. It leaves the output/overrite model and path semantics to the reader's inference. The one behavioral detail about missing fields is useful but not enough to safely invoke the tool with confidence in all intended cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It adds meaning only for 'fields' by stating the mapping is field name → string/boolean, and it hints at a 'missing' key in the result. It does not explain 'path', 'output', or 'overrite', which remain completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('填写' / fill) and a specific resource ('AcroForm 表单'), clearly identifying the tool as a form-filling operation. This distinguishes it from the many sibling PDF tools like extraction, rendering, splitting, or redaction.
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 about when to use this tool instead of a sibling or when not to use it. The intended use is only implied by the description, with no explicit context, exclusions, or alternatives.
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 does communicate that the output is a progressive-loading, web-optimized version, which is useful. However, it does not explain side effects, such as whether the original file is modified, what the `output` and `overwrite` parameters do semantically, or what happens if output is null.
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 no filler, and the key purpose is front-loaded with 'Web 优化'. It is appropriately sized for a simple tool, though the phrasing is slightly vague and could be more explicit about the resource being linearized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no schema-level parameter descriptions, this description is incomplete. It provides the high-level use case but omits essential operational details like what input path should point to, how output/overwrite interact, and whether the operation is destructive. The sibling names strongly suggest PDF handling, but the description itself does not state this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it only weakly implies an output parameter via '输出'. The required `path` parameter and the `overwrite` behavior are not explained at all, leaving the agent to guess what values and side effects are involved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific behavior: '输出渐进加载版' (outputs a progressive-loading version) and gives the use context: web-optimized, online browsing. It is distinguishable from sibling PDF operations like compress_pdf because it focuses on progressive loading behavior, though it never explicitly names PDF as the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when this tool is appropriate: for publishing files intended to be viewed online, with progressive loading as the goal. It does not mention alternatives or exclusion criteria, but the stated context is specific enough for an agent to select it over general PDF manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry full behavioral disclosure. It clearly discloses the write-back nature, per-file result returning, and failure isolation. However, it does not clarify whether files are overwritten in place, how out_dir relates to write-back, or how redo_ocr/overwrite/retries/timeouts affect behavior, leaving operational side effects under-specified.
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 short sentences, front-loaded with the main action and scope, and no filler or repetition. Every phrase contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, the tool has 8 parameters and no annotations or schema descriptions. The description covers the required input and failure handling but leaves essential operational details like write destination, overwrite behavior, and advanced options unexplained, so an agent can make a default call but cannot confidently handle non-default use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It only explains 'inputs' as file paths or directories taking all PDFs; the other seven parameters (lang, deskew, out_dir, redo_ocr, overwerite, max_retries, per_file_timeout) are left without meaningful semantics beyond their names and defaults.
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 opens with '批量 OCR 写回' (batch OCR write-back), which identifies a concrete action and resource, then specifies that inputs can be file paths or directories containing all PDFs. This distinguishes it from the single-file sibling tool_ocr_pdf via the 'batch' and 'per-file' framing, though it does not fully define the write-back target.
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 input guidance about directories and all PDFs, plus the statement that a single-file failure does not interrupt the batch, implies the intended use case for batch OCR over multiple files. However, no alternatives are named and there is no explicit when-to-use vs when-not-to-use guidance relative to the many 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 discloses the core read/write action (extracting files) but fails to mention side effects such as whether out_dir is created if missing, what happens to existing files, or what the tool returns. No behavioral detail beyond the basic operation is given.
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 single, focused sentence with no filler. The verb and key nouns are front-loaded, and every word contributes to meaning. It is concise without being under-spectified to the point of confusion.
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 a simple tool with two parameters and no annotations, the description still omits important context: when to prefer this sibling, what the default output behavior is, and any side effects of writing files. The output schema exists but does not offset missing behavioral or usage context. An agent could call it, but not confidently in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions, so the description must compensate. It does tie 'PDF' to the path parameter and '指定目录' to out_dir, giving a basic mapping. However, it does not clarify that out_dir is optional with a null default or what happens when out_dir is null, leaving a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (抽取/extract), a precise resource (PDF 内嵌附件文件/embedded PDF attachment files), and a destination (指定目录/specified directory). It also distinguishes itself from sibling extraction tools like tool_extract_text and tool_extract_images by targeting attachments 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?
No guidance is provided on when to use this tool instead of alternatives, and there is no mention of exclusions or conditions. The sibling list contains several extraction tools, but the description does not tell the agent which situations call for attachments extraction versus text or image extraction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does reveal the key behavioral difference for return_images=True (direct image content blocks), which is valuable. However, it doesn't mention what happens when return_images=False, whether files are written to out_dir, or any side effects or prerequisites.
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 short and front-loaded. The core action is stated first, and the return_images behavior is added as a useful conditional. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, this description is minimal. It fails to define the pages string syntax, the meaning of dpi, the role of out_dir, or what the non-return_images mode returns. An agent would likely need external documentation to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. Only return_images is partially explained; dpi, pages, path, and out_dir receive no semantic meaning beyond their names and types. The agent would have to guess the pages format, DPI behavior, and output directory semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: render specified pages as PNG. It also explains the return_images mode, which helps distinguish this from extraction or OCR tools. However, it doesn't explicitly contrast with sibling tools like extract_images or ocr_pdf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives one concrete usage hint: use return_images=True when you need visual inspection of complex layouts, charts, or scanned pages. But it doesn't explain when to prefer this over alternatives or when not to use it, leaving much of the decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does usefully reveal that list_only=true returns a listing without writing files, implying the default behavior writes PNGs to disk. However, it does not disclose output location defaults, permission requirements, overwrite behavior, or what happens when no images are found.
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 compact sentence that front-loads the core action and then adds the important list_only variant. There is no filler or redundancy; every word contributes 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?
For a tool with four parameters, zero schema descriptions, and no annotations, the description is too thin. It explains list_only but leaves pages and out_dir unexplained and provides no usage guidance. The presence of an output schema helps, but the agent still lacks enough context to invoke the tool with non-default parameters confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only explains list_only. It does not clarify the meaning of pages, out_dir, or path, leaving key parameters undocumented. Some meaning for path is implicit via 'PDF,' but pages and out_dir remain opaque.
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 and resource: extracting embedded images from a PDF and saving them as PNG. It also mentions the list_only behavior, which helps distinguish it from sibling tools like tool_extract_text, tool_render_pages, and tool_extract_attachments.
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 about when to prefer this tool over alternatives, nor does it mention any exclusions or context where another sibling like tool_render_pages or tool_extract_attachments would be more appropriate. Usage context is only implied by the tool's name and the phrase 'embedded images.'
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 bears the behavioral disclosure burden. It adds useful parameter behavior — exact page-range syntax, layout preservation, and per-page return mode — but it omits broader traits such as that pdftotext only reads the embedded text layer, that scanned PDFs may return empty text, and that the file is not modified.
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 that names the operation first and then gives a compact semicolon-separated parameter summary. Every phrase adds relevant information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter tool with no annotations, the description covers the main extraction options and an output schema exists for return values. However, it does not cover the critical decision boundary between this tool and OCR-based text extraction, nor what happens when pages is null, leaving the agent with partial context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the parameter-level details in the description are essential. It explains pages with an example, layout as preserving layout, and per_page as returning by page; only path is left implicit, but its meaning is clear from the tool context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: extract PDF text via pdftotext, with a clear verb and resource. It does not explicitly differentiate itself from sibling OCR tools like tool_ocr_pdf that can also produce text from PDFs, relying on the pdftotext reference to imply embedded-text extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 versus alternatives such as tool_ocr_pdf for scanned PDFs or tool_locate_text for finding text positions. The description only explains parameter behaviors, not the use-case conditions that should select this 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?
With no annotations, the description carries the full transparency burden. It usefully discloses the blank user_password behavior and the default permissions, but it does not explain output/overwrite behavior or what happens when owner_password is null. These are material unknowns for a file-modifying 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 dense sentences with zero filler; the primary encryption purpose comes first and the critical user_password semantics immediately follow. This is appropriately sized for the information it conveys.
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 an 11-parameter mutating tool with no annotations and 0% schema description coverage, this is too thin. Essential invocation details like what output=null means, whether overwrite applies to the input path, and what owner_password controls are absent. The output schema may cover return values, but not the file-side behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add parametric meaning. It does add the crucial semantic that an empty user_password still applies permissions without requiring an open password, and it summarizes three permission defaults. However, it leaves output, overwrite, owner_password, and several allow_* booleans unexplained beyond their raw names, and some default details are already present 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 nails the core action: it is AES-256 encryption for external distribution, which clearly identifies a protect/encrypt operation on a PDF. It distinguishes generally from siblings like unlock/extract/merge, though it never names a specific sibling.
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 phrase 对外分发 gives a clear intended context: protect PDFs that will be sent outside the organization. It does not explicitly say when not to use it or point to unlock/aliternative tools, leaving some routing inference to the agent.
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 carry the full behavioral disclosure burden. It reveals the angle range and the default 'pages' behavior, but it does not disclose whether the original file is modified in place, what happens when 'output' is omitted, or what 'overwrite' actually controls. For a mutating PDF tool, these are critical safety-relevant behaviors.
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 and front-loaded, with no wasted words. However, it is somewhat terse for a mutating tool with multiple undocumented parameters; a sentence or two about output/overwrite behavior would make it appropriately sized without adding clutter.
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 5 parameters, no annotations, and 0% schema description coverage, yet the description only covers the rotation action and the 'pages' default. It omits essential input-side behavior such as how 'output' and 'overwrite' interact and whether the original file is modified. The existence of an output schema does not compensate for these input-behavior gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the bare input schema. It adds meaning for 'angle' (allowed values) and 'pages' (default all), but leaves 'path', 'output', and 'overwrite' semantically unexplained. This is insufficient for a 5-parameter tool with no 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 uses a specific verb ('rotate') with a specific resource ('pages'), and states exact supported angles (90/180/270 degrees). It also communicates that omitting 'pages' rotates all pages. This clearly differentiates it from the sibling tools, none of which are rotation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is clear from the operation itself: rotate PDF pages by the specified angle. No sibling tool performs rotation, so there is no ambiguity about which alternative to choose. However, the description does not explicitly state exclusions or conditions such as output-file requirements or overwrite behavior.
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?
There are no annotations, so the description carries the full behavioral transparency burden. It discloses the ordering behavior but does not mention whether input files are modified, how the optional overwrite parameter affects behavior, or what happens if the output file already exists. These are relevant side-effect details for an agent invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler and the most important constraint (ordering) is included. Every word contributes to understanding what the tool does.
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 straightforward merge operation the description covers the core behavior, but it leaves gaps around the optional overwrite parameter and failure behavior. Given that annotations are absent and the operation creates a file, a more complete description would state whether existing outputs are overwritten only when the flag is set and whether source files are left untouched.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds meaning by clarifying that the 'paths' array is order-sensitive and that 'output' is the single result file. However, it does not describe the 'overwrite' parameter, whose semantics are only partially inferable from its name and default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('merge'), a clear resource ('PDFs'), and a meaningful constraint ('in the order passed in'). No sibling tool performs merging, so it is immediately distinguishable from the other PDF operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used when you need to combine multiple PDFs, but it does not explicitly state when to use it versus alternatives or mention prerequisites such as input file validity or output path expectations. Since no sibling tool merges PDFs, the ambiguity is low, but the guidance is still 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?
No annotations are provided, so the description must carry behavioral disclosure by itself. It does state the key behavior of producing a decrypted output file and clarifies that only the user/open password is needed, which is useful. But it does not disclose side effects, whether the original file is preserved, or what happens when overwrite is used.
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 short purposeful sentences: it states what the tool does, adds the crucial password distinction, and gives workflow guidance. Every sentence earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has few parameters and an output schema exists, the description is mostly sufficient for basic invocation. The main contextual gaps are the meaning and default behavior of 'output' and 'overwrite', plus failure behavior on an incorrect password. These are not fatal, but they require the agent to infer.
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 0%, so the description needs to compensate. It does clarify the password parameter meaningfully ('user（打开）密码即可，无需 owner 密码') and implies the output parameter via '输出解密文件'. However, 'path' and especially 'overwrite' remain underexplained in 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 a specific action ('解锁加密 PDF') and a concrete result ('输出解密文件'), making the tool's purpose obvious. It does not explicitly name a sibling to differentiate from, but the verb and resource are specific enough to separate it from protect, compress, and metadata tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The statement '解锁后再走其他工具' gives some workflow context by implying this tool should be run before other PDF tools when a password is present. However, it does not explicitly state when not to use it or compare it with alternatives such as tool_protect_pdf or tool_check_repair.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It does reveal mutual exclusivity of ranges/every_n and that files are produced per range/page-group, but says nothing about side effects like overiting, file creation location, or whether the source PDF is modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence that front-loads the action and uses concrete examples. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core splitting behavior is covered and output schema exists, but with no annotations and five params, the holostic description misses important operational details such as what out_dir/overwrite do and what the output files are called. This is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, so the description needs to compensate. It explains the ranges and every_n formats and their exclusivity, which helps, but it leaves path, out_dir, and overwrite semantically unexplained.
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 names the operation ('拆分 PDF') and illustrates both split modes with concrete syntax, which unambiguously identifies this as the splitting tool among siblings like merge/rotate. It goes beyond the tautological title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It includes some parameter usage guidance ('二者二选一' for ranges/every_n) but never addresses when to choose this tool over siblings or states exclusions/alternatives. The context is mostly about mode selection, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively discloses that compression is lossy, uses image resampling via ghostscript, and that target_mb triggers a best-effort descent from ebook to screen quality. This is meaningful behavioral context beyond a simple 'compress PDF' statement, though it does not describe overwrite safety or output-file behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, with no filler. It front-loads the core purpose, then adds the key behavioral nuance about target_mb and quality descent. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, zero schema descriptions, and no annotations, the description is not complete enough for an agent to confidently invoke the tool in all cases. The output schema may cover return shape, but the parameter semantics for output, overwrite, and path behavior are still missing, and the quality parameter's full range of allowed values is unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the five parameters. It adds meaning for target_mb (size target) and quality (values ebook and screen), but it does not explain path, output, or overwrite semantics. That leaves a significant portion of the parameter surface undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as compressing PDFs, specifies the underlying engine (ghostscript), and the lossy nature (image resampling). This is a specific verb+resource pairing that makes the tool's purpose unmistakable, and it is distinct from sibling tools which do other PDF operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to reduce PDF file size, and it explains the quality descent path (ebook→screen) when target_mb is set. However, it does not explicitly state when to use this tool versus alternatives, mention prerequisites, or call out situations where lossy compression would be inappropriate.
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 zero annotations, the description carries the full behavioral burden and it does disclose the dual-target side effect (docinfo+XMP) and the destructive clear-all path. However it is silent on whether the original file is modified in place, what overwrite does, and reversibility, leaving material behavioral risk undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence packs operation, side-effect, destructive mode, and workflow pairing with zero wasted words. The semicolon and dash structure keeps the clear special case and the sanitize pairing immediately readable.
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 mutating tool with 9 params, no annotations, and 0% schema coverage, the description is too thin: it never explains in-place vs output behavior, overwrite merge semantics, or how the dual-rite manifests on clear. The output schema may cover return values, but core invocation semantics remain guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 9 parameters, so the description must compensate. Only clear=true receives real semantics; the roles of overwrite and output, and how title/author/subject etc. interact with overwrite, are left to name-guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('编辑元数据') and adds the dual-write mode ('docinfo+XMP 双写'), making the tool's scope unambiguous. No sibling tool targets metadata, so this clearly differentiates it from the extraction and content-manipulation tools in the family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a concrete invocation context ('对外发布前配合 sanitize 使用') and a conditional mode (clear=true 清空全部), which tells an agent when this workflow step matters. It does not explicitly name when-not-to-use cases or alternatives, so it stops just short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It states that the tool lists fonts and their embedding status, and it adds a useful real-world implication. The verb 'list' implies a read-only operation, though it does not explicitly say so.
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 compact, front-loaded with the core action, and each clause contributes information. There is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-oriented tool with an output schema, the description covers the central purpose and the user-facing consequence well. The main gap is the undocumented path parameter, but the sibling context and the nature of the task make the intended input reasonably inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, path, with 0% description coverage, and the description does not compensate. It gives no guidance that path should point to a PDF, no format details, and no example, so an agent gets no additional parameter meaning from the description.
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 and object ('列出字体与嵌入状态' — list fonts and embedding status), making the tool's function immediately clear. It also distinguishes itself from every sibling tool in the list, none of which covers font inspection.
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 use context: a 'font health check' to detect embedding issues. The added consequence — unembedded fonts may cause missing characters when viewing or printing across devices — tells an agent when this tool is valuable, though it does not name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly implies a read-only metadata retrieval operation and lists what the call reveals, which is useful. However, with no annotations provided, the description carries a heavier burden and does not explicitly state side-effect freedom, error behavior, or what happens with invalid/encrypted 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 two short sentences with no fluff. It front-loads the operation and metadata fields, then adds the critical usage timing guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter metadata tool with an output schema present, the description is mostly complete: it says what the tool returns, when to call it, and what resource it operates on. Minor gaps are path semantics and edge-case behavior, already reflected in other dimensions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'path', has 0% schema description coverage, and the description does not explain the expected path format, file accessibility, or whether it must be a local file vs a URI. The phrase '任何 PDF' implies it is a path to a PDF, but the description fails to compensate for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('获取') and a specific resource ('PDF 元信息'), and enumerates concrete metadata fields (page count, encryption, page size, title, author). It also distinguishes itself from the sibling PDF-processing tools by positioning itself as the pre-flight info tool.
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 explicitly states when to use it: '处理任何 PDF 前先调用此工具' (call this before processing any PDF). It does not explicitly name alternatives or when-not-to-use cases, but the pre-processing direction is clear enough for an agent to select it first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries more weight, and it does disclose non-obvious matching behavior: no Chinese segmentation, English cross-word matching, NFKC normalization, and whitespace removal. It also clarifies the coordinate system. It does not explicitly note absence of side effects, but 'locate' is read-only by nature.
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 compact, front-loaded with the primary function, then adds matching nuance in a second sentence. Every sentence earns its place, and there is no redundant noise.
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 output schema covers return shape, and the description covers coordinate semantics and matching behavior. However, because schema coverage is 0% and annotations are absent, the missing documentation of pages and max_results leaves a real gap for an agent trying to call the tool correctly in non-trivial cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters, but it only elaborates on query matching. It does not describe the format or meaning of pages, the semantics of max_results, or how path should be supplied. The param names are somewhat self-evident, but the description provides little value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: locate text and return its page and coordinate box in PDF points with top-left origin. It also frames the tool as the coordinate source for redaction, which clearly separates it from extraction or rendering tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It communicates a clear use case: find where content is and provide coordinates for redaction. It does not explicitly mention alternatives like extract_text or state when not to use it, but the redaction-focused framing is sufficient context for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and reveals destructive effects: redacted pages are rasterized, text is physically deleted, and other pages retain their text layer. It does not cover output/overwrite side effects, but the core mutating behavior is 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?
Two terse sentences plus a concrete example convey the action, workflow, and destructive side effects with no filler. The key behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for the core redaction scenario but incomplete for optional output behavior: it does not clarify how dpi, overwrite, output, or rasterize_all alter the result. Since an output schema exists, returns are covered, but the overall tool behavior is not fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters, but it only clarifies 'queries' as keywords. 'path', 'dpi', 'output', 'overwrite', and 'rasterize_all' receive no meaningful explanation, leaving most parameters under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Identifies a precise action: automatically locate every occurrence of given keywords and black them out by content, without manual coordinates. The phrase '按内容' and the example distinguish it from coordinate-based redaction tools and sibling tool_redact.
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 example '把所有合同编号涂掉' and the automatic keyword-location behavior make the intended use case clear. It implies a content-driven redaction workflow, though it never explicitly names alternatives or says 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?
No annotations are provided, so the description carries the behavioral disclosure burden. It explains that the tool only returns a recommended action rather than performing extraction, which is useful, but it does not mention whether the operation is read-only, what happens with invalid paths, or any edge cases around sampling.
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 with critical routing information front-loaded. Every clause earns its place, and the fallback instruction '不确定时先调这个' is a useful, compact guideline.
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 lightweight routing tool with an output schema present, the description covers the core decision flow and names both target tools. The only gap is the unexplained sample_pages parameter, which prevents full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter meaning, but it mentions no parameters. 'path' is somewhat inferable, but 'sample_pages' and its default of 5 are completely unexplained, leaving the agent unsure how sampling affects the check.
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 and resource: it checks whether a PDF has an extractable text layer and returns a recommended action. It clearly distinguishes itself from sibling tools by positioning itself as the routing entry point between extract_text and ocr_pdf.
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?
The description explicitly names when to use this tool: when uncertain, call it first. It also names the two alternative actions it routes between (extract_text and ocr_pdf), giving clear decision 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?
With no annotations, the description carries the full burden. It discloses critical behavior: pages with redactions are rasterized, text is physically and irrecoverably removed, other pages keep their text layer, and rasterize_all rasterizes the whole document.
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 compact sentences deliver the security promise, coordinate format, irreversibility, and the rasterize_all escalation. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core destructive behavior and region format are well covered, and an output schema reduces the need to document return values. Still, it omits output/overwrite flow, dpi effect, and path constraints, which matter for a destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description meaningfully documents regions=[{page,x,y,w,h}] with coordinate units and origin, plus rasterize_all semantics. However, dpi, path, output, and overwrite are not explained in either the schema or description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb/resource: secure redaction via coordinate regions, and clearly distinguishes itself by explaining physical deletion and rasterization, which separates it from sibling tools like tool_redact_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives context that this is the security-level true redaction option and describes when rasterize_all=true is strongest, but it does not explicitly state when to prefer this tool over tool_redact_text or tool_sanitize.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of disclosing behavior. It clearly lists what the tool strips (JS/OpenAction/metadata/attachments) and explicitly states that body text is untouched, which is critical destructive semantic information. It does not mention side effects around overwriting or output handling, but the core behavioral profile is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with a clear colon-led list and a dash-introduced rationale. Every clause adds information: purpose, stripped items, optional toggle, non-goal, and security motivation. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive 7-parameter tool with no annotations, the description provides purpose, scope, excluded behavior, and security rationale. An output schema exists, so return-value documentation is not required here. It would be more complete if it related the output/overwrite parameters to the described sanitation workflow, but the agent can still select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It usefully maps the strip_metadata, strip_javascript, strip_attachments, and strip_annotations parameters to concrete behaviors, and '正文文本不动' clarifies that no text-modification parameter is intended. However, it does not clarify the required 'path' parameter nor the semantics of 'output' and 'overwrite', which are meaningful for safe invocation.
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 ('剥离' / strip) and a clear target ('发布版脱敏' / release-sanitization), then enumerates exactly which components are removed: JS, OpenAction, metadata, attachments, and optionally annotations. It also states a key non-goal (body text unchanged), which distinguishes it from sibling tools like tool_redact and tool_edit_metadata.
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 phrase '发布版脱敏' gives a clear release/distribution context for when this tool should be used, and '正文文本不动' signals that it is not for content redaction. It does not explicitly name sibling alternatives or state when-not-to-use conditions, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the output artifact and naming convention, the default behavior of skipping existing text layers, language defaults (chi_sim+eng), and language-pack fallback behavior. These are meaningful behavioral traits beyond the schema. It doesn't mention performance expectations, side effects on the original file, or what happens when OCR is impossible, but it discloses more than most.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and information-dense, with the primary purpose front-loaded in the first sentence and the key defaults and special behaviors in the second. Every sentence adds value, and there is no repetition of the tool name or schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an OCR tool with a single required parameter (path), the description provides usable defaults and output expectations. But it omits the meaning and valid ranges of the optional parameters (e.g., what 'deskew' does, how 'output' interacts with the naming convention, what 'redo_ocr' affects), and there is no annotation layer to fill that gap. The output schema exists but is not shown here, so return-structure clarification would be needed for a fully confident 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 description coverage is 0%, so every parameter lacks schema doc. The description does not explain individual parameters, so the agent must infer the effect of 'lang', 'deskew', 'redo_ocr', 'overwrite', and 'output'. However, the description's behavioral details (e.g., 'redo_ocr' likely relates to re-OCRing pages with existing text layers, 'overwrite' likely controls whether an existing output file is replaced) provide some implicit context. Since the tool has 6 parameters and 0% schema coverage, the description does not fully compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately identifies the tool's core function: OCR scanned PDFs and write the text layer back, producing a searchable PDF. It also specifies the output naming convention (<stem>_ocr.pdf), which is concrete and actionable. The claim that it is a core differentiating capability of the toolbox distinguishes it from sibling PDF tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the default behavior when to use this tool: it is for scanned documents and searchable PDF output. It also mentions when it will skip pages (those already having text layers), which helps the agent understand when the tool is still useful. However, it doesn't explicitly name sibling alternatives such as tool_extract_text or tool_is_searchable for non-OCR workflows, so the when-not-to-use guidance is only partially explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries some burden. It discloses that the tool probes dependencies and returns installation commands, but it doesn't state whether this performs system checks, downloads anything, or merely reads configuration. However, for a dependency-check tool, this is reasonable and not misleading; a middling 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?
The description is a single concise sentence that packs the resource (system dependencies), the purpose (detect and provide installation commands), and a usage trigger. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a zero-parameter diagnostic tool: it names dependencies, the output (installation commands), and the error context. An output schema exists, so return values don't need elaboration. It could add more detail about whether it actually installs or just reports, but that is a minor gap.
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 tool has zero parameters and schema coverage is 100%, so there is no parameter ambiguity. The description is clear that the tool is about dependency status, not about asking for user input. This is effectively complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool detects system dependencies (qpdf/poppler/tesseract/ghostscript) and installation commands. It also tells the agent to consult this tool when a missing_dependency error occurs, which clearly distinguishes it from sibling tools.
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?
Gives an explicit trigger condition: '工具报 missing_dependency 时先看这里' (when a tool reports missing_dependency, check here first). This directly tells the agent when to use this tool before troubleshooting, which is clear usage 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:

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

Score Badge

Copy to your README.md:

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

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