pdfnative-mcp

Verify PDF signatures

verify_pdf

Read-onlyIdempotent

Check every PDF signature for integrity, signer certificate, and trust chain, plus RFC 3161 timestamps, returning per-signature valid/invalid verdicts.

Instructions

Read-only verification of every signature: ByteRange digest vs CMS messageDigest (integrity), CMS signatureValue vs the embedded signer certificate (RSA-SHA256/384/512, ECDSA P-256), chain trust when trustedRootsDerBase64 is given ('self-signed' | 'unverified' | 'trusted' otherwise). /DocTimeStamp entries are verified as RFC 3161 tokens and count in allValid like any signature. Result: { allValid, signatureCount, summary, signatures:[{ valid, integrity, signerSubject, signingTime, chainTrust, errors[] }] }. ltv:true adds the PAdES view: per-signature profile, timestamp, revocation (read from embedded /DSS only — responder signatures are not re-verified) and ltvLevel B-B / B-T / B-LT / B-LTA with explicit caveats. Token-frugal: verbosity:'summary', fields:['allValid'].

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ltv`	No	Add the PAdES view: per signature profile, timestamp, revocation (embedded /DSS only), ltvLevel (B-B / B-T / B-LT / B-LTA); document-level dss, ltvLevel, caveats.
`fields`	No	Optional dot-path projection applied to the structured result (e.g. ['allValid'] or ['signatures.valid']). Composes after verbosity. Unknown paths are omitted.
`password`	No	Password (user or owner) of an encrypted source. Never logged or echoed.
`pdfBase64`	Yes	Base64-encoded PDF bytes to verify.
`verbosity`	No	Response verbosity. 'full' (default) returns the per-signature signatures[] array; 'summary' returns a token-frugal verdict { signatureCount, allValid, invalid, summary } (+ ltvLevel when ltv:true) and drops signatures[], dss and caveats.	full
`trustedRootsDerBase64`	No	Optional list of base64-encoded X.509 root certificates (DER). When supplied, each signer certificate is validated against these roots; otherwise chainTrust is reported as self-signed or unverified.

Output Schema

TableJSON Schema

Name	Required	Description
`dss`	No	ltv only. Document Security Store summary, or null when the catalog has no /DSS.
`caveats`	No	ltv only. Fixed statements about what the LTV evaluation does not cover.
`invalid`	No	summary only: number of invalid signatures.
`summary`	No
`allValid`	No	true when the document carries at least one signature and every entry of signatures[] — CMS signatures and /DocTimeStamp tokens alike — is valid (integrity + signature check + chain trust when trustedRootsDerBase64 is given). A tampered document timestamp fails the verdict; a sound one never does.
`ltvLevel`	No	ltv only. Minimum level across non-timestamp signatures ('B-B' when there are none).
`signatures`	No
`signatureCount`	No

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. ['allValid'] or ['signatures.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 the per-signature signatures[] array; 'summary' returns a token-frugal verdict { signatureCount, allValid, invalid, summary } and drops signatures[].",
+  "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 description goes beyond the readOnlyHint and idempotentHint annotations by explaining exactly what is verified, how chainTrust is determined, how /DocTimeStamp is treated, and what ltv:true does. It also includes important caveats such as embedded /DSS-only revocation data and the fact that responder signatures are not re-verified. This gives the agent a strong model of the tool's behavior before invoking it.

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 dense but well structured, front-loading the core verification purpose and then layering optional modes. Every sentence adds meaningful information, and the structured result shape and token-frugal guidance are presented in compact, scannable form.

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 the tool's complexity, the input schema, annotations, and output schema, the description covers the essential semantic, behavioral, and output-critical details. It explains verification scope, trust behavior, timestamp handling, LTV caveats, and result shapes well enough for an agent to decide whether to call it and what to expect.

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?

The schema already documents all six parameters with high coverage, so the baseline is solid. The description adds genuine semantic value by explaining the effect of trustedRootsDerBase64, the LTV behavior tied to ltv:true, and the token-frugal interaction between verbosity and fields.

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 states a precise operation: read-only verification of every PDF signature, including integrity, signature value, chain trust, timestamps, and PAdES LTV behavior. It clearly distinguishes the tool's scope from generic PDF validation by enumerating specific verification mechanics and output fields.

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?

The description makes the tool's purpose and behavior easy to infer: it is for signature-specific verification, with optional LTV analysis. However, it does not explicitly tell the agent when to choose verify_pdf over sibling tools like validate_pdf or inspect_pdf, nor does it state any exclusions. Usage context is implied rather than directly described.

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