Skip to main content
Glama

merge_pdfs

Combine 2 to 10 PDF files into one document in the order you specify, joining scans, chapters, or invoices into a single file.

Instructions

Combine 2 to 10 PDFs into one document, in the order given. Use this to join separate scans, chapters or invoices into a single file. Password-protected files must be unlocked first. The input is uploaded to the Papyrio API, processed in memory and not stored. The result is written to output_path, replacing any file already there, and the call returns that path and the size in bytes. Inputs are limited to 50 MB, and each call counts as one operation against the daily quota.

Input Schema

NameRequiredDescriptionDefault
filesYesAbsolute paths to the PDFs, in the order they should appear.
output_pathNoAbsolute path to write the result to. Defaults to the input file with a "-papyrio.pdf" suffix.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses upload to the Papyrio API, in-memory processing with no storage, an overwrite of any existing file at output_path, the 50 MB input cap, and quota consumption. The destructive overwrite warning is especially valuable since no annotations flag it.

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?

Five tight sentences, front-loaded with the core action and scope, followed by prerequisites, privacy, side effects, and limits. Every sentence carries distinct information with no repetition of the schema.

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

Completeness5/5

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

Although there is no output schema, the description states the return value (path and size in bytes), covers side effects, size limits, and quota cost. An agent has everything needed to invoke this correctly on the first try.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it reinforces that file order determines output order and that output_path replaces any existing file. It does not otherwise elaborate on path formats, but the added overwrite semantics are real 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?

Opens with a specific verb and resource ("Combine 2 to 10 PDFs into one document") plus a scope constraint (order preserved, count bounded). It is clearly distinguishable from siblings like split_pdf or extract_pdf_text without needing the schema.

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?

Gives concrete use cases (scans, chapters, invoices) and an explicit prerequisite: password-protected files must be unlocked first, which implicitly routes to unlock_pdf. It does not explicitly name alternatives or state when not to use it, but the context is clear.

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