pdfnative-mcp

Embed LTV validation material (PAdES B-LT)

add_ltv

Embed certificates, OCSP responses, and CRLs into a signed PDF's DSS and VRI so future verifiers can validate PAdES B-LT signatures online or offline.

Instructions

PAdES B-LT: embed a Document Security Store (/DSS + per-signature /VRI) with the certificates and OCSP/CRL material future verifiers need ('LTV enabled' in Adobe Reader once the root is trusted). Ladder step 3: sign_pdf (profile:'pades', timestamp:true) → add_ltv → timestamp_pdf. mode 'online' (default) fetches through the OPERATOR revocation provider (PDFNATIVE_MCP_REVOCATION + PDFNATIVE_MCP_NETWORK_ALLOWED_HOSTS; REVOCATION_NOT_CONFIGURED otherwise — no network without it); mode 'offline' embeds caller-supplied DER certificates / OCSP responses / CRLs with zero network. Incremental (existing /DSS merged). Needs ≥ 1 signed signature; unencrypted PDFs only.

Input Schema

Name	Required	Description	Default
`mode`	No	'online': fetch OCSP/CRL through the operator provider (PDFNATIVE_MCP_REVOCATION + allow-list; REVOCATION_NOT_CONFIGURED otherwise). 'offline': embed the caller-supplied DER material, zero network.	online
`match`	No	offline: what each signature's /VRI references. 'all' (default): every item (Adobe-tolerant superset). 'chain': only the material that validates that signature (its certificates and issuers, the OCSP responses naming them, their issuers' CRLs); the rest still ships in /DSS.	all
`pdfBase64`	Yes	Base64-encoded SIGNED PDF (unencrypted). Sign with sign_pdf (profile=pades recommended) first.
`outputMode`	No	'base64' (default) returns the PDF inline; 'file' writes it inside the PDFNATIVE_MCP_OUTPUT_DIR sandbox (SECURITY_VIOLATION when the sandbox is not configured).	base64
`outputPath`	No	Relative path inside PDFNATIVE_MCP_OUTPUT_DIR (required when outputMode='file').
`preferOcsp`	No	online: try OCSP before CRL for each certificate (default true).
`crlsDerBase64`	No	offline: DER CertificateList (RFC 5280) blobs to embed in /DSS /CRLs.
`certificatesDerBase64`	No	offline: DER X.509 certificates to embed in /DSS /Certs.
`ocspResponsesDerBase64`	No	offline: DER OCSPResponse (RFC 6960) blobs to embed in /DSS /OCSPs.
`extraCertificatesDerBase64`	No	online: additional DER certificates (intermediates / roots) to complete chains the CMS does not carry.

Output Schema

Name	Required	Description
`url`	No	Public URL of the file (file mode, only when PDFNATIVE_MCP_OUTPUT_BASE_URL is set): base URL + sandbox-relative path, percent-encoded.
`mode`	Yes
`summary`	No	Tool-specific summary, when produced.
`filePath`	No	Sandboxed absolute path (file mode).
`sizeBytes`	Yes
`diagnostics`	No	Engine diagnostics (when includeDiagnostics=true).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.8.0Nov 3, 2026

addedInput schema / properties / match

Added value: +{
+  "default": "all",
+  "description": "offline: what each signature's /VRI references. 'all' (default): every item (Adobe-tolerant superset). 'chain': only the material that validates that signature (its certificates and issuers, the OCSP responses naming them, their issuers' CRLs); the rest still ships in /DSS.",
+  "enum": [
+    "all",
+    "chain"
+  ],
+  "type": "string"
+}

changedOutput schema / description

Previous value: -"Result of a PDF-producing tool. base64 mode: the PDF arrives as an embedded `resource` content block (not duplicated here); file mode: `filePath`."New value: +"Result of a PDF-producing tool. base64 mode: the PDF arrives as an embedded `resource` content block (not duplicated here); file mode: `filePath` (and `url` when the operator maps the sandbox to a public base URL)."

addedOutput schema / properties / url

Added value: +{
+  "description": "Public URL of the file (file mode, only when PDFNATIVE_MCP_OUTPUT_BASE_URL is set): base URL + sandbox-relative path, percent-encoded.",
+  "type": "string"
+}

Changed1 schema field changedv1.6.2Sep 27, 2026

changedOutput schema / properties / diagnostics / description

Previous value: -"PDF/A diagnostics (when includeDiagnostics=true)."New value: +"Engine diagnostics (when includeDiagnostics=true)."

AddedAug 24, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond annotations, it discloses network gating via PDFNATIVE_MCP_REVOCATION and PDFNATIVE_MCP_NETWORK_ALLOWED_HOSTS, the REVOCATION_NOT_CONFIGURED failure, offline zero-network behavior, incremental merging of existing /DSS, and prerequisites (at least one signed signature, unencrypted PDFs only). These details materially help an agent predict behavior and failure modes.

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?

Despite its density, the description is front-loaded with the core operation, then the ladder position, then mode/network details. Every sentence carries operational information about prerequisites, environment variables, or side effects; there is no filler.

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?

For a complex mutation tool with ten parameters, network dependencies, and a defined workflow position, the description covers prerequisites, mode behavior, environment gating, output handling hints, and incremental merging. An output schema exists, so return-value explanation is not needed here.

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 input schema already documents all ten parameters, including mode, match, outputMode, and the DER material arrays. The description reinforces mode semantics and offline caller-supplied material but does not add much beyond the schema for parameters such as match or outputPath.

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 names a specific verb and resource — embed a PAdES B-LT Document Security Store (/DSS + /VRI) — and states exactly what material is added for future verifiers. It distinguishes itself from siblings by placing the tool in the signing ladder between sign_pdf and timestamp_pdf.

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?

It gives an explicit ordered workflow: sign_pdf with profile:'pades' and timestamp:true, then add_ltv, then timestamp_pdf. It also explains when to use each mode: online for operator-provider fetching, offline for caller-supplied DER material with zero network.

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