Sdcreceipt MCP server

sdcreceipt

<!-- mcp-name: io.github.SemanticDataCharter/sdcreceipt -->

Verify and settle VSL Settlement Receipts.

Verification needs no account, no network, and nothing from the issuer. That is the point of the tool: a claim that anyone can check a Receipt independently is worth exactly as much as the ability to do it.

Apache-2.0.

pip install sdcreceipt

Four verbs

# Check a Receipt you were sent. Offline.
sdcreceipt verify receipt.json --keys issuer-keys.json

# Set yourself up as a party: keypair + the document to publish.
sdcreceipt init --key-id https://vendor.example/.well-known/vsl-key.json

# Authorize a settlement you are a party to.
sdcreceipt trigger receipt.json --key vsl-party.pem \
    --key-id https://vendor.example/.well-known/vsl-key.json

# Ask an issuer for a Receipt. The one verb that needs an account.
sdcreceipt settle payload.xml \
    --party https://vendor.example/.well-known/vsl-key.json \
    --party did:web:partner.example

settle prompts for anything it needs and was not given. Two of its fields are not guessable and never were: the release condition is hashed by the issuer and never stored, and currentstate/targetstate come from a governance workflow defined in a schema the issuer holds, not you.

If the issuer refuses the transition it answers with the ones it would have accepted, and settle prints them:

Governance evaluation produced no Receipt. Decision was DENY

From 'draft' you can go to: review

This model's workflow:
  standard: draft -> review -> published

It exits 2 there, and 1 on a real failure, so a script can tell "ask again differently" from "something is broken".

verify exits 0 only if every check passed, so it composes in a shell without anyone parsing output.

That is the whole surface. This is a client, not a product, and its value is in being small enough to read.

Try it without reading anything

python examples/settle.py

One settlement end to end: two parties, two signatures, verified offline. No account, no network, no API key. See examples/.

For an agent

Three of the four verbs over MCP, in the same package:

sdcreceipt-mcp --key vsl-party.pem \
    --key-id https://vendor.example/.well-known/vsl-key.json

Exposes verifyreceipt, signtrigger and settle. Each is advertised only when the server has what it needs, so a tool is never offered whose every call would fail.

Two deliberate omissions, and they are the security posture rather than an oversight (see also SECURITY.md):

clear custody story. init stays a human act at a terminal.

• No key generation. A private key generated inside an agent session has no

Submitting takes a destination from the caller, and a signed trigger plus an arbitrary host is the combination worth refusing.

• No submission. sign_trigger returns a signed trigger for you to submit.

settle is available when the server is started with --endpoint and a token, and it is the only tool that reaches the network. The endpoint is fixed at start-up exactly like the key, so a caller can never redirect where a payload goes. No tool takes a URL, and that is the invariant to keep if this ever grows another one.

The signing key is given at start-up, never in a tool call, so it does not travel through the conversation.

If you were sent a Receipt

You do not need an account with anyone. You need the issuer's published key document and, for a settled Receipt, each party's. The Receipt names the parties by the URIs they publish their keys at; the issuer's key document is at a fixed well-known path.

Shortened. The full README is on GitHub.