A
licenseA
qualityC
maintenanceCryptographic accountability for AI agents. Ed25519-signed receipts for every MCP tool call. Constraints, chains, AI judgment, invoicing, and local dashboard included.
24
6 npm
1
MIT
mcp-context-receipts
by DARREN-2000
You can create and verify privacy-first, tamper-evident receipts for MCP tool calls.
create_receipt: Generate a signed capsule containing server, tool, hashed arguments, hashed result, duration, timestamp, sequence, previous hash, and HMAC signature.
verify_receipt: Validate a receipt's HMAC signature and content hash to confirm integrity and authenticity.
Use as an MCP stdio server with any compatible MCP client.
Works with the same secret to detect edits, deletion, or reordering in a capsule stream.
No raw prompts, arguments, or results are stored or transmitted—only SHA-256 digests.
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., "@mcp-context-receiptsGenerate a signed receipt for the most recent tool run."
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.
# MCP Provenance Capsules
Portable, privacy-first evidence for every MCP tool call.
MCP gives models access to powerful tools. Provenance Capsules answer the hard question that follows: what ran, exactly, and can anyone verify the record later?
This project is a tiny, dependency-free universal library (Node.js, Deno, Bun, Browser) and an MCP server that emits cryptographically linked evidence without storing raw prompts, arguments, or results.
Playground
You can try the library directly in your browser without any setup! Try the GitHub Pages Playground here!
Related MCP server: Agent Audit Logger MCP
Why this is not another audit log
Privacy by default: only SHA-256 digests leave the call boundary; raw payloads stay in the caller.
Tamper evident: each capsule carries an HMAC signature and the previous capsule hash.
Portable: JSON capsules and JSONL streams work with object storage, SIEMs, test fixtures, or a database.
MCP-native: use it as a stdio server with any compatible client, or import the core class into an existing server.
Universal & Robust: Uses the native Web Crypto API so it works universally in browsers, Node 20+, Deno, and Edge Workers. Features a deterministic JSON stringifier to eliminate fragile signature failures due to key reordering.
Verifiable later: anyone holding the capsule stream and verification secret can detect edits, deletion, and reordering.
Small surface: Zero runtime dependencies, no hosted service required.
Quick start
Requires Node.js 20+ (for the MCP server).
npm startConfigure an MCP client with command node and argument /absolute/path/to/mcp-provenance-capsules/src/server.js. Set MCP_RECEIPT_SECRET outside source control.
The server exposes create_receipt and verify_receipt tools.
Embed it
Import ReceiptChain from src/receipts.js, construct it with your secret, and await chain.create(...). Because it uses the native Web Crypto API, all operations are asynchronous.
import { ReceiptChain } from "./src/receipts.js";
const chain = new ReceiptChain("your-secret");
// Create a receipt
const receipt = await chain.create({
server: "demo",
tool: "fetch_data",
arguments: { id: 123 },
result: { status: "ok" },
durationMs: 42
});
// Verify a receipt
const verification = await chain.verify(receipt);
console.log(verification.valid); // trueCapsule anatomy
A capsule contains a version, sequence number, UTC timestamp, server and tool identity, argument and result hashes, duration, previous hash, HMAC signature, and its own hash. The canonical schema lives at schema/capsule.schema.json.
The chain is storage-agnostic: write JSONL to object storage, a database, or your existing audit pipeline. The library never persists data itself.
Verify a stream
Set the same secret used when creating capsules, then run MCP_RECEIPT_SECRET='your-secret' npx verify-capsule capsules.jsonl.
The command prints one machine-readable verification result per capsule and exits non-zero if any signature, hash, or chain link fails.
Security notes
Use a high-entropy secret from your deployment secret manager. Rotate secrets by starting a new chain and recording the rotation boundary in storage. HMAC proves integrity to parties that possess the secret; it is not a public, non-repudiable signature.
Product boundary
This project is not a hosted compliance platform, payload recorder, or replacement for authorization. It is the evidence layer underneath those systems.
Development
npm testMIT licensed. Contributions are welcome, especially durable sinks, key rotation, OpenTelemetry export, and adapters for additional MCP transports—while preserving the no-raw-payload default.
Available Tools
2 toolscreate_receiptC
Create a privacy-first signed receipt for an MCP tool call.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | ||
| result | No | ||
| server | Yes | ||
| arguments | No | ||
| durationMs | No |
TDQS
C2.1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'privacy-first' but gives no concrete behavioral details such as data handling, side effects, or security requirements. No annotations exist to supplement this.
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?
The description is a single concise sentence that front-loads the action and object. It is appropriately short, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to explain how the parameters fit the receipt creation process, what the receipt contains, or what the output looks like. It is incomplete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists five parameters but none have descriptions. The tool description does not explain any of them, leaving their purpose and relationships completely unspecified.
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?
The description clearly states the action (create) and the resource (a signed receipt) for an MCP tool call. It is specific enough to understand the core purpose, though it could elaborate on what the receipt includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. It does not mention when to use this tool versus the sibling 'verify_receipt', nor any conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_receiptB
Verify a receipt's signature and content hash.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It does communicate that the tool checks signature and content hash, which implies a read-only verification action. However, it does not state the return value, success/failure behavior, or any side effects, leaving significant ambiguity for an agent.
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 consists of a single compact sentence, 'Verify a receipt's signature and content hash.' It is front-loaded, economical, and contains no redundant words or filler.
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?
The tool has a nested input object with no schema detail and no output schema. Despite moderate complexity, the description omits the receipt structure expected by the parameter, the return format, and the meaning of a successful verification. This leaves significant gaps for correct invocation.
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 input schema lists a single nested 'receipt' object with no described properties (0% coverage). The description partially compensates by mentioning that verification involves 'signature and content hash,' which hints at expected receipt fields. But it still doesn't describe the shape, required keys, or format of the receipt object.
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 uses the specific verb 'verify' with the resource 'receipt' and specifies the exact scope ('signature and content hash'), making the tool's purpose clear. It also distinguishes itself from sibling create_receipt by being the verification counterpart rather than a creation or mutation tool.
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?
The description provides no guidance on when to use this tool, what precedes it, or alternatives such as create_receipt. There is no mention of what scenario calls for verification, so a lowercase agent must infer usage solely from the tool's name and purpose.
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.
2 tool updates
v0.1.0- First observed
create_receipt - First observed
verify_receipt
TDQS
B3.2/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes: one creates a receipt and the other verifies it. There is no overlap or ambiguity between them.
Naming Consistency5/5
Both tool names follow the same verb_noun pattern: create_receipt and verify_receipt. The naming is consistent, predictable, and aligned with the server's purpose.
Tool Count4/5
With only two tools, the set is minimal, but each tool is essential and earns its place for the narrow domain of receipt creation and verification. It feels slightly thin but is still well-scoped.
Completeness5/5
The domain is signing and verifying receipts, and create plus verify covers the full lifecycle. No update or delete is expected for immutable receipts, so there are no meaningful gaps.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Hash-chained HMAC-signed audit log MCP for A2A (agent-to-agent) calls. Every tool-call, agent-ha...
Post-quantum, tamper-evident receipts for agent actions. Ed25519 + ML-DSA-65, offline verify.
Remote MCP for MCP tool deprecation receipt, structured receipts, audit logs, and reviewer-ready evi
Issue signed receipts for AI agent actions; verify any receipt offline - free, no account.
Related MCP Servers
- AlicenseBqualityCmaintenanceHash-chained HMAC-signed audit log MCP for A2A (agent-to-agent) calls. Every tool-call, agent-handoff, decision gets a tamper-evident signed record.5167 PyPIMIT
- FlicenseAqualityDmaintenanceMCP server that auto-emits tamper-evident receipts for every tool call, enabling EU AI Act Article 12 compliance with signed, chain-linked receipts.1-
- AlicenseAqualityAmaintenanceProvides tools to issue, verify, and export cryptographically signed receipts for AI agent actions, enabling tamper-proof audit trails for compliance with regulations like the EU AI Act.439 npm1MIT