A
licenseA
qualityD
maintenanceMCP server for AI agent trust verification, enabling agents to verify identities, check trust scores, and build reputation across multiple blockchain and web platforms.
12
5 npm
1
MIT
attest-mcp
The attest-mcp server provides tools to privately attest, verify, and manage proof-of-existence for digital works using SHA-256 fingerprinting, signed certificates, and Bitcoin anchoring — all without ever uploading your file bytes to any server.
Authorize: Initiate or continue a device-flow authentication session (or use an API key) to gain access to attestation services.
Attest a file: Compute a SHA-256 fingerprint of a local file (streamed locally, never uploaded) and submit it to the attestation service, which timestamps and cryptographically signs it (HMAC). Optional metadata (title, author, year, notes) can be bound to the signature.
Get a certificate PDF: Mint a fresh signed PDF certificate immediately after attestation, or recover a previously archived certificate using just the file's hash. Includes an RFC 3161 timestamp and Bitcoin anchor reference.
Verify a file: Hash a local file and compare it against a declared hash, attestation string, and HMAC signature from a certificate — confirming integrity and authenticity.
Verify a certificate: Validate the HMAC signature of an attestation and its declared metadata without needing the original file.
Check Bitcoin anchor: Determine if an OpenTimestamps proof exists for a specific SHA-256 hash and optionally download the
.otsproof file.Check service status: Get a real-time traffic-light health report on the attestation service components (worker, archive, signer, anchor).
Anchors file attestation timestamps on the Bitcoin blockchain via OpenTimestamps proofs, providing immutable proof of existence.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@attest-mcpattest this PDF and get the certificate"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
attest-mcp
Listed on the official MCP Registry as
io.github.SPAZIO-GENESI/attest-mcp.
MCP server and CLI for Spazio Genesi's attestation service — attest, verify, and check the existence of digital works from any MCP-capable AI agent (Claude Code, Claude Desktop, etc.) or straight from a terminal / CI pipeline.
Full privacy: file bytes never leave your device. The fingerprint (SHA-256) is computed locally, streamed from disk — only the hash and optional metadata are sent.
📖 English documentation: attestazione.spaziogenesi.org/en — site, developer docs, and tiers/terms are all available in English.
What it does
The attestation service timestamps a file's SHA-256 fingerprint, signs it (HMAC), and can produce a signed PDF certificate plus an OpenTimestamps proof anchored in Bitcoin. This server exposes that service as MCP tools, so an agent can attest and verify works on your behalf without a browser.
Related MCP server: AgentLedger
Why this, not just an OpenTimestamps wrapper
Several MCP servers can submit a hash to an OpenTimestamps calendar. As far as we know, this is the only one that hands back a complete proof of existence — a signed PDF certificate, a recognized RFC 3161 timestamp, and a Bitcoin anchor — for free, with the file's bytes never leaving the caller's machine. No account, no upload, no paid notarization chain. If you know of another MCP server with the same combination (full certificate + free + local hashing), we'd genuinely like to hear about it — open an issue.
Built for the European legal and regulatory context
Spazio Genesi is an Italian non-profit (ETS – Ente del Terzo Settore). The attestation service behind this package was designed with the EU regulatory environment in mind, not adapted to it afterwards:
GDPR-first, privacy by design: the file itself never reaches our servers — only its SHA-256 fingerprint (and any metadata you choose to declare) is sent.
EU data residency: certificates and proofs are archived on Cloudflare R2 under EU jurisdiction.
Recognized timestamping, no single point of trust: every certificate carries an RFC 3161 timestamp from an AATL-rooted authority (trusted by Adobe and most PDF readers) and an independent Bitcoin anchor via OpenTimestamps.
Honest about eIDAS: this is not (yet) an eIDAS qualified trust service — the signer identity is currently self-signed, and a qualified electronic seal is a planned but unimplemented upgrade. See the technical whitepaper for the full, unvarnished breakdown of what is and isn't guaranteed.
Full tiers and terms: attestazione.spaziogenesi.org/en/condizioni.
Install
Claude Desktop — one command, no manual JSON editing:
npx -y @spazio-genesi/attest-mcp-setupThis finds your claude_desktop_config.json (Windows/macOS/Linux), adds the
attest-mcp entry, and backs up the original file first. It refuses to touch
anything if the existing file isn't valid JSON — it never guesses. Restart
Claude Desktop afterwards. To remove it again: add --uninstall. To preview
without writing: add --dry-run.
Claude Code:
claude mcp add attest-mcp -- npx -y @spazio-genesi/attest-mcpManual / other clients — add this to your MCP client's config:
{
"mcpServers": {
"attest-mcp": {
"command": "npx",
"args": ["-y", "@spazio-genesi/attest-mcp"]
}
}
}Authentication
Two ways to authenticate, matching the underlying service:
API key (for partner integrations, issued manually by Spazio Genesi): set the
IMGAUTH_API_KEYenvironment variable.Device flow (for personal/agent use): call the
authorizetool with no arguments. It returns a URL — open it, approve with the human-verification widget, then callauthorizeagain with the returned code. The session token (24h, 20 attestations) is saved to~/.config/attest-mcp/credentials.json(permissions600where supported) and used automatically after that.
Either way, the credential only unlocks the anti-bot check on attestation — the server-side timestamp, cryptographic signature, and rate limits are unchanged.
Tools
Tool | What it does |
| Start or continue the device-flow authorization. |
| Hash a local file (streamed) and attest it. |
| Mint a fresh signed PDF, or recover an already-archived one, saved to disk. |
| Hash a local file and check it against a declared hash + signature. |
| Verify a certificate's signature without a local file. |
| Check/download the OpenTimestamps (Bitcoin) proof. |
| Traffic-light status of the attestation service. |
CLI (sg-attest)
Same package, no separate install. The CLI is a bin alongside the MCP server,
sharing the same hashing/API/config code — same full privacy (streamed local
hash, file bytes never sent), same credentials.
npx -y -p @spazio-genesi/attest-mcp sg-attest attest ./work.png
npx -y -p @spazio-genesi/attest-mcp sg-attest verify ./work.png --hash <sha256>(-p is required: sg-attest is a secondary bin of the package, and plain
npx -y @spazio-genesi/attest-mcp runs the MCP server instead.)
One advantage over the site: no 1 GB cap. The browser is limited by WebCrypto (which loads the whole file into memory); this CLI streams from disk on Node, so it can attest files of any size.
Command | What it does | Credential |
| Hash locally (streamed) → attest → print fingerprint, attestation, HMAC. Nothing is archived and no | Yes |
| Hash locally; with | No |
| Verifies a certificate's HMAC signature, no local file involved | No |
| Recovers an already-archived certificate | No |
| Checks/downloads the OpenTimestamps (Bitcoin) proof | No |
| Traffic-light status of the service | No |
| Device flow: prints a URL to approve, polls, saves the token | — |
| Version (from | — |
Every command accepts --json (emits one JSON object on stdout, for scripting)
and --quiet (reduces non-essential human-readable output). Errors go to
stderr; the CLI never prints a credential (API key or session token) to
stdout, stderr, or --json output — same discipline as the MCP server.
Exit codes (a stable contract, for CI/scripting):
Code | Meaning |
| Success / positive outcome |
| Operational error (network, auth, bad input) |
| Negative verification outcome (hash mismatch, invalid signature) |
Authentication is the same as the MCP server: IMGAUTH_API_KEY env var, or a
session token saved by sg-attest authorize (device flow). There is no
--key flag — a credential on the command line ends up in shell history; use
the env var (or a CI secret) instead.
A GitHub Action that uses this CLI to attest build artifacts in CI lives in a
companion repo: attest-action.
Standalone binaries (no Node required)
For a machine or CI runner without Node.js, download a pre-compiled sg-attest
executable from the Releases page —
same commands, same behavior, nothing to install.
OS | Architecture | File |
Linux | x64 |
|
Linux | arm64 |
|
macOS | Intel |
|
macOS | Apple Silicon |
|
Windows | x64 |
|
Windows | ARM64 |
|
Each release also includes SHA256SUMS.txt. Verify the download before running it:
sha256sum -c SHA256SUMS.txt --ignore-missing # Linux/macOS(Get-FileHash .\sg-attest-windows-x64.exe -Algorithm SHA256).Hash # compare by eye to SHA256SUMS.txt⚠️ The binaries are not code-signed: expect an "unknown publisher" warning from Windows SmartScreen or macOS Gatekeeper the first time you run one. The checksum above is the integrity guarantee in the meantime — the binary is built and published by GitHub Actions directly from this repo's source, nothing hand-uploaded.
Usage is identical to the npm-installed CLI, just call the file directly:
chmod +x ./sg-attest-linux-x64 # Linux/macOS only
./sg-attest-linux-x64 attest ./work.png --pdf cert.pdf
./sg-attest-linux-x64 statusnpx/npm remain the primary distribution channel (and what attest-action
uses in CI) — the binaries are an additional channel, not a replacement.
Build provenance (SLSA/in-toto)
The checksum above answers "is this file intact?" — it says nothing about
where the bytes came from. Every release since v0.4.2 also carries a
signed build provenance attestation
(actions/attest-build-provenance, job release in
release-binaries.yml): cryptographic
proof that the file was built by this repo's own workflow, from a specific
commit and tag, not hand-uploaded or swapped afterward.
The GitHub CLI can verify it, but gh attestation verify requires an
authenticated gh session even on this public repo (confirmed: it fails
with "please run gh auth login" without one) — a real gap if the point is a
check anyone can run with zero setup:
gh attestation verify sg-attest-linux-x64 --repo SPAZIO-GENESI/attest-mcpscripts/verify-provenance.mjs does the same
verification with no GitHub credentials at all — only the public
attestations REST endpoint (confirmed reachable unauthenticated, even on this
public repo) and the sigstore
library, which checks the signature against Sigstore's own public
infrastructure (Rekor, Fulcio, TUF — no account needed there either):
git clone https://github.com/SPAZIO-GENESI/attest-mcp
cd attest-mcp && npm install
node scripts/verify-provenance.mjs ./sg-attest-linux-x64 \
--repo SPAZIO-GENESI/attest-mcp --tag v0.4.2Exits 0 on success, 1 if the file doesn't match anything the workflow
actually built (e.g. a single altered byte makes the digest — and therefore
the lookup key itself — no longer match any attestation).
Configuration
Env var | Default | Purpose |
| — | API key credential, bypasses the device flow. |
|
| Override for local development ( |
|
| Override for the permanent-certificate-page base URL. |
Troubleshooting
If your client reports "Server disconnected", check its log first: this server
writes diagnostics to stderr, which MCP clients capture. On Claude Desktop the log
lives in %APPDATA%\Claude\logs\mcp-server-attest-mcp.log (Windows) or
~/Library/Logs/Claude/mcp-server-attest-mcp.log (macOS).
You should see one line per lifecycle event:
[attest-mcp 2026-07-21T11:14:12.948Z] v0.2.2 ready on stdio (node v22.22.2, pid 32316)
[attest-mcp 2026-07-21T11:14:12.965Z] exiting (code 0)exiting (code 0)— ordinary shutdown: the client closed stdin. After a laptop sleep or a client restart this is expected; just restart the client to reconnect.fatal: …followed byexiting (code 1)— a real crash, with the stack trace on the preceding line. Please open an issue with it.No
readyline at all — the process never started: check thatnodeis on PATH and at least v18 (node --version).
stdout carries the JSON-RPC protocol and is never used for logging.
Known limitation
The certificate PDF and its text are in Italian (Spazio Genesi is an Italian non-profit and the certificate is a legal-facing document). The MCP tool descriptions and this README are in English for an international audience.
Development
npm install
npm test # unit tests (hash vectors, CLI argument parsing)
IMGAUTH_BASE_URL=http://localhost:8787 npm start # MCP server against a local `wrangler dev`
IMGAUTH_BASE_URL=http://localhost:8787 node src/cli.js status # CLI against the sametest/cli-smoke.local.mjs is a local-only harness (not run by npm test) that
exercises every sg-attest command end-to-end against an isolated wrangler dev
imgauth instance — see the header comment in that file for the required env vars.
Security
Report vulnerabilities → /sicurezza/
(responsible disclosure policy, safe harbor for good-faith research) — this
repo has no security.txt of its own (npm package, no static assets), but
the policy covers the whole project.
Contributing
Bug reports and feature requests: open an issue.
Pull requests are welcome — keep them focused (one change per PR), make sure
npm test passes, and explain the "why" in the description, not just the
"what". Test policy: any PR that adds new functionality should add a test
for it under test/; npm run lint and npm test both run in CI on every
push and pull request. For anything that touches the attestation contract itself (hashing,
HMAC verification, the API surface), open an issue first: this client mirrors
a contract owned by imgauth, so
changes need to stay compatible with it.
License
MIT — see LICENSE. This is a client for the attestation service; the service itself (imgauth) is AGPL-3.0.
Available Tools
7 toolsattest_fileAttest a 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| anno | No | Declared year/version (optional). | |
| note | No | Declared free-text note (optional). | |
| path | Yes | Absolute or relative path to the local file. | |
| autore | No | Declared author (optional). | |
| titolo | No | Declared title of the work (optional). |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavior: file is streamed and never sent, server timestamps and returns signed attestation. With no annotations, description covers privacy and output adequately, though missing details on error handling or rate limits.
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?
Two sentences, no filler. Front-loaded with main action and key constraints (streamed, credential needed). Every sentence adds value.
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?
Covers auth, privacy, output (signed attestation), and optional metadata. No output schema, but description sufficiently describes return. Complete for a file attestation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by explaining that optional metadata (titolo/autore/anno/note) is bound to the signature, going beyond schema descriptions.
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?
Clearly states the tool computes SHA-256 fingerprint and attests it with timestamp and signed attestation. Distinguishes from siblings like 'verify_file' and 'authorize' by specifying the core action.
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?
Explicitly mentions prerequisite credential (run 'authorize' first or set IMGAUTH_API_KEY). Provides context on when to use, though does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
authorizeAuthorize this agentA
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 code, a few seconds apart, until status is 'approved' (token saved automatically) or 'expired' (start over). Grants 20 attestations for 24 hours.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | The code from a previous authorize call, to resume polling. |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description fully discloses behavior: device flow, polling pattern, token auto-save, 20 attestations for 24 hours. No hidden surprises.
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?
Three sentences, no wasted words. Front-loaded with main purpose, then step-by-step flow. Ideal length for quick consumption.
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?
No output schema, but description explains possible statuses and implication (token saved or expired). Covers the entire lifecycle. Siblings are unrelated, so no missing comparative context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter with description, and the description adds context about polling and resuming. With 100% schema coverage, baseline is 3, but description adds value explaining usage flow.
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 clearly states the action ('start or continue device-flow authorization') and specifies the resource ('device-flow authorization'). It distinguishes from siblings which are unrelated (e.g., attest_file, verify_certificate).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit instructions: call with no arguments to begin, then poll with the same code a few seconds apart. Defines when to stop ('approved' or 'expired'). No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_anchorCheck the Bitcoin anchoring proofB
Check whether a fingerprint has an OpenTimestamps proof, optionally saving the .ots proof file to disk.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | The SHA-256 fingerprint. | |
| save_to | No | Local file path to save the .ots proof to, if it exists. |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It hints at read-only check ('check whether') but also mentions optional file save, which is a side effect. Does not disclose error behavior, return format, or authorization needs.
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?
Single sentence, front-loaded with key action. No wasted words. Could be slightly more structured (e.g., separate usage note) but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with 2 parameters and no output schema. Description covers core function but omits return behavior (expected boolean or object). Adequate but could explicitly state outcome when proof exists vs. not.
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 coverage is 100% with clear descriptions for both parameters (hash as SHA-256 fingerprint, save_to as local file path). Description adds no new meaning beyond schema. Baseline score of 3 is appropriate.
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?
Description clearly states the tool checks for an OpenTimestamps proof for a fingerprint, using specific verb 'check' and resource 'fingerprint...proof'. It distinguishes from siblings like verify_certificate and verify_file which perform different verification tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., attest_file, verify_certificate). No when-not-to-use or prerequisite information provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_certificate_pdfGet the certificate PDFA
Get the signed certificate PDF for an attested work, saving it to a local file. Pass attestation (the exact object returned by attest_file) right after attesting, to mint a freshly-signed PDF. Pass only hash to recover an already-archived certificate instead (no credential needed).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | The SHA-256 fingerprint (64 hex chars). | |
| save_to | No | Local file path to save the PDF to (default: ./certificato_<hash12>.pdf). | |
| attestation | No | The full object returned by attest_file, to mint a new PDF. |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions that the tool saves to a local file, specifies a default save path, and clarifies authentication requirements (no credential needed for hash-only mode). However, it does not disclose potential side effects (e.g., server state changes), error conditions (e.g., if attestation is stale or hash not found), or file overwrite behavior, leaving some gaps.
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 description is concise, consisting of exactly three sentences with no redundant information. The first sentence states the main purpose, and the subsequent sentences clearly delineate the two usage modes. Each sentence serves a distinct purpose, making it easy to parse and act upon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested object, no output schema, no annotations), the description adequately covers the two primary use cases and provides necessary parameter context. It mentions the default file path and credential requirements. However, it does not specify the return value (is there a confirmation or path returned?) or error handling, which would be valuable for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100% for the two described parameters (hash and save_to) and one nested object (attestation), the description adds significant meaning beyond the schema. It clarifies that 'attestation' must be the exact object returned by attest_file, and that the hash-only mode requires no credential. The description also provides a default value for save_to. This enhances the agent's ability to correctly use parameters.
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 clearly states that the tool retrieves a signed certificate PDF for an attested work and saves it to a local file. It distinguishes between two distinct use cases: minting a fresh PDF using an attestation object, and recovering an archived certificate using only a hash. This specificity, combined with differentiation from sibling tools like attest_file and verify_certificate, makes the purpose highly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance for each mode: 'Pass attestation right after attesting' for a new PDF, and 'Pass only hash to recover an already-archived certificate' with the note that no credential is needed. This makes it easy for an agent to decide which parameters to provide based on the scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
service_statusCheck service statusA
Get the traffic-light status of the attestation service (worker, archive, signer, Bitcoin anchor).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It accurately describes a read operation and specifies the output type ('traffic-light status'). However, it does not mention response format details or potential side effects, though none are expected for a status check.
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?
Single sentence, 15 words. Front-loaded with the core action and resource. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides the essential purpose. However, it does not explain what 'traffic-light status' means (red, yellow, green), which could be clarified. Context signals show no parameters, so completeness is adequate for a simple status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params, 100% schema coverage). The description correctly omits parameter details, aligning with the baseline score of 4 for parameterless tools.
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?
Description clearly states the verb 'Get' and the resource 'traffic-light status of the attestation service' listing specific components (worker, archive, signer, Bitcoin anchor). It distinguishes from sibling tools like 'check_anchor' which focus on a single component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for overall service status, but does not provide when-not-to-use or contrast with siblings like 'check_anchor'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_certificateVerify a certificate's signatureA
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| anno | No | ||
| hash | Yes | The SHA-256 fingerprint from the certificate. | |
| hmac | Yes | The HMAC signature from the certificate. | |
| note | No | ||
| autore | No | ||
| titolo | No | ||
| attestazione | Yes | The attestation string from the certificate. |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states that the tool confirms authenticity and integrity of declared data, but lacks details on side effects, authentication requirements, or what occurs upon failure. Some behavioral context is provided, but important aspects are missing.
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 description is two sentences with no extraneous information. The key verb and resource are front-loaded, and each sentence adds value. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema), the description covers purpose and exclusions but does not explain return values or error handling. It is adequate but lacks completeness for an agent to fully understand behavior.
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 43%, so the description partially compensates by explaining that metadata parameters are included in verification if present. However, it does not add detailed semantics for each parameter beyond the schema's minimal descriptions.
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 clearly states the specific action: verify the HMAC signature of a certificate's attestation and declared metadata. It explicitly distinguishes from sibling tool verify_file by noting that it does not check against a local file, making the purpose unambiguous.
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 implies when to use this tool (to verify signature of attestation/data) and when not to (if file matching is needed, use verify_file). While not naming siblings explicitly, the context is clear and provides guidance on usage scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_fileVerify a file against a certificateB
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).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| anno | No | ||
| hash | No | Declared SHA-256 to compare against (from the certificate). | |
| hmac | No | The HMAC signature from the certificate. | |
| note | No | ||
| path | Yes | Local file to verify. | |
| autore | No | ||
| titolo | No | ||
| attestazione | No | The attestation string from the certificate. |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool computes SHA-256 locally and verifies server-side, and that no file bytes are sent. However, it does not explain error handling, return values, or permissions needed, which are important for safe invocation.
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?
Two concise sentences front-load the core action and input requirements. No redundant information, every sentence adds value. Ideal length for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description should specify what the tool returns (e.g., success/failure, matched hash, signature validity) to enable the agent to act on results. This is missing, leaving the agent uncertain about the outcome.
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 description adds context that optional parameters (titolo, autore, anno, note) come from the certificate, which aids understanding. However, 50% of parameters lack schema descriptions, and the description does not fully compensate by explaining their purpose or format beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool computes SHA-256 of a local file and verifies it against a hash and HMAC signature, emphasizing that no file bytes are sent. This differentiates it from siblings like 'verify_certificate' but could be more explicit about how it differs from 'attest_file' and 'check_anchor'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a file needs to be verified against a certificate, but does not provide explicit guidance on when to use this tool versus siblings like 'verify_certificate' or 'attest_file'. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
7 tool updates
v0.2.1- First observed
attest_file - First observed
authorize - First observed
check_anchor - First observed
get_certificate_pdf - First observed
service_status - First observed
verify_certificate - First observed
verify_file
TDQS
A3.9/5.0
Scored across 7 tools
Disambiguation5/5
Each tool serves a distinct purpose: authorization, attestation, verification, certificate retrieval, anchor checking, and service status. No overlap or ambiguity.
Naming Consistency4/5
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.
Tool Count5/5
Seven tools cover the core workflow without being excessive. The scope is well-defined for an attestation service.
Completeness4/5
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.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Hosted MCP server for AI agent identity, permissions, verification, and reusable proof.
AI governance MCP server for EU AI Act compliance and jurisdiction verification
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Personal MCP server for humans who create. Proof of authorship, license control.
Related MCP Servers
- AlicenseAqualityCmaintenanceMCP server that stores AI agent reasoning traces permanently on 0G Storage, enabling immutable and verifiable decision logging.59 npmMIT
- AlicenseNot gradedqualityBmaintenanceMCP server for verifying and attesting SHA-256 fingerprints of digital works via Streamable HTTP, with zero-install and privacy-preserving design.MIT
- AlicenseAqualityBmaintenanceMCP server for GoCertius: certified evidence, dossiers, notifications and chats via AI agents.41148 npmMIT
