attest-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| IMGAUTH_API_KEY | No | API key credential, bypasses the device flow. | |
| IMGAUTH_BASE_URL | No | Override for local development (http://localhost:8787). | https://imgauth.spaziogenesi.org |
| IMGAUTH_CERT_PAGE_BASE | No | Override for the permanent-certificate-page base URL. | https://attestazione.spaziogenesi.org |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| authorizeA | Start or continue the device-flow authorization. Call with no arguments to begin: show the returned verification_url to the human and ask them to open it and approve. Then call again passing the same |
| attest_fileA | Compute the SHA-256 fingerprint of a local file (streamed, never sent anywhere) and attest it: the server timestamps it and returns a signed attestation. Requires a credential — run 'authorize' first, or set IMGAUTH_API_KEY. Optional declared metadata (titolo/autore/anno/note) is bound to the signature. |
| get_certificate_pdfA | Get the signed certificate PDF for an attested work, saving it to a local file. Pass |
| verify_fileB | Compute the SHA-256 of a local file and check it against a declared hash/attestation, plus verify the HMAC signature server-side (no file bytes are ever sent). Pass the fields as read from the certificate (hash, attestazione, hmac, and any declared titolo/autore/anno/note). |
| verify_certificateA | Verify the HMAC signature of a certificate's attestation (+ declared metadata, if any) without checking against any local file. Confirms authenticity and integrity of the declared data, not that a given file matches. |
| check_anchorB | Check whether a fingerprint has an OpenTimestamps proof, optionally saving the .ots proof file to disk. |
| service_statusA | Get the traffic-light status of the attestation service (worker, archive, signer, Bitcoin anchor). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool serves a distinct purpose: authorization, attestation, verification, certificate retrieval, anchor checking, and service status. No overlap or ambiguity.
Most tools follow verb_noun pattern (attest_file, check_anchor, get_certificate_pdf, verify_certificate, verify_file), but 'authorize' is a bare verb and 'service_status' is noun_noun, introducing minor inconsistency.
Seven tools cover the core workflow without being excessive. The scope is well-defined for an attestation service.
The set covers authorization, attestation, verification, certificate retrieval, anchor checking, and service status. Missing update/delete for attestations, but those are atypical for immutable attestations.