Thanks for raising this, pulling together a few earlier threads on memory in MCP here, since the maintainers have already weighed in on a very similar proposal and the position they staked out is probably the main thing to address before drafting:

When SEP-2342 (Memory Interchange Format) was proposed earlier this year, two core maintainers explained why memory standardization sits outside MCP's current scope:

"MCP at a protocol level establishes a set of primitives and is not necessarily opinionated about what is being transported across as long as it maps to those primitives. There is also no single standard adopted for memories, so I am not entirely sure what we're establishing a baseline against."
(PR #2342 comment, 2026-03-03)

"My sense here is the way this should work out is that (1) the broader AI community agrees on a standard memory format, and then (2) we can consider whether it makes sense for MCP to tie itself to that standard. […] Episodic/runtime memory and knowledge bases don't appear to be even close to any sort of convergence. […] Memory extends well beyond MCP, so I don't think we have the necessary authority to be able to set this standard, and I don't think people are looking to MCP to make a decision."
(PR #2342 comment, 2026-03-05)

"I think what @pja-ant outlined here makes a ton of sense — this is not necessarily a MCP concern, and I don't see how MCP should be the one standardizing memory formats, given the impact on the ecosystem and MCP's current role in it."
(PR #2342 comment, 2026-03-05)

Based on the maintainer comments above, a proposal that just adds a memory capability alongside tools/resources/prompts will likely run into the same "MCP shouldn't standardize what isn't yet converged" response. I think it would be a better angle to contribute towards other memory providers aligning on a common shape first before proposing support for that in MCP.

Agreeing with the maintainer position quoted above: memory formats haven't converged, so a new capability type would be premature. A data point from the implementation side that supports that stance —

SAIHM is an Apache 2.0 memory implementation that runs entirely over MCP's existing tools primitive: memory is three tools (remember, recall, forget), no protocol extension. The primitives turned out to be sufficient. What was non-obvious wasn't the transport but two semantics any "common shape" would still have to pin down:

• Scoping — memories are keyed per agent identity, with explicit share/revoke between agents rather than one global namespace.
• Eviction — "forget" destroys the data's encryption key (which lives on COTI V2) rather than soft-deleting the record, so deletion semantics, not just retention/TTL, become part of the contract.

So +1 to memory providers converging on a common shape first. If a thread forms on that, scoping and erasure are the two places implementations seem most likely to diverge — and probably where alignment would pay off most.

Following olaservo's point that providers should converge on a shape before MCP considers standardizing, and citw2's that scoping and erasure are where implementations diverge — a data point from the other end of that space, because ours lands opposite to SAIHM's on both.

We've been building piia-engram, a local-first memory layer that several coding tools (Claude Code, Codex, Cursor) point at as one store the user owns. Because it's single-user and multi-tool rather than multi-agent-team, scoping isn't an access question for us — there's no "which agent may read this" to resolve, the user owns all of it. What we actually need to scope by is provenance: every entry records which tool wrote it and when, so a later session can tell its own past writes apart from another tool's. That's a different primitive than per-agent share/revoke — it's aimed at attribution, not access control.

Erasure diverges the same way. We deliberately don't make hard deletion the default lifecycle — a superseded fact is versioned and kept as superseded, not destroyed, because in a personal store "what did I once believe, and what corrected it" is usually worth more than true erasure. Real deletion exists but is the exception, not the contract. That's close to the opposite of erasure-by-key-destruction, where the whole point is that the data becomes unrecoverable.

Which is maybe the useful part here: two implementations in this thread already scope and delete differently, and not because one is wrong — because one serves a personal multi-tool store and the other a multi-agent team. So a "common shape" probably can't pick a single scoping or erasure model. The more tractable target might be to name the axes — attribution vs access-control scoping, supersede vs destroy erasure — and let implementations declare where they sit, rather than force one answer. Happy to write up our side in more detail if a thread forms on it.