OpenWorkProof logo

OpenWorkProof

Signed work contracts, execution receipts, verification decisions, and human acceptance records for independently auditable agent work.

Install OpenWorkProof

Pick your client, then add it in one click or paste the config.

STDIOPython
~/Library/Application Support/Claude/claude_desktop_config.json
claude_desktop_config.json
{
  "mcpServers": {
    "openworkproof": {
      "command": "uvx",
      "args": [
        "openworkproof"
      ]
    }
  }
}

Settings → Developer → Edit Config, merge this into mcpServers, then fully quit and reopen Claude Desktop.

We couldn’t confirm it starts correctly

We ran the install command but it didn't respond within our test window — this can mean a slow first-time install rather than a real problem.

uvx openworkproof

Process exited before answering initialize.

This is an experimental automated check and can have false negatives — missing environment variables, a slow cold install, etc. It doesn’t necessarily mean something’s wrong. Last checked 7d ago.

Overview

OpenWorkProof MCP server connects agents to a signed work-contract and evidence workflow for authorization, execution, verification, and human acceptance. It links WorkOrders, CapabilityGrants, PolicyDecisions, ActionReceipts, VerificationDecisions, and AcceptanceDecisions into an append-only chain using Ed25519 signatures, normalized JSON, and content digests. Reach for it when an agent must show who authorized an action, whether execution stayed within scope, and what an independent verifier or human acceptor concluded. It does not determine whether a business result is correct or replace human acceptance.

Use cases

  • Record agent authorization and execution evidence for code changes
  • Verify exported work histories without access to the original platform
  • Require human approval for reserved agent actions
  • Separate technical verification from customer acceptance
  • Inspect and export delivery evidence in CI workflows

Key features

  • Ed25519-signed work contracts and evidence chains
  • Pre-execution policy decisions
  • Action receipts linked to authorization and evidence
  • Independent verification and human acceptance records
  • Offline surface and acceptance-bundle validation
  • Human Agency Profile enforcement

Security & health

What it can reach and how reliably it runs — from our own checks, not the maintainer’s claims.

ActiveLast checked Today

Recent health check succeeded.

7/7 checks healthy over the last 35d

Supply-chain signal

No high-severity advisories surfaced by our automated scan.

Critical 0High 0Medium 0Low 0

Scanned 15d ago via OSV.dev · openworkproof (PyPI)

Adoption & maintenance

Factual signals from GitHub, npm, and our automated checks — not a rating.

GitHub stars262Stargazers on the source repository.
Last commit1mo agoMost recent push to the default branch.
Install checkInconclusiveDidn't respond in our test window — often a slow first install.
Directory activity2 viewsConfig copies, upvotes, and views on AllMCPs.

How OpenWorkProof works

What OpenWorkProof MCP server does

OpenWorkProof MCP server adds a verifiable execution layer to agent, CI, MCP, and multi-agent workflows. It records the intended task, the authority that approved it, decisions made before tool execution, the actions that occurred, the evidence attached to those actions, and the separate outcomes of verification and acceptance.

The resulting record can be exported as a signed evidence package. A third party with the package and public keys can replay the chain without connecting to the original platform. This makes it possible to inspect authorization, execution scope, evidence summaries, verification conclusions, and acceptance status as separate facts.

The protocol does not act as an operating system, model, orchestrator, payment service, legal arbitrator, or automatic acceptance authority. A VERIFIED result is not the same as ACCEPTED, paid, settled, legally audited, or adopted by an upstream system.

How it works

A work chain proceeds through these linked objects:

  • WorkOrder fixes the goal, source version, paths, tools, time limit, and acceptance conditions.
  • CapabilityGrant gives a signed, limited authority that can be narrowed or consumed but not expanded.
  • PolicyDecision records whether an action is allowed before the tool runs.
  • ActionReceipt connects the request, authorization decision, execution result, and evidence digest.
  • VerificationDecision records an independent assessment of the frozen scope and evidence.
  • AcceptanceDecision records whether the designated acceptor accepted or rejected the delivery.

