Skip to main content
Glama
shuji-bonji

pdf-verify-mcp

by shuji-bonji
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Detect PAdES Baseline Level

detect_pades_level
Read-onlyIdempotent

Determine which PAdES baseline level each PDF signature's structure matches, from B-B to B-LTA, to check long-term validation (LTV) readiness or audit archived contracts.

Instructions

Observe which PAdES baseline level (ETSI EN 319 142) the structure of each signature matches.

This is an observation, not a conformance verdict. ETSI EN 319 142 is not in this family's spec corpus, and unlike PDF/A there is no third-party validator to delegate to — so the result says "the structure matches B-LT", never "conforms to PAdES B-LT". Every report carries normativeBasis: "T3" to make that explicit.

Detection is structural: B-B (CAdES signature), B-T (+ RFC 3161 signature timestamp), B-LT (+ DSS with validation data), B-LTA (+ document timestamp). Legacy adbe.pkcs7.detached signatures are reported as non-PAdES.

Args:

  • file_path (string): Absolute path to a local PDF file

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: An object of the form { scope, levels: [...] }. The top level changed from an array to an object in v0.21.0 - read .levels for the list.

Size (v0.29.0): at most 32 signatures are listed; levelsTruncated = { returned, total } says when the list was cut. JSON is never cut by length.

Every report begins with a "scope" object - how far the reading got, not a verdict: whether the cross-reference chain could be walked to the end (chainStop), whether this tool had to rebuild the cross-reference table itself (reconstructed - when true, the table is this tool's reconstruction and not the one the file carries), how many objects and sections were read, and whether an encrypted document could be opened. Read it before the verdict: "no violations" over a rebuilt table is not the same statement as "no violations" over the file's own table.

Per-signature level with evidence (signature timestamp, DSS, VRI, document timestamp presence).

Note: B-LT / B-LTA additionally require that the DSS revocation data actually covers the signer certificate (content-level LTV validation); otherwise the level is capped at B-T.

Examples:

  • Check if a signature is long-term validation (LTV) enabled

  • Audit whether archived contracts meet B-LTA requirements

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.29.1

TDQS

A4.4/5.0
Behavior5/5

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

Even with readOnlyHint and idempotentHint annotations, the description adds substantial behavioral detail: the structural detection ladder, legacy adbe.pkcs7.detached handling, normativeBasis 'T3', scope object semantics, cross-reference table reconstruction caveats, truncation behavior, and LTV capping rules. It clarifies exactly how results should be interpreted, which far exceeds what the annotations convey.

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?

The description is long but well-organized and front-loaded: purpose first, then the critical observation-versus-verdict caveat, followed by technical details, arguments, return shape, and examples. The Args block is somewhat redundant with the schema, but the density is justified given that there is no output schema and the tool has nuanced interpretation semantics.

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 no output schema, the description carries the full burden of explaining what the tool returns, and it does so thoroughly: top-level object shape, .levels, levelsTruncated, scope object fields, per-signature evidence, and the LTV cap. It also covers edge cases like reconstructed cross-reference tables, encrypted documents, and legacy signatures, making the tool safely callable and interpretable.

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 schema already covers both parameters with 100% coverage, so the baseline of 3 applies. The description's Args section mostly repeats the schema (absolute path, markdown/json default) and adds little new semantic meaning about the parameters themselves, though it does tie response_format to output behavior like JSON never being length-truncated.

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 opening sentence states a specific action ('Observe which PAdES baseline level...') on a specific resource ('the structure of each signature'), immediately grounding the tool's purpose. It also distinguishes itself from conformance validation by explicitly saying 'This is an observation, not a conformance verdict,' which separates it from siblings like validate_conformance.

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 clear use cases ('Check if a signature is long-term validation (LTV) enabled', 'Audit whether archived contracts meet B-LTA requirements') and strongly warns against treating results as conformance verdicts. It does not explicitly name sibling tools or state 'use X instead', but the observation-versus-verdict framing and examples provide clear contextual guidance.

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