Scroll the MCP server lists from the last few months. You'll see a category emerging: memory servers. They give your AI client a place to remember things across sessions. They handle the storage, the retrieval, sometimes the embeddings. They do the recall job and they do it well.

They also stop there.

That stopping point is interesting. Memory is genuinely a good wedge — it's the highest-frequency pain in the daily AI workflow, and it's easy to demo. But the user's broader workflow has more in it than recall. There are prompts the user wants to reuse. There are snippets they want to keep. There are credentials the assistant needs to act. There are durable project facts that don't fit neatly under "memory."

Memory-only servers do not own any of those. The whitespace is still open.

Why memory-only servers exist

It's worth understanding why this design has been so common. The reasons are pragmatic.

Memory is shippable in a weekend. A simple memory MCP server is a small surface: save, search, list, delete. You can ship a credible v1 in a few days. The demos write themselves.

Memory is the loudest complaint. "AI forgot what we talked about" is the most common piece of user feedback. Building a memory tool feels like the obvious response.

Memory has good metaphors. "Your AI's brain" is a clean tagline. The product is easy to explain.

These are all real advantages, and they explain the proliferation. The downside is that they encourage stopping where the shipping is easy rather than where the user's workflow is.

What memory-only misses

When a user actually sits down with one of these tools, they hit the boundary fast.

Prompts. The user has prompts they want to reuse. The memory server doesn't store prompts as a separate type. The user either stuffs them into memory as plain text (messy retrieval) or keeps them in a different tool (fragmentation).

Snippets. Reusable code blocks, content templates, queries the user wants the model to know about. Same problem: memory schemas weren't built for typed snippet assets.

Credentials. The assistant needs API keys to do real work. The memory server has nothing to say about them. The user falls back to .env files or scattered config.

Project context. Stable facts about a project — the stack, the customers, the conventions — sit awkwardly inside generic memory. They're not transient observations; they're structural. They deserve their own shape.

Recipes. Chains of prompts and operations. No memory server has a place for them.

Each of these is a separate need that overlaps with memory but isn't the same. A memory server treats them all as text blobs. A vault treats them as typed first-class assets.

What a vault adds

A vault is the union of all these assets in one substrate with one set of trust decisions.

Typed entries. Memories, prompts, snippets, recipes, credentials, notes — each with its own schema, its own UI affordances, its own search behavior. Heterogeneous, not homogeneous.

Cross-asset references. A prompt references a snippet. A recipe references prompts. A memory references a project. The asset graph mirrors how the work actually fits together.

Single trust boundary. The user decides once how to feel about the vault. They don't make separate decisions about a memory tool, a prompt tool, a credentials tool, and a notes tool.

Single backup. One export, one backup, one migration. Not five.

Single scope model. When the user switches projects, all asset types reorient at once. Memory, prompts, credentials, and recipes all align with the new context.

This breadth is exactly what memory-only servers leave unbuilt. The user can stitch the pieces together themselves, but the stitching is the work the vault should have done.

Why the broader wedge is more defensible

Building a memory-only MCP server is a small surface. It's also a small moat. The next memory server is one weekend away. Differentiation has to come from somewhere other than features that are easy to copy.

A vault that owns the breadth — prompts, memories, snippets, credentials, recipes — has more surface to differentiate on. Not because more features is always better, but because the integration between asset types is where the user value compounds. Anyone can ship a memory feature; integrating memory with prompts and credentials cleanly is genuinely harder, which means the moat is real.

This also changes the user's switching cost. A user who has invested in a memory-only server can move to another memory server with a single export. A user who has invested in a vault has years of cross-referenced prompts, memories, snippets, and credentials. The vault doesn't lock them in — it grows with them in ways another product can't match without the same breadth.

What this means for the MCP ecosystem

The memory-only servers have done useful work. They validated that users want recall as a first-class capability. They proved MCP is the right plumbing for cross-client access. They taught users to expect their AI clients to know things across sessions.

The next wave of MCP servers will benefit from that groundwork by aiming wider. A vault MCP server isn't competing with memory servers — it's eating the larger pie that memory servers staked out the edge of.

Users who started with a memory server will, within months, ask their server for prompt support, snippet support, credential support. The server either grows into a vault or loses users to one. The momentum is one-directional.

What this means for builders

If you're building in this space, the strategic question is whether to be a memory tool, a vault, or something narrower.

A memory tool is easy to ship and easy to copy. The first one had differentiation; the tenth doesn't. Good for fast learning, hard for long-term moat.

A vault is harder to ship and harder to copy. The differentiation comes from integration between asset types and from the trust posture (local-first, encrypted, scoped). Worth the heavier build.

A narrower tool — credentials only, prompts only, snippets only — is also fine, but the same trajectory plays out: users want unification within a year and the tool either expands or loses ground.

There isn't a wrong answer, but the answers that age best are the ones that aim at the substrate breadth. The user's workflow is broad. The substrate that serves it has to be broad too.

What this means for users

If you're a user picking an MCP server today, ask whether it's planning to stay narrow or expand. A narrow tool can be the right call for a one-off need. A vault is the right call for the substrate underneath your AI workflow.

A short way to tell: read the tool's roadmap. If the roadmap is "better memory search," the tool is committed to staying narrow. If the roadmap mentions prompts, snippets, credentials, scopes, and recipes, the tool is moving toward the breadth your workflow needs.

Picking the tool that's aiming wide saves you the migration step a year from now.

The summary

Memory-only MCP servers proved a category. The unmet opportunity is broader: prompts, snippets, credentials, recipes, and durable project context in the same substrate. Vaults that own that breadth have a moat that memory-only servers can't reach, and users who invest in vaults will avoid the migration that memory-only users will eventually have to make. The wedge is wider than memory. Build accordingly.