Skip to main content
Glama
shuji-bonji

pdf-verify-mcp

by shuji-bonji
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Evaluate Trust Policy (deterministic verdict)

evaluate_policy
Read-onlyIdempotent

Generate a reproducible trust verdict for a PDF—trust_and_use, use_with_caution, human_review_required, or reject—by running signature, integrity, PAdES, and conformance checks through a fixed rule table.

Instructions

Produce a deterministic 4-value trust verdict (trust_and_use / use_with_caution / human_review_required / reject) for a PDF.

Runs verify_signatures, verify_integrity and detect_pades_level internally (plus validate_conformance for long-term-preservation profiles) and folds the facts through a fixed rule table — the same facts and profile always yield the same verdict. The verdict is decided entirely by code; use the returned firedRules/advisories to explain the outcome, never to override it. It judges authenticity and integrity only, never the truth of the document's content.

Args:

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

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

  • profile ('general' | 'contract' | 'financial' | 'legal' | 'medical' | 'government'): Judgment profile (default: 'general')

  • trust_anchors (string[], optional): Trust anchor certificate paths. Without them, signer identity stays not_evaluated and the verdict is capped at use_with_caution

  • check_revocation ('none' | 'embedded' | 'online'): Revocation mode (default: 'embedded')

  • revocation_freshness (integer seconds, default 86400): How long before the validation time a CRL / OCSP response may have been issued and still count as "good"

  • trusted_ocsp_responders (string[], optional): Certificates of locally trusted OCSP responders (RFC 6960 §4.2.2.2)

  • password (string, optional): Password for an encrypted PDF

Returns: 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.

Size (v0.29.0): the verdict is computed over EVERY signature; facts.signatures lists at most 32 of them and facts.signaturesTruncated = { returned, total } says when it was cut. JSON is never cut by length.

verdict, firedRules (rule IDs with per-rule verdict and reason), advisories (recommendations that do not affect the verdict), and the underlying facts summary.

Examples:

  • Gate incoming invoices before filing them (profile: financial)

  • Decide whether a countersigned contract can be relied on (profile: contract, with the counterparty CA as trust anchor)

  • Batch-audit a folder of received PDFs with a reproducible, model-independent verdict

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
profileNoJudgment profile: "general" (default thresholds), "contract" (signature required, identity-focused), "financial" (long-term preservation checks), "legal", "medical" (most conservative; caution escalates to review), "government" (long-term checks, unsigned tolerated).general
passwordNoPassword for an encrypted PDF. Omit for permission-encrypted PDFs (an empty user password is tried automatically).
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
trust_anchorsNoAbsolute paths to trust anchor certificates (PEM or DER). Merged with the PDF_VERIFY_TRUST_ANCHORS environment variable. Without anchors, valid signatures are capped at use_with_caution (identity not evaluated).
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown
check_revocationNoRevocation checking: "none", "embedded" (default), or "online" (queries OCSP/CRL endpoints over HTTP).embedded
revocation_freshnessNoSeconds before the validation time that a CRL / OCSP response may have been issued (thisUpdate) and still support "good". Default 86400 (24 h); 0 accepts only data issued at or after the validation time. Older data gives "unknown".
trusted_ocsp_respondersNoAbsolute paths to certificates (PEM or DER) of locally trusted OCSP responders (RFC 6960 §4.2.2.2). A response signed by one of them is accepted even when the responder is not the issuing CA or its delegate.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.29.1

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds meaningful behavioral detail: verdicts are deterministic and code-decided, firedRules/advisories are explanatory not overridable, the scope object must be read before the verdict, reconstructed xref tables change the meaning of results, and signature lists can be truncated but JSON is not. No contradiction with annotations.

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 text is long but structured into Purpose, Args, Returns, and Examples, and each section serves a clear need for a tool of this complexity. The core purpose is front-loaded, and the return-value caveats are grouped rather than scattered. No sentence is purely 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?

There is no output schema, so the description correctly takes responsibility for explaining return semantics. It covers the scope object, verdict, firedRules, advisories, truncation behavior, and the reconstructed-table caveat. Given the tool's 18 parameters and complex behavior, nearly everything an agent needs to select and invoke it correctly is present.

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%, and the Args section largely restates the schema's parameter meaning. The description does add some contextual significance, such as trust anchors capping the verdict and revocation freshness affecting 'good' status, but those points are also present in the schema. This is the baseline case where structured data already does the heavy lifting.

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 opens with a specific verb and outcome: 'Produce a deterministic 4-value trust verdict... for a PDF.' It also differentiates itself from lower-level siblings by stating that it runs verify_signatures, verify_integrity, and detect_pades_level internally, so the agent knows this is the policy-level aggregation tool, not a raw verifier.

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 examples give concrete use cases (gating invoices, deciding on countersigned contracts, batch-auditing), and the description clarifies it is not a content-truth tool. It names the internal verifiers as components rather than alternatives, but does not explicitly say 'use verify_signatures when you need raw signature details,' so explicit when-not guidance is slightly incomplete.

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