attest
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| X-PAYMENT | No | Header for a per-call x402 payment (USDC on Base) when the free tier is exhausted. | |
| PAYMENT-SIGNATURE | No | Header for a per-call x402 payment (USDC on Base) when the free tier is exhausted. | |
| X-ATTEST-ENTITLEMENT | No | Header carrying a prepaid key (entitlement) for paid access; no auth is required for the free tier (20 checks/day). |
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": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| verify_artifactA | Verify an artifact produced by an AI agent before accepting or paying for it. Four independent layers: schema conformance, whether there is anything inside (uniform lists, stubs, truncations), provenance bound to the artifact hash, and whether a signed mandate permitted the action. Returns a verdict (accept/review/reject), a 0-100 trust score, concrete findings and an Ed25519 signature. Rule-based, no LLM: the same artifact always yields the same result. Use before accepting work from another agent and before payment. |
| verify_artifact_batchA | Verify several artifacts at once — a scan report, a list of findings, a set of tool descriptions. One call, one verdict per artifact, plus a summary of how many were accepted, need review, or were rejected. Use when an agent produced a batch (twenty findings from a security scan, for example) and each of them has to be checked before the work is paid for. |
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 2 tools
verify_artifact and verify_artifact_batch are clearly distinguished by single vs. batch input; the batch tool is essentially a convenience wrapper, so there is slight purpose overlap but descriptions make the boundary clear.
Both tools follow the same verb_noun convention (verify_artifact, verify_artifact_batch) with a predictable _batch suffix for the plural case.
Two tools is thin for an attestation service; the single/batch split is reasonable but leaves no room for auxiliary operations like retrieving past verdicts or fetching the signing key.
Core verification for one or many artifacts is covered, but there are notable gaps: no tool to retrieve a prior verdict or trust score, no way to fetch the Ed25519 public key needed to check the returned signature, and no mandate inspection.