pdfnative-mcp

Validate PDF/UA structure

validate_pdf

Read-onlyIdempotent

Check PDF/UA-1 (ISO 14289-1) structural conformance: marked content, structure tree, metadata, language, per-page MCID uniqueness. Returns verdict with errors, warnings, and summary.

Instructions

Read-only PDF/UA-1 (ISO 14289-1) structural gate for Tagged PDF: /MarkInfo /Marked, /StructTreeRoot (+ /ParentTree), XMP /Metadata, /Lang, per-page MCID uniqueness. Result { standard:'pdf-ua-1', valid, errors[], warnings[], summary }. Fast and structural only — NOT a reference validator (veraPDF): fonts, colour and rendering are not checked. Unparsable input → PDF_PARSE_FAILED. Generate tagged input with pdfA (e.g. 'pdfa2u') first.

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.
`pdfBase64`	Yes	Base64-encoded PDF bytes to validate for PDF/UA (ISO 14289-1) 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 PDF/UA conformance violations. Empty when valid is true.
`summary`	No	Human-readable one-line summary of the result.
`standard`	No	Conformance standard checked (ISO 14289-1).
`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.

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.5/5.0

Behavior5/5

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

The annotations already declare read-only, idempotent, non-destructive, and limited open-world semantics; the description adds specific behavioral detail by listing the exact inspection points (MarkInfo, StructTreeRoot, ParentTree, XMP Metadata, Lang, MCID uniqueness). It also discloses the denfinite error condition: 'Unparsable input → PDF_PARSE_FAILED', and clearly states scope limits and fonts/color/rendering are not checked. This goes well beyond what the annotations provide.

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 compact yet information-dense with every sentence earning its place: it states the exact checks, the result shape, the error behavior, the limitations, and the intended workflow. It reads well and front-loads the most important 'structural gate' phrase.

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 annotations, a fully documented input schema, and an output-like result shape in the description, the agent has everything needed to call this tool correctly. The description also mentions 'Generate tagged input with pdfa first' to tie the surrounding workflow, and gives the precise response shape 'valid, errors[], warnings[], summary'.

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?

The input schema already documents all three parameters descriptions: pdfBase64 with base64 details, verbosity with default/enum, and fields with projection behavior. Schema description coverage is 100%, so the baseline applies. The tool description adds no additional parameter-level meaning, but none is necessary.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the operation ('validate'), the resource ('PDF/UA structure'), and the exact standard ('PDF/UA-1 ISO 14289-1'), and enumerates the structural checks it performs. It distinguishes itself from a reference validator: 'NOT a reference validator (veraPDF): fonts, colour and rendering are not checked'. However, it does not explicitly differentiate itself from sibling tools like verify_pdf or inspect_pdf by name.

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 explicit when-to-use guidance: 'Read-only PDF/UA-1 structural gate' and 'fast and structural only'. It also states a clear exclusion: 'NOT a reference validator:' fonts, colour and rendering are not checked, so the agent knows when not to rely on it. The workflow hint 'Generate tagged PDF with pdfA first' provides a useful conditional prerequisite.

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