MCP server for PDF authenticity verification - cryptographic signature verification, tamper detection, PAdES level detection
Strong domain-specific tool design with clear, detailed descriptions (avg 180 chars) and comprehensive parameter documentation. All 7 tools have explicit schemas with typed inputs. Naming follows verb_noun pattern (verify_*, validate_*, detect_*, identify_*, evaluate_*). However, output schemas are not documented in the source code provided, and error handling guidance is absent. Tool composition is excellent, each tool has a single, well-defined responsibility aligned with PDF verification workflows. The server includes exceptional instructions explaining the epistemological limits of verification (T1/T2/T3 framework), which is rare and valuable for LLM reasoning.
PAdES level detection - identifies the PAdES (PDF Advanced Electronic Signatures) level of signatures based on structure analysis
Policy evaluation - evaluates document against a policy rule engine to produce a deterministic verdict (trust_and_use / use_with_caution / human_review_required / reject)
Conformance declaration identification - identifies PDF/A, PDF/UA, and other conformance declarations in the document
Clause validation - validates PDF structure against ISO 32000-1/-2 clauses using bundled constraints
Conformance validation - validates PDF/A conformance using veraPDF or native validation engine
Tamper detection - verifies document integrity, checks for incremental updates, signature coverage, and revision chain consistency
Output schemas not documented. Tool descriptions explain what is returned conceptually (e.g., 'produces a deterministic verdict'), but the JSON structure of responses is not specified in the source code provided. LLMs cannot plan downstream tool calls or extract fields without knowing the response schema.
No error handling guidance in tool descriptions. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do if a call fails. E.g., verify_signatures does not explain what happens if the PDF is malformed or if trust anchors are invalid.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Cryptographic signature verification - verifies digital signatures in PDF documents, checks signature validity, certificate trust, and revocation status
Parameter 'trustAnchors' in verify_signatures and evaluate_policy lacks format specification. Description says 'array of trust anchor certificates in PEM format' but does not clarify: is each element a string? What if the PEM is invalid? Should the tool fail or skip invalid anchors?
validate_conformance 'flavour' parameter is optional but its valid values are not enumerated. Description says 'Optional PDF/A flavour' but does not list valid options (e.g., 1a, 1b, 2a, 2b, 3a, 3b). LLMs will hallucinate invalid values.
validate_clauses 'subjects' parameter is underdocumented. Description says 'Optional array of constraint subjects to validate' but does not explain what a 'subject' is, what valid values are, or what happens if an invalid subject is passed.