Ownership Attestation Protocol

What the ownership-attestation-protocol MCP server does

The ownership-attestation-protocol MCP server provides a narrow protocol for tracking who has accepted a task and how an actor knows that the task is complete. A newly created task starts without an owner. Assignment, context, or handoff does not establish ownership; the proposed recipient must explicitly accept the task.

Completion claims must include one of three provenance values: observed, reviewed, or reported. An observed claim means the reporting actor performed the work, a reviewed claim means the actor checked evidence, and a reported claim relays information from another source. Calls with a missing or invalid value are rejected.

The implementation also prevents an observed claim from replacing a reported claim on the same task unless the request identifies the evidence checked through sourceReference. Handoffs retain a state snapshot, and task history can be reconstructed from the recorded events.

How it works

Tasks are created in pending_acceptance. accept_task establishes ownership only when the task does not already have a different current owner. The acceptance check is atomic, allowing concurrent requests to contend safely rather than relying on sequential application behavior.

handoff_task transfers responsibility while recording the task state at transfer time. The recipient remains unowned until it calls accept_task. get_task_status returns the task’s injection, acceptances, completion claims and provenance, and handoffs. list_unaccepted_tasks identifies tasks without a current owner, making silent inheritance queryable.

The protocol is intended to complement logs, Git, OpenTelemetry, or durable execution systems. Those systems can record events, content, traces, or execution state, while this protocol focuses specifically on explicit acceptance and the basis for completion claims.

Setup and configuration

Local operation requires Node.js 24, PostgreSQL, and pnpm. Install dependencies with pnpm install, push the database schema, and start the API server with the repository’s workspace commands.

Set DATABASE_URL to the PostgreSQL connection string and MCP_ACCESS_TOKEN to a long random bearer-token value. The MCP endpoint is /mcp; requests require that token in the Authorization header. /api/healthz is exempt for health checks.

Create an actor before using any protocol tool. Actor identity is supplied by an external identity system, and the server does not expose a create_actor tool or route. The repository includes a local seed script for creating an actor during development. Connect an MCP client over HTTP, such as Claude Code, using the bearer token.

Tools and capabilities

The six protocol tools are:

• create_task: creates a task awaiting acceptance.
• accept_task: explicitly claims a task, with an atomic ownership check.
• report_completion: records a completion claim with required provenance.
• handoff_task: transfers a task and saves a state snapshot.
• get_task_status: returns the complete recorded history for one task.
• list_unaccepted_tasks: lists tasks that have no current owner.

The ownership-attestation-protocol MCP server has automated tests for malformed inputs, ownership bypass attempts, and concurrent database transactions. The test suite requires a real PostgreSQL instance and uses a separate loopback test connection by default.

Limitations and notes

The project is described as early and personally tested, with no reported use beyond its author. It makes no broader production-readiness claim. The implementation requires actors to exist before tool calls, and the test runner deliberately ignores DATABASE_URL so it cannot accidentally use a non-loopback database. Partial implementations should not describe themselves as conformant unless they support explicit acceptance, all three provenance categories, reconstructable history, and ownership transfer through handoff.