PDF Manipulation MCP Server

by fastmcp-me

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.2
Disambiguation4/5
Most tools target distinct actions or resources (e.g., add_text vs replace_text, add_image vs extract_images). Some overlap exists between crop_page and auto_crop_page, and between merge_files and combine_pages_to_single, but descriptions clarify the differences.
Naming Consistency4/5
All tools follow a snake_case pattern with the pdf_ prefix and mostly verb_noun structure (pdf_add_text, pdf_rotate_page). The only deviation is pdf_split, which lacks an explicit object, but the pattern is otherwise consistent.
Tool Count4/5
With 16 tools, the server is at the high end of what is typically well-scoped, but the breadth of PDF manipulation features (text, images, forms, pages, metadata, merging) justifies the count. Each tool covers a distinct need without excessive redundancy.
Completeness4/5
The tool surface covers the main PDF operations: editing, extraction, merging/splitting, page manipulation, forms, and metadata. Minor gaps exist, such as no explicit page reordering or form flattening, but these are not critical for the core purpose.
Average 2.7/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description gives no information about side effects, such as whether the original file is modified or a new file is created, coordinate system details, or file handling. With no annotations to rely on, the description carries the full burden and fails to disclose essential behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single direct sentence with no wasted words, making it structurally concise. However, it is too terse to be considered well-structured for a tool with 7 parameters and no supporting detail elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 7 parameters, no annotations, and a minimal description, the tool's behavior remains almost entirely unspecified. The output schema exists but the description still fails to explain coordinate semantics, file impact, or pagination, making it deeply incomplete.
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 description does not explain any of the 7 parameters (pdf_path, page_number, x0, y0, x1, y1, coordinate_mode). Schema description coverage is 0%, so the description must compensate but provides zero value beyond the parameter names.
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 ('Crop a page in a PDF') with a clear verb and resource. However, it does not differentiate from the closely related sibling tool pdf_auto_crop_page, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like pdf_auto_crop_page, pdf_rotate_page, or pdf_delete_page. There is no mention of prerequisites, interactions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Add' implies mutation, but it does not state whether the file is modified in place, what annotation types are supported, or any required permissions. This is a significant gap for a tool that likely modifies the PDF.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified for a tool with 8 required parameters and no additional documentation. It does not front-load important usage details and lacks structure that would help an agent parse relevant information quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotation coverage, no schema descriptions), the description is completely inadequate. It does not explain annotation types, coordinate systems, page indexing, or the output format, making it impossible for an agent to invoke the tool correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no information about any of the 8 parameters. The parameters (x, y, width, height, annotation_type, etc.) are entirely unexplained, leaving the agent to guess their meanings and formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Add an annotation') and the target resource ('a PDF'), using a specific verb. It does not explicitly differentiate from sibling tools like pdf_add_text or pdf_add_image, but 'annotation' is a distinct concept in PDF terminology, providing some 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 provided on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or typical scenarios, leaving the agent without context for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Delete a page from a PDF,' which adds nothing beyond the tool name. It does not mention whether the operation is irreversible, how the file is handled (in-place vs new file), 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is structurally acceptable. However, it is under-specified and essentially restates the tool name, providing little value beyond the title. It is not bloated, but it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two required parameters and an output schema, indicating a moderate complexity. The description is too minimal to guide correct usage, lacking critical details like page numbering convention, file path handling, or notable side effects. It leaves the agent to guess essential information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain that pdf_path is the file location or that page_number might be 0-indexed or 1-indexed. It merely uses the word 'page' which parallels the parameter name, providing no additional meaning.
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 (delete) and the resource (a page from a PDF), which distinguishes it from sibling tools like pdf_crop_page or pdf_rotate_page. However, it does not explicitly differentiate itself from alternatives or mention any edge cases, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, constraints, or exclusions. It simply states the action with no context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it reveals nothing beyond the raw action. It does not mention rotation direction or units, page indexing, whether the operation is destructive, or what the output looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and to the point, but it is overly sparse. It is a single short sentence that states the core function yet lacks necessary detail about parameters and behavior, making it under-specified rather than efficiently complete.
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 definition is incomplete for a mutation operation: no annotations, no parameter explanations, and a one-line description. Although an output schema exists, it does not clarify the operation's semantics, leaving important behavior ambiguous.
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 descriptions coverage is 0%, and the description does not compensate by explaining any of the three parameters. It omits details such as allowed rotation values (e.g., 90, 180, 270) and whether page_number is zero- or one-based.
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 ('Rotate') and the target ('a page in a PDF'), which makes the tool's purpose immediately identifiable. It distinguishes from sibling tools like pdf_delete_page or pdf_crop_page because it specifies a distinct operation, though it does not elaborate on rotation specifics.
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 other PDF manipulation tools. The description does not state prerequisites, whether the operation modifies the file in-place or produces a new file, or any context for typical usage.
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. 'Add an image' implies mutation, but it does not explain whether the PDF is modified in place, what coordinate system is used, or what the output will be. Critical behavioral context such as file overwriting, page number validity, or error handling is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient and free of fluff. However, it is under-specified, bordering on terse, as it omits essential details. It is not as extreme as a tautology, but it sacrifices clarity for brevity, resulting in a middling score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 7 required parameters, no annotations, and no schema parameter descriptions. The description 'Add an image to a PDF' is grossly inadequate to guide an agent on how to correctly invoke it. It does not cover positioning, page selection, image scaling, or any other necessary operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 7 required parameters. It does not explain what x, y, width, height represent, how page_number is used, or what image formats are accepted. The tool has many parameters, and the description fails to compensate for the complete 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 'Add an image to a PDF' clearly states the action (add) and resource (image to a PDF). It distinguishes from siblings like pdf_add_text and pdf_add_annotation by specifying 'image' rather than other content types. However, it lacks any detail about placement or constraints, so it is not fully specific.
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 like pdf_add_text or pdf_add_annotation. The description provides no context about suitable scenarios, prerequisites, or when other tools should be preferred. It gives no usage directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'Replace text' without explaining whether this affects all occurrences, how page_number restricts the operation, or any side effects on the PDF layout and text extraction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is terse and front-loaded, but it sacrifices necessary specification. For a tool with four parameters, this is under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not provide enough operational context for an agent to invoke the tool reliably. It lacks details on occurrence semantics, page handling, and return values, making the definition incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter details. The meaning of page_number (e.g., null vs integer) and whether old_text/new_text are case-sensitive or replace all occurrences are left completely 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 uses a specific verb ('replace') and resource ('PDF document'), making the core purpose immediately clear. It is distinct from sibling tools like pdf_add_text, which adds text, and pdf_fill_form, which fills 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor are any prerequisites or limitations mentioned. The description gives no usage context beyond the basic operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the PDF is modified in place, whether an output file is created, what validation is applied, or any side effects of adding a form field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is too under-specified to be considered well-structured; conciseness should not trade away necessary 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?
With 8 required parameters, no annotations, and an output schema that is not described, the description is insufficient for correct invocation. It lacks information about return values, required field types, and page indexing, making it inadequate for an MCP tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions no parameters. Parameter names are somewhat self-explanatory, but the description does not explain field_type options, coordinate system, or the role of options.
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 identifies the action (adding a form field) and resource (a PDF), using a specific verb. It does not elaborate on form field types or distinguish it from pdf_add_annotation, but the basic 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 is provided on when to use this tool versus pdf_fill_form or pdf_add_annotation. The description only states the action, with no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. 'Set metadata' implies a write operation but does not state whether existing metadata is overwritten, whether the file is modified in place, or whether any permissions are required. This significant gap leaves the agent without crucial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, making it concise. However, it is under-specified; the brevity undermines informativeness. It does not waste words, but it could include more useful detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (two parameters, one being a nested object) and lack of annotations or output schema details, the description is incomplete. It fails to explain metadata formatting, overwrite behavior, return values, or any constraints, leaving the agent with insufficient context for correct invocation.
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 semantics. It does not mention pdf_path or metadata, or explain how the metadata object should be structured. While pdf_path is self-explanatory and metadata can be inferred as a key-value map, the description adds no explicit 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 uses a specific verb ('Set') and resource ('metadata for a PDF'), clearly indicating the tool's function. It is distinct from sibling tools that add text, images, or annotations, though it does not explicitly differentiate itself or mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. The usage is only implied by the tool's name and one-sentence description, leaving the agent to guess context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden for behavioral disclosure. It only states the action and position, but does not reveal whether the PDF is modified in-place, how the coordinate system works, how page numbers are indexed, or whether the input file is preserved. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence with no wasted words. It is formatted plainly and front-loads the core action clearly, which fits the conciseness criterion.
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 7 parameters, 5 required, and no annotations, the description is insufficiently complete. It omits crucial context such as coordinate system, unit of measurement, file mutation semantics, and error/return behavior. The presence of an output schema is noted, but the input handling remains underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no additional meaning for parameters beyond their names. It does not explain the units for x/y, the coordinate origin, the expected format for color, or the range/validity of page_number. The sparse one-line description fails to compensate for the undocumented 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 text') and the resource ('to a PDF') with a positional qualifier ('at a specified position'). It is specific enough to distinguish from sibling tools like pdf_replace_text (replace vs. add), though it does not explicitly contrast with alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings such as pdf_replace_text or pdf_add_annotation. The usage is only implied by the tool name and description, with no explicit 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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the general purpose. It does not mention output behavior, default output_path handling, overwrite risks, or any side effects, which is insufficient for a merge operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words, front-loading the core action. It avoids fluff and is appropriately minimal for the stated purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having only 2 parameters and an output schema, the description is too sparse to be contextually complete. It lacks essential information such as how output_path works (e.g., default behavior), what types of PDF paths are accepted, and any constraints, leaving the agent to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain pdf_paths or output_path beyond what is already evident from their names. No additional meaning or format details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Merge' and the resource 'multiple PDF files' into 'one combined PDF', distinguishing it from siblings like pdf_combine_pages_to_single which works on pages, not files. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It only states what it does without any context on prerequisites, exclusions, or comparisons to sibling tools like pdf_combine_pages_to_single.
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 supplied, so the description must carry the full behavioral burden. It explains the cropping approach but does not disclose whether the file is modified in place, what happens to the original, or how page_number=None affects the crop (e.g., all pages vs first page). This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no filler. Every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description still lacks critical context: how page_number and padding behave, whether the operation is destructive, and what the return value signifies. The tool is simple enough, but ambiguity around default behavior and parameters makes it incomplete.
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?
With 0% schema description coverage, the description must explain the parameters. It only mentions 'page' generically, but fails to explain the required pdf_path, the meaning of padding, or the semantics of page_number being null. The schema provides no descriptions, so the agent is left 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 uses a specific verb ('crop') and resource ('PDF page'), and clearly states it auto-detects content boundaries to remove blank margins. This distinguishes it from the sibling manual pdf_crop_page tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies automatic cropping but provides no explicit guidance on when to choose this over pdf_crop_page or other PDF manipulation tools. No exclusions or alternative selection advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects (e.g., whether it creates a new file or modifies the original), handling of output_path, or behavior when page_numbers are omitted. 'Specified layout' is vague and does not disclose available layout options or formatting behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, front-loaded with the primary action. However, it is too brief to be fully effective—important operational details are omitted, but this is not a bloat issue.
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 four parameters and no annotations, so a sparse description is inadequate. It does not explain layout options, page selection semantics, output path behavior, or what the output schema represents. Though an output schema exists, the description still leaves too much unexplained for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description provides only a vague reference to 'specified layout' but does not explain any of the four schema parameters (pdf_path, layout, output_path, page_numbers). It does not clarify what page_numbers means, what output_path defaults to, or how layout values affect the output. Schema description coverage is 0%, so the description fails to compensate.
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 ('Combine multiple pages from a PDF into a single page') with a clear resource and result. This differentiates it from sibling tools like pdf_merge_files, which merges entire PDF files rather than combining pages within a single PDF.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as pdf_merge_files or pdf_split. There are no explicit use cases, prerequisites, or exclusion statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It merely restates the function without disclosing behaviors such as file output format, handling of output_dir, overwrite behavior, or error cases. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the action and object. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no annotation coverage, this description is too sparse. It omits crucial context such as how output_dir behaves when null, what image formats are produced, and whether the tool creates the output directory. The presence of an output schema may compensate, but the description itself does not provide enough operational detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain either parameter. pdf_path and output_dir are left undefined; the description mentions only 'a PDF' and not the arguments, so the agent receives no semantic guidance beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Extract all images from a PDF' uses a specific verb and resource, clearly distinguishing this from sibling tools which perform add/merge/split operations. It unambiguously states the tool's function.
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 over alternatives. The description does not mention prerequisites, typical use cases, or exclusions, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states the action and lacks details about field-matching behavior, overwrite semantics, error handling, or any side effects beyond the mutation.
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 wasted words. It efficiently conveys the core operation without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not provide enough context for a tool with a nested object parameter. It fails to explain how to structure field_values or what happens when fields are missing, leaving the agent to guess at critical usage details.
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 should compensate by explaining parameter meaning. It mentions 'values' but does not clarify that field_values is a mapping of form field names to values, nor does it describe pdf_path beyond the inferred 'PDF' reference.
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 resource ('form fields in a PDF'), clearly distinguishing it from siblings like pdf_add_form_field or pdf_replace_text. It states exactly what the tool does with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as pdf_add_form_field or pdf_replace_text. The description implies usage for populating existing form fields but does not state exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Get' implies a read-only operation with no side effects, but it does not explicitly state that the PDF is not modified, nor does it mention error behavior or prerequisites like file existence. The behavior is not contradicted, but it is under-specified for a tool with zero annotation coverage.
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 repetition. It efficiently communicates the core function in just seven words, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so the description does not need to explain return values. However, it lacks any usage guidance and explicit read-only confirmation, making it minimally viable but not fully complete for an agent deciding when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to the single parameter 'pdf_path'. The parameter name is self-evident but the description does not explain its format, required location, or any constraints, so the description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('PDF') and clearly states it retrieves metadata and information. It distinguishes itself from all sibling tools, which are mutating operations (add, replace, merge, split, etc.), so the purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is intended for inspection before modification, nor does it name any exclusions or alternative tools, so an agent gets no usage context beyond the obvious difference from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the original PDF is modified, what output files are created, how overwriting is handled, or any permissions/limitations. 'Split' implies output, but key behavioral traits are undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It front-loads the core action and scope, making it easy to parse.
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 an output schema, the description omits critical usage details such as how page ranges are specified, what output directory is used, and how individual-page splitting differs from range splitting. For a tool with no annotations, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for its three parameters. The description hints at page_ranges ('page ranges') but does not explain the format or the role of pdf_path and output_dir. This is insufficient for a 3-parameter tool with no parameter-level documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Split a PDF into individual pages or page ranges.' This distinguishes it from sibling tools like pdf_merge_files and pdf_combine_pages_to_single, which perform related but different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to split a PDF), but it does not explicitly compare with alternatives or provide exclusions. There is no guidance on when to prefer this over pdf_delete_page or pdf_merge_files, so usage context is only implied.
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-manipulation-mcp-server MCP server](https://glama.ai/mcp/servers/fastmcp-me/pdf-manipulation-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/fastmcp-me/pdf-manipulation-mcp-server)

Score Badge

Copy to your README.md:

[![pdf-manipulation-mcp-server MCP server](https://glama.ai/mcp/servers/fastmcp-me/pdf-manipulation-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/fastmcp-me/pdf-manipulation-mcp-server)

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/fastmcp-me/pdf-manipulation-mcp-server'

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