docbridge

Overview Schema Source Related Servers Discussions Admin

pdf_merge

Idempotent

Merge PDFs in a specified order into one file while preserving bookmarks, links, annotations, and form fields; get a page-identity verification report.

Instructions

Merge PDFs, in the order given, into one PDF. Bookmarks, links, annotations and form fields are carried. The report checks page count, and that every output page is pixel-identical (rendered), text-identical and rotation-identical to the source page it came from. [docbridge schema 0.2.4]

Input Schema

TableJSON Schema

Name	Required	Description	Default
`detail`	No	summary: report_summary + report_id (get_report has the rest). full: the whole report inline.	summary
`inputs`	Yes	PDF paths, in output order.
`overwrite`	No
`raster_dpi`	No	Render resolution for the page-identity check.
`output_path`	Yes	Absolute file path.
`report_path`	No
`max_differences`	No	Differences kept in the full report; the rest are counted.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`tool`	Yes
`error`	No
`report`	No	The full report. Over MCP only with detail='full'.
`outputs`	No
`report_id`	No	Pass to get_report for the full report (held for this server session).
`disclaimer`	No		docbridge never alters, summarizes or silently truncates source evidence. docbridge reports what it compared. PASS on an axis covers only that axis's stated scope; NOT_CHECKED and UNSUPPORTED are never passes. PDF text is the text layer as PyMuPDF decodes it, not the rendered glyphs. Nothing here interprets meaning: numbers are compared as characters, not as values.
`report_path`	No
`report_summary`	No
`schema_version`	Yes
`conversion_notes`	No
`operation_completed`	Yes	The operation ran and wrote its outputs. Says NOTHING about fidelity: read the report status.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.4Sep 28, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations declare this is a non-read-only but idempotent, non-destructive write, and the description adds real value beyond them: exactly what content is carried (bookmarks, links, annotations, form fields) and the built-in verification (page count, pixel/text/rotation identity). It stops short of stating failure behavior or what happens to the output path on error.

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?

Three tight sentences, front-loaded with the core action, followed by carried content and verification. The trailing '[docbridge schema 0.2.4]' tag is minor noise but the rest 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?

With an output schema present, the description needn't explain return values, and it covers action, carried content, and verification. Only error/failure handling and overwrite behavior are unstated, which is a minor gap for a 7-param write tool.

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 71%, so the schema documents most parameters, but the description usefully explains why raster_dpi, max_differences, and the report exist by describing the page-identity check. This adds meaning beyond the field-level 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?

States a specific verb and resource ('Merge PDFs ... into one PDF') and pins down the ordering semantics ('in the order given'), which is the key ambiguity for a merge operation. It is easily distinguished from siblings like pdf_split and images_to_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?

Usage is strongly implied by the name and the description, but there is no explicit when/when-not guidance and no pointer to alternatives (e.g., pdf_split for the inverse, images_to_pdf for non-PDF sources). Adequate but leaves selection to inference.

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

Deploy Server