Summary

Today an MCP tool response is trusted implicitly: the client receives content and has no
standard, structured way to answer "what produced this, when, and can I check it later?"
As agents increasingly chain tool calls — and as one agent's output becomes another's
input — it's worth asking whether the protocol should define an optional place for
tool results to carry verification metadata.

This is a question, not a finished proposal. I'd like to gauge whether the maintainers and
community see this as in-scope for the spec, out-of-scope (better left to implementations),
or already solved by something I've missed.

The gap

A tool result is currently content plus an isError flag. There's no standardized,
machine-readable channel for a server to assert things like:

• Provenance — which server/version/tool produced this result
• Integrity — a hash of the inputs and outputs, so a downstream consumer can detect
  tampering or drift if the same result is replayed or cached
• Timestamp — when the work was actually performed (vs. when it was returned)

Servers can stuff this into ad-hoc fields today, but because it's non-standard, no client
or downstream agent can rely on it. That's the part a spec could fix: a defined, optional
shape that tooling can recognize.

Why it matters now

• Multi-agent pipelines: when agent B consumes agent A's tool output, B has no
  protocol-level way to confirm the output's origin or that it wasn't altered in transit.
• Caching/replay: agents increasingly cache tool results. Integrity metadata lets a
  consumer tell a fresh result from a stale or substituted one.
• Auditing: post-incident, "which tool call produced this claim, and when?" is hard to
  answer reconstructively. A structured, optional field makes it answerable by design.

What I am explicitly NOT proposing

• Not mandatory — this should be opt-in. Servers that don't care emit nothing; clients
  that don't care ignore it. Zero impact on the simple case.
• Not a specific crypto scheme, blockchain, or vendor mechanism. The spec would define the
  shape and semantics of an optional metadata field; how a server signs or anchors it (if
  at all) is an implementation choice.
• Not transport-layer security — TLS authenticates the channel, not the claim that a
  specific tool produced a specific result at a specific time.

Sketch (for discussion only)

A possible shape — an optional verification object on a tool result:

{
  "content": [ /* ... */ ],
  "isError": false,
  "verification": {           // OPTIONAL — absence means "unverified", same as today
    "producer": "server-name@1.4.2",
    "produced_at": "2026-06-22T17:00:00Z",
    "input_hash": "sha256:…",
    "output_hash": "sha256:…",
    "signature": "…"          // optional; scheme left to the implementation
  }
}

Open questions I'd genuinely like input on:

1. Is this in-scope for the core spec, or better as a documented convention / extension?
2. If in-scope, does it belong on the tool result, or as a separate capability negotiated
   during initialization (so clients opt in to receiving it)?
3. What's the minimum useful field set? (I suspect producer + produced_at + output_hash
   covers most value; signatures are a separable layer.)
4. Are there existing efforts or prior discussions I should connect this to?

Happy to write this up as a more formal SEP if there's appetite. Mostly I want to find out
whether the problem resonates before investing in a proposal.