Which integrations are available for this server?

Provides a callback handler to automatically emit receipts for every tool call in CrewAI agents. Provides a callback handler to automatically emit receipts for every tool call in LangChain agents. Works with Vercel AI SDK to integrate ActionProof receipts into AI applications.

actionproof

by Burakfenerci5

Overview Schema Related Servers Score Discussions

TypeScript

Local

ActionProof

A tamper-proof audit trail for AI agents. Verifiable observability: every action your agent takes gets a cryptographically signed receipt you can verify offline, anywhere — zero backend.

Observability tools (LangSmith, Langfuse, Arize) show you what your agent reportedly did — traces recorded inside their platform, on their word. But those logs are self-asserted: an agent, a bug, or an attacker can write anything into them, and you can't prove after the fact that the record wasn't edited.

ActionProof adds the missing layer: verifiable observability. Each action — email sent, form filed, payment made — gets a tamper-evident, Ed25519-signed receipt capturing what was done, by which agent, when, and on whose authority. Edit any field and verification fails. It's an audit trail you (or an auditor, a user, or a counterparty) can trust without trusting the agent, the vendor, or us.

Built for the compliance floor that's coming — the EU AI Act (Article 12) and ISO 42001 require traceable, tamper-evident logs for automated decisions. ActionProof produces exactly that, as a portable primitive rather than a walled-garden platform.

Install

npm install actionproof      # TypeScript / JavaScript
pip install actionproof      # Python

Receipts are cross-compatible: one signed in TypeScript verifies in Python, and vice-versa.

Related MCP server: agent-receipts-mcp

Quick start (TypeScript)

import { attest, verify, generateKeypair } from "actionproof";

const agent = generateKeypair();               // agent's identity = its key (did:key)

const receipt = attest(agent, {
  type: "email.send",
  summary: "Sent renewal quote to jane@acme.com",
  params: { to: "jane@acme.com", amount: 4200 }, // hashed, not stored in clear
  result: { smtp: 250 },
  outcome: "ok",
});

verify(receipt);            // -> { valid: true, agent: "did:key:z6Mk..." }

Quick start (Python)

from actionproof import attest, verify, generate_keypair

agent = generate_keypair()

receipt = attest(
    agent,
    type="email.send",
    summary="Sent renewal quote to jane@acme.com",
    params={"to": "jane@acme.com", "amount": 4200},  # hashed, not stored in clear
    result={"smtp": 250},
    outcome="ok",
)

verify(receipt)             # -> VerifyResult(valid=True, agent="did:key:z6Mk...")

Edit any field of that receipt and verify returns invalid. That's the whole idea.

Where it fits: the verifiable layer of agent observability

