MCP server that reads C2PA Content Credentials: what an image declares about its own origin, and whether that declaration still verifies
Two well-named, focused tools with excellent descriptions (200+ chars each) that clearly explain what they do, when to use them, and critical limitations. Input schemas are present with typed parameters and descriptions. However, output schemas are not documented in the visible code, and error handling guidance is minimal. Tool names follow verb_noun pattern (check_*, scan_*) and are unambiguous. Descriptions are LLM-optimized and include guardrails about what the tools cannot do, a strength. Missing: explicit output schema documentation, error recovery guidance, and parameter constraints (e.g., limit bounds).
Read the C2PA Content Credential embedded in a single image file and report what it declares about the image's origin: whether it asserts AI generation or a real-world capture, and whether that assertion's cryptographic signature still verifies. This reads metadata the file already carries; it does not analyze pixels and cannot detect AI generation on its own. A missing or invalid credential is not evidence the image is human made, an AI image loses its credential the moment it is screenshotted or re-saved. Always read the result's 'what_this_does_not_mean' field before repeating its verdict.
Walk a directory of images and report how many carry a C2PA Content Credential, broken down by verdict (AI_DECLARED, NO_AI_DECLARED, UNKNOWN) and by signer. This reproduces the sweep behind this project's own finding that roughly 96.5% of real images carry no credential at all. It reads only file metadata, never pixels, and touches no network. Returns counts and a capped sample of credentialed files, not a full file listing, so a large directory does not flood the response. If the directory has more images than 'limit', the scan is partial and the result says so explicitly rather than silently truncating.
Output schemas not documented. Tool descriptions explain what is returned (counts, verdicts, signer info) but the actual JSON structure is not formally specified. LLMs cannot plan downstream operations without knowing field names and types.
No error handling guidance. Descriptions do not explain what happens if the file is unreadable, unsupported format, or permission denied. LLMs have no recovery path.
scan_directory 'limit' parameter lacks bounds documentation. Description says 'Maximum number of image files' but does not specify min/max values or what happens if exceeded. The description mentions 'partial' results but does not formalize the constraint.
check_image_provenance 'path' parameter accepts only local file paths. No guidance on absolute vs relative paths, symlink handling, or permission requirements. LLMs may pass invalid paths.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
No pagination or result-limiting guidance for scan_directory. If a directory contains millions of images, the tool may return a very large response. The description mentions a 'capped sample' but does not specify the cap or how to iterate.