Skip to main content
Glama
BatuhanCakmakk

LaserPDF

by BatuhanCakmakk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Merge PDFs

merge_pdfs
Idempotent

Combine multiple PDFs and images into one new PDF in the given order—PDF pages sequentially, each image centered on its own A4 page. Use it to build PDFs from documents, photos, or scans.

Instructions

Joins several PDFs and images (JPEG, PNG, WebP, GIF, BMP, AVIF) into one new PDF, in the order given: all pages of each PDF, and each image centred on an A4 page of its own. Use it to combine documents or turn photos and scans into a PDF; to take pages out, use extract_pages or split_pdf, and to turn pages into images, use pdf_to_images. The inputs are not changed, and an existing output file is only replaced with overwrite: true. Fails with a message when a path cannot be read, when no file is a PDF or image, and for encrypted PDFs; other files in the list are skipped.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathsYesAbsolute paths of the PDFs and images, in the order wanted (at least one).
outputYesAbsolute path of the new PDF. If the file exists, the call fails unless overwrite is true.
overwriteNoAllow replacing an existing file (default false).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.9
    • changedInput schema / properties / output / description
      Previous value: -"Absolute path of the PDF to write."New value: +"Absolute path of the new PDF. If the file exists, the call fails unless overwrite is true."
    • changedInput schema / properties / paths / description
      Previous value: -"Absolute paths, in order."New value: +"Absolute paths of the PDFs and images, in the order wanted (at least one)."
  2. First observedv1.0.6

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare the non-destructive, idempotent, closed-world profile, but the description adds substantial context on top: inputs are left unchanged, an existing output is replaced only with overwrite:true, non-PDF/image entries are silently skipped, and it fails on unreadable paths, all-invalid lists, and encrypted PDFs. These failure modes and side effects are exactly the behavioral detail annotations cannot express.

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 core operation is front-loaded in the first clause, followed by layout rules, alternatives, and failure modes in one dense paragraph. Every clause carries information, though the single block is slightly long for easy scanning.

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?

With no output schema, the description still covers ordering, layout, side effects, overwrite gating, skip behavior, and error conditions. An agent has everything it needs to invoke this correctly without guessing.

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 100%, so the baseline would be 3, but the description adds meaning for paths by specifying ordering is significant and that non-PDF/image entries are skipped rather than erroring, and it clarifies the existence/overwrite interaction for output. Only minor overlap with what the schema already says about overwrite keeps this from a 5.

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 (joins) and resource (PDFs and images into one new PDF), plus the exact ordering and image-to-A4-page layout semantics. It also names the sibling tools for the inverse operations (extract_pages, split_pdf, pdf_to_images), so an agent can place it precisely in the toolset.

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 explicit when-to-use ("combine documents or turn photos and scans into a PDF") and explicit when-not, routing removals to extract_pages/split_pdf and page-to-image conversion to pdf_to_images. The alternatives are named with the condition that selects them.

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

Deploy Server

Other Tools