ActionProof complements your observability stack rather than replacing it. Keep using LangSmith / Langfuse / Arize for rich traces, latency, and cost — then attach an ActionProof receipt to the actions that matter (the ones that move money, change state, or touch a user's data) so that part of your trail is tamper-evident and independently verifiable.

	Observability platforms	ActionProof
Recording	traces/logs inside the vendor	signed receipts you hold
Trust model	trust the platform's stored record	verify cryptographically, trust no one
Tamper-evidence	editable by whoever has DB access	any edit breaks the signature
Portability	lives in the vendor	offline, cross-language, anywhere
Cost at scale	metered per event	~$0 (local signing, zero backend)

It's a proof, not just a log entry — the difference between "our dashboard says the agent did this" and "here's a signed receipt anyone can verify."

Design principles

Offline & zero-backend. The agent brings its own Ed25519 key. Signing and verification use only native crypto — no server, no account, no network. (This is also why it costs ~nothing to run at any scale.)
Privacy-preserving. Sensitive inputs/outputs are stored as SHA-256 hashes; you can later prove a value matches without ever putting it in the receipt.
Composable, not competitive. ActionProof is the receipt envelope. Bind stronger evidence into result_hash — an x402 settlement, an AP2 mandate reference, a DKIM-signed SMTP 250 — to make a receipt as strong as its counterparty evidence.
Identity with no registry. Agent identity is a did:key (self-describing public key). Who you trust is your policy (pinned keys, an allow-list, or the optional log below).

See SPEC.md for the wire format.

Use it as an MCP server (no code)

The fastest way to give an agent receipts: run ActionProof as an MCP server and add it to Claude Desktop / Cursor. Your agent gets three tools — attest_action, verify_receipt, get_identity — and can emit a receipt right after it does something.

Add to your MCP client config (e.g. Claude Desktop claude_desktop_config.json):

{
  "mcpServers": {
    "actionproof": {
      "command": "npx",
      "args": ["-y", "actionproof-mcp"]
    }
  }
}

The server mints a stable Ed25519 identity on first run (stored at ~/.actionproof/agent.key.pem, override with ACTIONPROOF_KEY_PATH). Every receipt it signs is attributable to that one agent did:key.

Auto-emit receipts (framework wrappers)

You don't have to call attest by hand after every action — wrap the tool once and every call emits a receipt.

TypeScript (framework-agnostic; works with LangChain.js, Mastra, Vercel AI SDK):

import { withReceipts, generateKeypair } from "actionproof";

const agent = generateKeypair();
const send = withReceipts(agent, rawSendEmail, {
  type: "email.send",
  onReceipt: (r) => store(r),   // called with a signed receipt on every call
});

Python (@attest_action decorator, or a LangChain/CrewAI callback):

from actionproof import attest_action, ActionProofCallbackHandler

@attest_action(agent, type="email.send", on_receipt=store)
def send_email(to, body): ...

# or attest every tool a framework agent runs, no per-tool code:
handler = ActionProofCallbackHandler(agent, on_receipt=store)
agent_executor.invoke(input, config={"callbacks": [handler]})

Develop locally

git clone https://github.com/Burakfenerci5/actionproof
cd actionproof && npm install
npm run demo     # full sign → verify → tamper loop
npm test         # TS suite (9 tests)
npm run mcp      # start the MCP server over stdio

cd python && pip install -e ".[dev]" && pytest   # Python suite (7 tests, incl. TS↔Python interop)

Roadmap

Now (shipped): TypeScript library + MCP server + framework wrapper, and the Python package with a decorator and LangChain/CrewAI callback. Receipts interoperate across both.
Next: first-class LlamaIndex / CrewAI plugins; exporters that attach receipts to spans in your existing observability stack (OpenTelemetry, LangSmith, Langfuse).
Later (optional, hosted): a verifiable audit dashboard — a searchable, shareable, tamper-evident timeline of what your fleet of agents did, backed by an append-only log, for teams that need compliance-grade evidence (EU AI Act / ISO 42001) without building it themselves. The library and MCP server stay free and offline forever; only the hosted dashboard is a paid service.

License

MIT.

Available Tools

3 tools

attest_actionAttest an actionA

Create a signed, tamper-evident receipt that THIS agent performed an action (e.g. sent an email, filed a form, made a payment). Call it right after you perform the action. Returns a SignedReceipt you can store or share; anyone can later verify it offline.

ParametersJSON Schema

Name	Required	Description
`type`	Yes	Action verb in reverse-dot form, e.g. 'email.send', 'payment.send'.
`params`	No	The action's inputs. Stored only as a hash (privacy-preserving).
`result`	No	The observed result/response. Stored only as a hash.
`target`	No	System/resource acted upon, e.g. 'acme-crm'.
`outcome`	No	Outcome of the action. Defaults to 'ok'.
`summary`	No	Human-readable one-line description of what was done.
`delegation_by`	No	did:key or id of the principal who authorized this action, if any.
`delegation_ref`	No	Pointer to the grant (OAuth grant, AP2 mandate URL/URN).
`delegation_scope`	No	Authority granted, e.g. 'email.send'.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully bears the transparency burden. It discloses the tamper-evident nature, the return of a SignedReceipt, and offline verifiability. However, it does not mention required permissions, side effects, or state changes.

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 deliver all essential information without redundancy. Every word contributes to understanding the tool's function, usage timing, and output.

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?

For a tool with 9 parameters, no output schema, and no annotations, the description covers the core purpose, when to use, and what is returned. It could elaborate on the role of optional parameters, but the schema already handles that.

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 description coverage is 100%, so baseline is 3. The description adds value by noting that 'params' and 'result' are stored only as hashes for privacy, and provides examples like 'email.send'. This goes beyond the schema.

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 verb 'Create' and the resource 'signed receipt', with concrete examples of actions. It distinguishes itself from siblings 'get_identity' and 'verify_receipt' by describing a unique action recording purpose.

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 explicitly instructs 'Call it right after you perform the action', providing scenario examples. While it does not name exclusions or alternatives, the context for use is clear and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_identityGet this agent's identityA

Return this ActionProof server's stable agent identity (a did:key). Receipts from attest_action are signed by this identity.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/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 mentions the return value and signing context but does not disclose potential side effects, authentication requirements, or rate limits. However, as a read-only operation, the description is minimally adequate.

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 extremely concise: two sentences with no unnecessary words. It front-loads the core purpose and adds relevant context about identity usage.

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, the description could be more explicit about the format of the did:key. However, for a simple identity retrieval tool with clear context from siblings, it is sufficiently complete.

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?

With zero parameters and 100% schema coverage, the description does not need to provide parameter details. The title and description effectively communicate the tool's simplicity.

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 tool returns the server's stable agent identity (did:key). It also connects to sibling tools by noting that receipts from attest_action are signed by this identity, distinguishing the tool's purpose.

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 implicitly indicates when to use this tool (to obtain the identity for verifying signatures), but does not explicitly state when not to use it or provide direct comparison with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_receiptVerify a receiptA

Verify a signed ActionProof receipt offline. Returns whether the signature is valid and which agent did:key signed it. Optionally re-check that supplied params/result match the hashes in the receipt.

ParametersJSON Schema

Name	Required	Description
`expect_params`	No	If provided, verify these params match the receipt's params_hash.
`expect_result`	No	If provided, verify this result matches the receipt's result_hash.
`signed_receipt`	Yes	The SignedReceipt JSON (as produced by attest_action).

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that verification is offline, returns signature validity and signing agent, and optionally checks params/result against hashes. It does not mention error handling or edge cases, but main behavioral traits are clear.

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?

Description is two concise sentences. First sentence states core purpose and mode (offline), second explains outputs and optional feature. No redundant information.

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?

Tool is simple but lacks output schema. Description explains return of validity and agent key, but does not specify return format or error responses. Context about optional checks is provided, but completeness is moderate given no output schema.

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?

Input schema has 100% coverage with descriptions for all parameters. The description adds context that optional parameters allow re-checking against receipt hashes, which enhances understanding beyond the schema alone.

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 verifies a signed ActionProof receipt offline, returning signature validity and signing agent. Title and description align, and it is distinguishable from sibling tools attest_action (which produces receipts) and get_identity (which gets identity).

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?

Description implies usage by stating it verifies receipts offline, but it does not explicitly state when to use this tool versus alternatives or provide any prerequisites or exclusions. Sibling tool names are provided but no guidance on when to choose verify_receipt.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a distinct purpose: attest_action creates a receipt, get_identity provides the signer's DID, and verify_receipt validates receipts. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: attest_action, get_identity, verify_receipt.

Tool Count4/5

With only 3 tools, the server is minimal but well-scoped for its purpose. A few additional tools (e.g., list_receipts) could be useful but are not necessary.

Completeness5/5

The core workflow of attestation is fully covered: identity retrieval, action attestation, and receipt verification. No obvious gaps in the domain.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
com.pcrzero
Issue signed receipts for AI agent actions; verify any receipt offline - free, no account.
Security Observability
31
Trust Gate A
io.github.CWNApps
Post-quantum, tamper-evident receipts for agent actions. Ed25519 + ML-DSA-65, offline verify.
Security Autonomous Agents
42
Agent Receipts A
com.dropwatchhq
Issue & verify signed (ed25519), hash-chained, timestamped provenance receipts for agent actions.
Security Blockchain Autonomous Agents
32
InfraPulse A
ai.infrapulse
AI agent infrastructure for discovery, authorization, execution, identity, and signed receipts.
Agent Orchestration Developer Tools
61

Related MCP Servers

hive-mcp-spire
srotzin
A
license
Not graded
quality
A
maintenance
Provides tools to sign and verify post-quantum attestations of AI agent actions (mint, trajectory, coherence) using ML-DSA-65 signatures, with offline verification always free.
Updated a month ago (2026-08-04 20:51 UTC)
MIT
agent-receipts-mcp
Security Autonomous Agents
dhanushs1912-svg
A
license
A
quality
A
maintenance
Provides 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.
Updated 2 months ago (2026-07-17 19:51 UTC)
4
64
1
MIT
ZeroID Agent Identity
Security Autonomous Agents
clauxel
F
license
Not graded
quality
D
maintenance
Issues accountable identities for AI agents before they interact with tools, with tools for identity management and receipt export.
Updated 3 months ago (2026-05-27 16:07 UTC)
@sequesign/mcp
Autonomous Agents Security
Sequesign
A
license
Not graded
quality
A
maintenance
Enables AI agents to create cryptographically verifiable receipts of their delegated work, with capabilities for multi-party approval and offline verification.
Updated 14 days ago (2026-08-21 03:03 UTC)
346
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Burakfenerci5/actionproof'

If you have feedback or need assistance with the MCP directory API, please join our Discord server