pdfnative-mcp

Validate PDF structure (PDF/UA, PDF/X-4)

validate_pdf

Read-onlyIdempotent

Validate PDF structural conformance for PDF/UA-1 accessibility or PDF/X-4 print exchange, returning errors and warnings. Use it as a read-only gate before full preflight.

Instructions

Read-only structural gate; standard picks the rule set. 'pdf-ua-1' (default, ISO 14289-1) for Tagged PDF: /MarkInfo /Marked, /StructTreeRoot (+ /ParentTree), XMP /Metadata, /Lang, per-page MCID uniqueness — generate tagged input with pdfA (e.g. 'pdfa2u') first. 'pdf-x-4' (ISO 15930-7) for print exchange: /GTS_PDFX OutputIntent with a prtr ICC profile, TrimBox or ArtBox, every font embedded, no annotation / JavaScript / embedded file / transfer function — generate it with pdfx:'pdfx4'. Result { standard, valid, errors[], warnings[], summary } (+ caveats[] for PDF/X). Fast and structural only — NOT a reference validator or a certified preflight: fonts, colour and rendering are not checked (veraPDF for PDF/A and PDF/UA; callas pdfToolbox or Acrobat Preflight for PDF/X). Unparsable input → PDF_PARSE_FAILED.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`fields`	No	Optional dot-path projection applied to the structured result (e.g. ['valid']). Composes after verbosity. Unknown paths are omitted.
`standard`	No	Rule set. 'pdf-ua-1' (default): PDF/UA accessibility structure (ISO 14289-1). 'pdf-x-4': PDF/X-4 print exchange (ISO 15930-7) — OutputIntent + prtr ICC profile, TrimBox, embedded fonts, no annotations / JavaScript / embedded files; structural prerequisites only, not a certified preflight (see caveats[]).	pdf-ua-1
`pdfBase64`	Yes	Base64-encoded PDF bytes to validate for structural conformance.
`verbosity`	No	Response verbosity. 'full' (default) returns errors[] and warnings[]; 'summary' returns a token-frugal verdict { standard, valid, errorCount, warningCount, summary } and drops the message arrays.	full

Output Schema

TableJSON Schema

Name	Required	Description
`valid`	No	True when no blocking structural violations were found.
`errors`	No	Blocking conformance violations. Empty when valid is true.
`caveats`	No	standard 'pdf-x-4' only: what a valid verdict does NOT establish.
`summary`	No	Human-readable one-line summary of the result.
`standard`	No	Conformance standard checked (ISO 14289-1 or ISO 15930-7).
`warnings`	No	Non-blocking best-practice recommendations.
`errorCount`	No	summary only: number of errors.
`warningCount`	No	summary only: number of warnings.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.6.2Sep 27, 2026

changedInput schema / properties / pdfBase64 / description

Previous value: -"Base64-encoded PDF bytes to validate for PDF/UA (ISO 14289-1) structural conformance."New value: +"Base64-encoded PDF bytes to validate for structural conformance."

addedInput schema / properties / standard

Added value: +{
+  "default": "pdf-ua-1",
+  "description": "Rule set. 'pdf-ua-1' (default): PDF/UA accessibility structure (ISO 14289-1). 'pdf-x-4': PDF/X-4 print exchange (ISO 15930-7) — OutputIntent + prtr ICC profile, TrimBox, embedded fonts, no annotations / JavaScript / embedded files; structural prerequisites only, not a certified preflight (see caveats[]).",
+  "enum": [
+    "pdf-ua-1",
+    "pdf-x-4"
+  ],
+  "type": "string"
+}

changedOutput schema / description

Previous value: -"Structured PDF/UA validation result. Every property is optional because the result can be projected: verbosity:'summary' returns only the scalar summary fields, fields:[...] keeps a dot-path subset. Defaults return the full shape."New value: +"Structured PDF/UA or PDF/X-4 validation result. Every property is optional because the result can be projected: verbosity:'summary' returns only the scalar summary fields, fields:[...] keeps a dot-path subset. Defaults return the full shape."

addedOutput schema / properties / caveats

Added value: +{
+  "description": "standard 'pdf-x-4' only: what a valid verdict does NOT establish.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / properties / errors / description

Previous value: -"Blocking PDF/UA conformance violations. Empty when valid is true."New value: +"Blocking conformance violations. Empty when valid is true."

changedOutput schema / properties / standard / description

Previous value: -"Conformance standard checked (ISO 14289-1)."New value: +"Conformance standard checked (ISO 14289-1 or ISO 15930-7)."

changedOutput schema / properties / standard / enum

Previous value: -[
-  "pdf-ua-1"
-]New value: +[
+  "pdf-ua-1",
+  "pdf-x-4"
+]

AddedAug 24, 2026
Removedv1.6.0Jul 22, 2026

Changed2 schema fields changedv1.2.0Jun 24, 2026

addedInput schema / properties / fields

Added value: +{
+  "description": "Optional dot-path projection applied to the structured result (e.g. ['valid']). Composes after verbosity. Unknown paths are omitted.",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 16,
+  "type": "array"
+}

addedInput schema / properties / verbosity

Added value: +{
+  "default": "full",
+  "description": "Response verbosity. 'full' (default) returns errors[] and warnings[]; 'summary' returns a token-frugal verdict { standard, valid, errorCount, warningCount, summary } and drops the message arrays.",
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "type": "string"
+}

First observedv1.1.0Jun 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, but the description adds substantial behavior beyond them: what is deliberately not checked (fonts, colour, rendering), the caveats[] return for PDF/X, and the concrete failure mode 'PDF_PARSE_FAILED' for unparsable input.

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?

Dense but front-loaded: the core role and the standard switch come first, followed by per-standard detail, result shape, and limitations. Every clause carries information, though the single block is heavy enough that some trimming or line breaks would improve scanability.

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?

Given an output schema exists, the description need not explain returns, yet it still summarizes the result shape and caveats[]. Combined with coverage of both standards, generation prerequisites, limitations, and the parse-failure code, an agent has everything needed to call it correctly.

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 baseline is 3, but the description still adds value by spelling out the ISO numbers and the exact rule contents behind each 'standard' enum value, plus the default. It does not add much beyond the schema for 'fields' or 'verbosity', keeping it at a 4.

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+resource ('structural gate') and enumerates exactly what each standard validates (PDF/UA tags, PDF/X-4 OutputIntent/fonts/annotations). It is clearly distinguishable from siblings like inspect_pdf or verify_pdf, which are not described in these structural-conformance terms.

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?

States when to pick each standard, that input should be generated first with the pdfA/pdfx tools (e.g. 'pdfa2u', 'pdfx4'), and explicitly routes agents needing deeper validation to veraPDF/callas/Acrobat. It also bounds scope with 'NOT a reference validator or a certified preflight'.

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