# MCP Provenance Extension — Proposal Draft

**Status:** Draft proposal — not submitted, not endorsed by Anthropic or the MCP specification authors.
**Author:** AiGentsy
**Date:** March 2026

---

## Summary

This document proposes a provenance extension for the Model Context Protocol (MCP) that would allow MCP tool servers to attach verifiable proof metadata to tool outputs. The goal is to enable any MCP-compatible client to verify that a tool result was produced by a specific agent, at a specific time, with specific inputs — without trusting the tool server itself.

## Problem

MCP tool servers return results to clients (Claude Desktop, Cursor, Cline, etc.), but there is currently no standard way to:

1. **Prove** which agent produced a result
2. **Verify** that a result has not been modified after creation
3. **Anchor** the result in a tamper-evident log
4. **Export** a portable receipt for the tool execution

Clients must trust the tool server entirely. There is no independent verification mechanism.

## Proposed Extension

### Provenance Metadata in Tool Results

Add an optional `provenance` field to MCP tool results:

```json
{
  "content": [
    {
      "type": "text",
      "text": "Analysis complete. 12 insights generated."
    }
  ],
  "provenance": {
    "spec_version": "1.0.0",
    "proof_hash": "sha256:abc123...",
    "deal_id": "deal_xxxxxxxxxxxxx",
    "agent_id": "agent_yyyyy",
    "timestamp": "2026-03-21T12:00:00Z",
    "verify_url": "https://provider.example/proof/deal_xxxxxxxxxxxxx/verify",
    "bundle_url": "https://provider.example/proof/deal_xxxxxxxxxxxxx",
    "log_inclusion": {
      "tree_size": 1024,
      "leaf_index": 1023,
      "root_hash": "sha256:def456..."
    }
  }
}
```

### Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `spec_version` | string | Yes | Provenance spec version |
| `proof_hash` | string | Yes | SHA-256 hash of the proof content |
| `deal_id` | string | Yes | Unique identifier for this proof |
| `agent_id` | string | Yes | Agent that produced the result |
| `timestamp` | string | Yes | ISO 8601 timestamp |
| `verify_url` | string | No | URL for independent verification |
| `bundle_url` | string | No | URL to fetch portable proof bundle |
| `log_inclusion` | object | No | Merkle transparency log inclusion data |
| `log_inclusion.tree_size` | integer | No | Log tree size at time of inclusion |
| `log_inclusion.leaf_index` | integer | No | Index of this entry in the log |
| `log_inclusion.root_hash` | string | No | Merkle root hash at time of inclusion |

### Client Behavior

- Clients **MAY** display provenance metadata to users
- Clients **MAY** verify proof hashes independently
- Clients **SHOULD NOT** block on provenance verification (it is informational)
- Clients **MAY** fetch and cache proof bundles for offline verification

### Server Behavior

- Tool servers **MAY** attach provenance metadata to any tool result
- The provenance provider is the tool server's choice — it is not mandated by MCP
- Tool servers **SHOULD** use a verifiable proof system (hash-based, not self-asserted)
- Tool servers **MUST NOT** fabricate provenance — if no proof exists, omit the field

## Why This Matters

As AI agents execute real work (content generation, code review, research, design), the provenance of that work becomes commercially and legally important:

- **Accountability:** Which agent did this work?
- **Auditability:** Can the work be verified after the fact?
- **Portability:** Can the proof of work travel with the output?
- **Non-repudiation:** Can either party deny the transaction?

Provenance transforms MCP from a tool execution protocol into a **verifiable work protocol**.

## Implementation Reference

AiGentsy's existing MCP tool server already produces proof metadata via the `/protocol/stamp` endpoint. A reference implementation is available:

- MCP tool server: [aigentsy-mcp on PyPI](https://pypi.org/project/aigentsy-mcp/) — `pip install aigentsy-mcp`
- Proof bundle spec: [proof_bundle_spec.md](https://aigentsy.com/data/proof_bundle_spec.md)
- Conformance vectors: [conformance_vectors.json](https://aigentsy.com/data/conformance_vectors.json)
- Protocol design note: [protocol_design_note.md](https://aigentsy.com/docs/protocol_design_note.md)

## Compatibility

This proposal is designed to be:

- **Backward-compatible:** The `provenance` field is optional. Existing clients ignore unknown fields.
- **Provider-agnostic:** Any proof system can populate the fields. AiGentsy is one implementation; others could use different backends.
- **Non-breaking:** No changes to the MCP transport, tool registration, or capability negotiation are required.

## Open Questions

1. Should provenance be a first-class MCP capability that clients can negotiate?
2. Should there be a standard verification algorithm, or is it provider-specific?
3. Should provenance apply to resources and prompts as well as tool results?
4. How should provenance interact with MCP's existing logging/sampling features?

---

*This document is a draft proposal by AiGentsy. It has not been submitted to or endorsed by the MCP specification authors. The proposal is shared publicly for community discussion and to demonstrate the technical feasibility of provenance extensions.*