Ed25519 signatures, canonical JSON, an append-only ledger, and content digests protect the relationships between these objects. Changing an authorization, receipt, evidence item, public key, or causal parent set causes offline replay to fail.

Human Agency Profiles further restrict the usable capability set. The effective permission is the intersection of the WorkOrder, CapabilityGrant, and active profile. An action marked reserved stops before execution with AGENCY_HUMAN_DECISION_REQUIRED; an appeal records a signed review request but does not restore or enlarge authority.

Setup and configuration

The published core can be installed from PyPI:

bash
python -m pip install openworkproof
owp --help

For protocol or adapter development, the repository documents editable installation from source. The command-line interface supports offline surface verification, acceptance-bundle verification, and delivery-case inspection, verification, and export. The repository also lists MCP as an integration entry point and provides an MCP-specific guide.

External acceptance uses a prepare → sign → commit flow. The system creates a draft without the acceptor's private key, the designated acceptor signs independently, and the signed object is committed before an acceptance bundle is exported.

Tools and capabilities

OpenWorkProof MCP server is suited to workflows that need signed authorization, pre-execution policy checks, action receipts, independent verification, separate human acceptance, and offline evidence review. The project also provides CLI, GitHub Action, AgentTeams, DeepSeek Harness, and Python API entry points, although the DeepSeek Harness integration is described as a local candidate rather than a published npm package.

Verification integrity checks can require coverage of the agreed object population and matching failure characteristics for negative controls. If those checks fail, the conclusion is closed as UNKNOWN rather than treated as verified.

Limitations and notes

The protocol proves that recorded evidence follows the defined chain; it does not prove that a business outcome is universally correct. It does not transfer legal responsibility, certify compliance, hold funds, execute payments, or decide whether a customer should accept work. Acceptance remains the responsibility of the WorkOrder-bound human authority.

The README identifies core version 1.4.0 as published to PyPI, GitHub Releases, and the MCP Registry. DeepSeek Harness 0.1.0 is identified as an unpublished local candidate, so its local test results should not be treated as npm availability, customer adoption, or official vendor endorsement.

Reviews

No reviews yet — be the first to share how it worked for you.

Frequently Asked Questions about OpenWorkProof

OpenWorkProof is an MCP server that connects AI agents to signed work contracts and auditable execution records. Its main capabilities cover authorization, pre-execution policy decisions, action receipts, independent verification, and separate human acceptance. It exports evidence that third parties can verify offline with the package and public keys.

Install the published core with `python -m pip install openworkproof`, then run `owp --help`. The repository also documents editable installation from source and identifies MCP as an integration entry point.

Yes. OpenWorkProof can verify exported Surface and Acceptance bundles offline. A reviewer needs the evidence package and public keys; the verifier checks the signed chain, authorization, evidence relationships, and relevant decisions without connecting to the original system.

Yes. `VERIFIED` records a verifier's conclusion, while `ACCEPTED` or `REJECTED` comes from the WorkOrder-bound acceptor. The protocol uses separate signatures and an acceptance binding, so a valid verification signature cannot by itself represent customer acceptance.

No. OpenWorkProof checks whether evidence supports a conclusion within the frozen scope, but it does not guarantee universal business correctness or make the acceptance decision. Payment, legal effect, customer adoption, and other external outcomes remain separate facts.

Related MCP servers

Add a badge to your READMEShow it’s listed — live SVG, Markdown or HTML.

AllMCPs Directory Badge

Full Badge Customizer

Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.

Badge Style:
Live Dynamic SVG PreviewOpenWorkProof AllMCPs Directory Badge
Markdown (GitHub README)
[![AllMCPs](https://allmcps.com/api/badge/openworkproof?style=directory)](https://allmcps.com/mcp/openworkproof)
HTML Embed
<a href="https://allmcps.com/mcp/openworkproof"><img src="https://allmcps.com/api/badge/openworkproof?style=directory" alt="OpenWorkProof on AllMCPs" /></a>