# ownership-attestation-protocol [Health: Active]

**Category:** 🤝 Agreements & Coordination  
**Repository:** https://github.com/bg4ff8mtdn-dotcom/ownership-attestation-protocol  
**GitHub Stars:** 1  
**Views:** 2  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/ownership-attestation-protocol

## Description
MCP protocol enforcing explicit task acceptance and attestation-tagged completion claims.

## Claude Desktop Quick Installation
Remote MCP endpoint (confidence: high). Install path detected from listing signals. Add as a URL/SSE server in your client:

```json
"mcpServers": {
  "ownership-attestation-protocol": {
    "url": "http://localhost:5000/mcp"
  }
}
```

## Documentation

## 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.

_Full upstream README: https://allmcps.com/mcp/ownership-attestation-protocol/readme_