# evidence [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/tersignhq/tersign-js  
**GitHub Stars:** 1  
**npm Downloads (last month):** 2046  
**Views:** 3  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/evidence

## Description
Evidence layer for agent commerce: signed receipts, verification, dispute evidence envelopes.

## Tools
Capabilities this server exposes over MCP:

- **issue_receipt** — Issue an x402 offer-receipt (EIP-712) plus a Tersign compliance record (returned as `compliance`; verify_compliance_record checks it) for a payment that has ALREADY settled; when a ledger is configured, the ledger counter-signs the receipt into your hash chain, while the compliance-fields record is not counter-signed and is bound to its receipt only by your own signature, which covers the receipt's digest. Use this for money that moved; use record_disclosure for a non-payment agent action. Side effects: signs with your signing key (the one set in the Tersign plugin's settings in Claude Code, or the TERSIGN_* environment variables, else the one generated and kept locally on first run), and performs ONE network write to the ledger when a ledger URL, API key and seller id are set there too (without them it signs locally and returns an unchained artifact). Returns the signed receipt artifact, its keccak256 canonical digest, and — when chained — the ledger counter-signature and sequence number.
- **verify_receipt** — Verify an x402 offer-receipt artifact, fully OFFLINE (no network, no API key, no account; checks no ledger or chain): recover the address whose key produced its EIP-712 signature over the six signed payload fields (version, network, resourceUrl, payer, issuedAt, transaction), and compute its canonical digest (the content address a ledger records it under). Recovery yields SOME address for any payload, so without expectedSigner the signer is UNAUTHENTICATED: valid:true then proves neither who signed nor that the receipt is unmodified — an edited receipt recovers a different address and still returns valid:true. Pass expectedSigner, the issuer's address obtained out-of-band, to bind it: valid:true then means the signed fields were signed by that key; a mismatch returns valid:false with the recovered signer so you can see who actually signed. Use this for a receipt (money); use verify_compliance_record for the compliance record issue_receipt returns beside a receipt. Returns { verdict, valid, signer, signerStatus: BOUND | UNAUTHENTICATED | MISMATCH, signerBound, testKey? (the signer is a PUBLISHED test key — anyone can sign as it), digest, unsignedFields? (present in the artifact but not covered by the signature), reason? }. Read verdict first.
- **record_disclosure** — One-call disclosure evidence (EU AI Act Art 50 dialect): digests the disclosure text LOCALLY, signs an action record with your key, and the public ledger counter-signs it into your per-signer hash chain. No API key needed — the first call self-provisions a free signer-keyed account, except when your key is already registered to an API-key account (409) or the daily provisioning caps are reached (429; https://tersign.ai/pricing).
- **verify_compliance_record** — Verify ONE record type: the compliance record that issue_receipt returns beside a receipt (`compliance`: a ComplianceRecordV1 `record` plus its ComplianceAttestation `attestation`, EIP-712 domain "compliance-fields"), fully OFFLINE (no network, no API key, no account): recompute the record's canonical digest, check that the attestation's signed payload names that exact digest and the same receiptDigest as the record, and recover the address that signed the attestation. It does NOT verify the disclosure record record_disclosure returns: that is a different record type (an action record, EIP-712 domain "tersign action-record"), and passed here it fails with a digest mismatch that says nothing about tampering. Use verify_receipt for the payment receipt itself. Without expectedSigner the signer is UNAUTHENTICATED and valid:true proves internal consistency only — anyone can edit a record, recompute its digest and re-sign the attestation with their own key, and still get valid:true with a different signer. Pass expectedSigner, obtained out-of-band, to bind authorship. Returns { verdict, valid, signer, signerStatus: BOUND | UNAUTHENTICATED | MISMATCH, signerBound, testKey? (a PUBLISHED test key — anyone can sign as it), digest (the recomputed record digest), reason? }. Read verdict first.
- **record_refund** — Log a refund against a receipt already on your chain, as the SELLER. The ledger stores it as a PENDING refund entry that references the original receipt digest; the entry is NOT counter-signed or appended to the hash chain, and it has no digest or sequence number of its own. Nothing is edited or deleted: the original receipt and its chain position stay exactly as they were. Requires a ledger URL, API key and seller id (the Tersign plugin's settings in Claude Code, or the TERSIGN_* environment variables) and performs one network write; errors if the original digest is not on your chain. This RECORDS a refund you have already made — it moves no money. For a signed refund RECORD, build a compliance record with refundOf set to the original record digest (buildMinimalRecord in the SDK). Returns { id, status: "pending" }.
- **open_dispute** — Open an objective dispute against a counter-signed receipt as the PAYER (the configured key must be the receipt payer). Reasons: not_delivered, wrong_content, duplicate_charge. Contested non-mechanical claims escalate to the arbiter; duplicate_charge is decided instantly from ledger arithmetic.
- **submit_dispute_evidence** — Submit signed evidence to an open dispute. Claimant evidence must be signed by the payer key; respondent evidence additionally requires the seller API key (the Tersign plugin's settings in Claude Code, or the TERSIGN_* environment variables).
- **adjudicate_dispute** — Trigger deterministic adjudication of an open dispute: the same inputs always produce the same verdict and rationale — no discretion, no model in the loop — and the verdict object embeds the inputs it was computed from. Side effects: writes the verdict to the dispute record; a refund verdict also logs a PENDING refund entry against the receipt (not counter-signed into the chain; no money moves). Adjudicating twice is not meaningful; the first verdict stands (a second call returns 409). Returns the verdict, the rationale naming the rule applied, the adjudication inputs, the verdict digest, and the ledger signature over that digest.
- **get_dispute** — Fetch a dispute in full: its state, both sides' evidence references, the verdict and rationale once adjudicated, and the ledger signature over the record. Read-only — one network read, no key required, and safe to poll while a dispute is open.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "evidence": {
    "command": "npx",
    "args": ["-y","tersign"]
  }
}
```

## Documentation

## What evidence MCP server does

The evidence MCP server supports evidence workflows around agent commerce rather than general-purpose data access. Tersign receipts use EIP-712 signatures and the x402 offer-and-receipt extension. The resulting payload receives a canonical keccak256 digest, is linked into a per-seller hash chain, and can receive a counter-signature from the Tersign ledger.

The evidence MCP server can verify a receipt supplied as JSON or identified by its digest. Local file verification recovers the signing address and can compare it with an issuer address supplied separately through `--signer`. Digest verification queries a ledger and reports that ledger’s counter-signed chain result; it does not re-verify the record locally.

Disclosure evidence is another supported workflow. A command digests disclosure text locally, signs the resulting record, and submits it for ledger counter-signing. This produces evidence that a disclosure was attested at a particular time, but it is not a compliance certification.

## How it works

A seller signs a receipt, Tersign computes its digest, and the digest joins a seller-specific sequence where each entry refers to the previous one. The ledger counter-signs the entry. Chain commitments are submitted for Bitcoin anchoring on a six-hour schedule; newer anchors cover the complete preceding prefix, while earlier anchors identify the head record they cover.

Disclosure text stays local during digest creation; only the digest is sent. The first disclosure request can create a free signer-keyed account, subject to provisioning, quota, and rate limits. Refund records can point to the corrected record by digest, and disputes can attach objective reason codes. Party statements are kept separate behind an `UNVERIFIED` marker.

## Setup and configuration

Install the JavaScript package with:

```sh
npm i tersign
```

Signing keys are resolved from `TERSIGN_SELLER_KEY`, the macOS keychain entry named `tersign-signer`, or `~/.tersign/signer.key`. A key file is created on first use when no earlier key is available. The `withAssure()` adapter can wrap an x402 fetch handler. With a configured ledger, it adds a seller receipt and a compliance-fields record to the base64 JSON payment response header while leaving the response body unchanged.

## Tools and capabilities

The evidence MCP server’s documented command-line capabilities include:

- Verify a receipt file or digest with `npx tersign verify`.
- Compare a locally recovered signer with an issuer address using `--signer`.
- Select another ledger with `--ledger` when checking a digest.
- Create disclosure evidence with `npx tersign disclose`, including a medium and agent identifier.
- Retrieve verification results over HTTP from the Tersign receipt verification endpoint.
- Wrap x402 handlers with `Assure` and `withAssure()` to emit payment-response evidence.

Verification rejects malformed JSON structures, duplicate keys, non-integer numbers, non-canonical signatures, unsupported signed field types, and published development test keys. Exit status `0` indicates a valid result, `1` an invalid result, and `2` a usage error.

## Limitations and notes

A receipt file checked without `--signer` is reported as having an unauthenticated signer. Signature recovery alone does not establish that the recovered address belongs to the issuer. Digest checks are ledger-reported and explicitly do not perform the local receipt verification performed for files.

Disclosure requests may fail when the signer is already attached to an API-key ledger account, provisioning limits are reached, or free-tier limits apply. If an x402 settlement network is unsupported or the ledger fails, `withAssure()` passes the paid response through without a receipt and sends the error to `onError`. Compliance-fields records are not counter-signed by the ledger; they are linked to their receipt by the seller’s signature.

_Full upstream README: https://allmcps.com/mcp/evidence/readme_