Skip to main content
Glama
shuji-bonji

pdf-writer-mcp

by shuji-bonji
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Attach File (Embedded File)

attach_file
Idempotent

Embed supporting files, such as CSV or XML data, into a PDF to create PDF/A-3 compliant bundles for e-bookkeeping and archival workflows.

Instructions

Embed (attach) a file into a PDF. Registers it under /Names /EmbeddedFiles and the catalog /AF, with an AFRelationship. For PDF/A-3 (ISO 19005-3) and Japanese e-bookkeeping-law (電子帳簿保存法) workflows that bundle "a human-readable invoice PDF + machine-readable data (CSV/XML)" into one file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoDisplay name inside the PDF. Defaults to the original filename. Must not duplicate an existing attachment.
mimeTypeNoMIME type. Inferred from the extension when omitted (e.g. .csv → text/csv).
inputPathYesAbsolute path of the target PDF.
outputPathNoDestination file path (absolute). When omitted, a base64 string is returned instead.
descriptionNoDescription of the attachment (/Desc; CJK fine).
relationshipNoRelation to the document content (PDF/A-3 §6.8). Data = machine-readable data with the same content as the document (invoice XML/CSV etc.) / Source = the source data of the document / Alternative = an alternative representation / Supplement = supplementary material / Unspecified = unknown (default). PDF/A-3 requires a meaningful value, so omission warns.
returnBase64NoWhen true, include a base64 string in the result in addition to saving.
attachmentPathYesAbsolute path of the file to embed.
preserveSignaturesNoEdit a signed PDF via an incremental update (appending) without invalidating existing signatures. Default false. The original bytes are untouched, so /ByteRange holds. Changes beyond the certification (DocMDP) permission level are refused.
allowBreakingSignaturesNoWhen the target is digitally signed (detected via /ByteRange), the default is an error. Set true to proceed, accepting that the signatures become invalid.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.21.2

TDQS

A4.2/5.0
Behavior4/5

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

With annotations already indicating readOnlyHint=false and destructiveHint=false, the description adds meaningful behavioral detail: it says the file is registered under specific PDF name trees and the catalog with an AFRelationship. This explains the underlying mutation mechanism without repeating annotation facts.

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 three sentences with no filler. The core action is front-loaded, followed by technical registration details and then a concise use-case context. Every sentence adds useful information.

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 10-parameter tool with no output schema, the description gives enough high-level context to select the tool correctly handed off to the schema for parameter details. It does not describe return behavior, but the schema documents outputPath and returnBase64, so the gap is minor.

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 the baseline is 3. The description does not explain individual parameters, but it does tie the tool's purpose to the relationship field by mentioning AFRelationship and the invoice/CSV/XML bundling use case. The schema itself carries most parameter meaning.

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 begins with a specific verb and resource: 'Embed (attach) a file into a PDF.' It further clarifies the operation by naming the PDF structures involved (/Names /EmbeddedFiles, /AF, AFRelationship). This clearly distinguishes it from sibling tools like merge_pdfs or add_annotation.

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?

The description gives a concrete use context: PDF/A-3 and Japanese e-bookkeeping-law workflows that bundle invoice PDFs with machine-readable CSV/XML data. It does not explicitly state when not to use it or name an alternative, but the context is specific enough for an agent to decide when this tool applies.

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