Skip to main content
Glama
PurpleDirective

quillpdf-mcp

Merge PDFs

pdf_merge

Combine two or more PDF files into a single document in the order you choose, processed entirely on your machine so files stay private.

Instructions

Merge two or more PDF files into one, in the order given. Runs entirely on this machine — the file is read and written locally and never sent anywhere.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoReplace the output file if it already exists (default: refuse, so existing files are never silently clobbered)
inputsYesPaths to the input PDFs, in merge order (2 or more)
outputYesPath to write the merged PDF

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.0
    • addedInput schema / properties / force
      Added value: +{
      +  "description": "Replace the output file if it already exists (default: refuse, so existing files are never silently clobbered)",
      +  "type": "boolean"
      +}
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare write behavior (readOnlyHint=false, non-idempotent), and the description adds genuinely new context: processing is local-only and files are never transmitted. That privacy guarantee is not available in schema or annotations. It does not, however, discuss side effects like overwrite handling beyond what the schema states.

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 core action and scope; the local-processing note earns its place as non-obvious behavior. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter tool with no output schema and full schema coverage, the essentials are covered: what it does, ordering, and a local-only security guarantee. It could mention the existing-file overwrite behavior, but that is adequately handled by the schema's force parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters (inputs, output, force) are already documented in the schema. The description only reinforces the merge-order semantics of inputs, adding little beyond the structured fields. Baseline 3 applies.

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?

States a specific verb and resource ('Merge two or more PDF files into one') plus the ordering constraint ('in the order given'), which cleanly separates it from siblings like pdf_split, pdf_organize, and pdf_from_images.

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 its use case (combining multiple PDFs) but never states when to prefer it over alternatives such as pdf_organize or pdf_split, nor any prerequisites or exclusions. Usage is inferable but not guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.