Server data from the Official MCP Registry
MCP protocol requiring task acceptance and provenance tags. Self-hosted only - see README.
MCP protocol requiring task acceptance and provenance tags. Self-hosted only - see README.
Remote endpoints: streamable-http: https://ownership-provenance-protocol.replit.app/mcp
Valid MCP server (3 strong, 2 medium validity signals). No known CVEs in dependencies. Imported from the Official MCP Registry.
Endpoint verified · Requires authentication · 1 issue found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
This plugin requests these system permissions. Most are normal for its category.
Remote Plugin
No local installation needed. Your AI client connects to the remote endpoint directly.
Add this to your MCP configuration to connect:
{
"mcpServers": {
"io-github-bg4ff8mtdn-dotcom-ownership-provenance-protocol": {
"url": "https://ownership-provenance-protocol.replit.app/mcp"
}
}
}From the project's GitHub README.
A small MCP protocol that enforces two rules no mainstream agent framework currently enforces natively:
Observed (I did this myself), Reviewed (I checked evidence of it), or Reported (I'm relaying what I was told). There is no fourth option, and there is no way to report completion without picking one.That's the whole protocol. Everything else in this repo exists in service of those two rules.
Broken ownership handoffs are named as the #1 failure mode in production multi-agent systems — an agent hands work to another agent, context gets lost, and nobody ends up owning the result. Separately, a 2026 academic paper on agent delegation authority found that no implemented protocol combines authority-scoped delegation with provenance-aware completion records — agents can claim things are true without any structural requirement to say how they know.
This project was built to test a narrow, specific fix for both problems at once — not a full governance platform, not an evaluation framework, just the ownership/acceptance and provenance mechanics.
Two documented, public incidents shaped this design directly:
Both failures are the same shape: a claim stated with more confidence than it had earned. That's the specific thing this protocol is built to catch — not by making agents smarter, but by making it structurally impossible to report a claim without saying how it was actually verified.
| Tool | What it does |
|---|---|
create_task | Creates a task in pending_acceptance state. Nothing is owned yet. |
accept_task | Explicit acceptance. Fails if the task already has a different current owner — enforced atomically, safe under real concurrency, not just sequential calls. |
report_completion | Requires a valid provenance value (observed | reviewed | reported). Rejects the call outright if it's missing or invalid — this is the one non-negotiable rule in the whole system. |
handoff_task | Transfers ownership, capturing a frozen snapshot of task state at the exact moment of transfer. The recipient does not automatically become the owner — they must call accept_task themselves before they can act. |
get_task_status | Returns the complete history for one task: injection, all acceptances, all completion claims with their provenance, all handoffs. |
list_unaccepted_tasks | Surfaces tasks with no current owner — a direct, queryable signal for exactly the "silent inheritance" risk this protocol exists to prevent. |
These six statements hold in any conformant implementation, at all times:
An implementation is OPP-conformant if it requires explicit acceptance, rejects claims without provenance, supports all three provenance categories, preserves reconstructable history, and supports ownership transfer via handoff. Partial implementations should describe themselves as "OPP-inspired," not conformant.
Fair question, and the short answer is that OPP is meant to sit alongside these, not replace them:
Requirements: Node.js 24, PostgreSQL, pnpm.
pnpm install
Set the required environment variables:
DATABASE_URL=<your Postgres connection string>
MCP_ACCESS_TOKEN=<a long random string — generate one with `openssl rand -hex 32`>
Push the schema and start the API server:
pnpm --filter @workspace/db run push
pnpm --filter @workspace/api-server run dev
The MCP server is mounted at /mcp and requires the MCP_ACCESS_TOKEN as a bearer token in the Authorization header on every request except /api/healthz, which stays open for health checks.
Connect a real MCP client (e.g. Claude Code):
claude mcp add --transport http opp http://localhost:5000/mcp --header "Authorization: Bearer <your-token>"
This is an early, personally-tested project, not a polished product. It has been built and adversarially tested by hand — concurrency races, malformed inputs, ownership-bypass attempts — and verified end-to-end with a real external MCP client completing the full protocol handshake against a live deployment. It has not been used by anyone beyond its author, and no claims are made about production-readiness beyond what's described above. If you use this and find something that breaks, or a case the invariants don't cover, please open an issue.
MIT
Be the first to review this server!
by Modelcontextprotocol · Developer Tools
Read, search, and manipulate Git repositories programmatically
by Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.
by mcp-marketplace · Developer Tools
Create, build, and publish Python MCP servers to PyPI — conversationally.