A memory backend behind the Model Context Protocol.
MCP standardizes how agent clients call tools. It does not specify where memory lives. RushDB’s MCP server exposes records, relationships, queries, and schema discovery as tools, so an MCP client gets a real memory backend instead of only prompt-stuffed context.
An MCP memory backend is a database exposed to Model Context Protocol clients as a set of tools — letting an agent store and recall structured memory through MCP instead of relying only on conversation history stuffed into the prompt.
What this guide covers
The practical decision points.
MCP is the transport, not the memory
The protocol standardizes tool discovery and invocation. Whether those tools touch durable memory depends on what server you connect.
Discovery before action
RushDB’s MCP server is built discovery-first: an agent can inspect schema before constructing a query, reducing hallucinated fields and labels.
One backend, many clients
The same RushDB project can back memory for Claude Desktop, Cursor, VS Code, and other MCP-compatible clients at once.
Architecture sketch
Where the MCP server sits
The MCP client calls tools exposed by the RushDB MCP server. Those tools operate on the same Records, relationships, and schema available through the REST API and SDKs.
Implementation example
Add the MCP server, then let the agent discover before it queries
Configuration is a local MCP server entry. The discovery-first workflow — schema, then query — is what the tools are designed around, not something you have to prompt for separately.
# MCP tools are invoked by the client, not called directly from Python.
# This is the equivalent SDK call the MCP tool wraps, useful for testing
# the same memory outside an MCP client.
from rushdb import RushDB
db = RushDB("RUSHDB_API_KEY")
schema = db.ai.get_schema_markdown({"labels": ["MEMORY"]}).data
print(schema)What the MCP server exposes
The documented tool surface covers records, relationships, queries, bulk operations, exports, and transactions — the same capabilities available through the REST API and SDKs, packaged as MCP tools.
Why discovery-first matters for memory backends
A memory backend an agent can’t inspect is only marginally better than no memory backend — the agent still has to guess field names and relationship paths. RushDB’s MCP tools are designed around checking schema first, so an agent builds queries against what actually exists in the project rather than a stale prompt description.
Decision table
Prompt-only context vs MCP-backed memory
MCP does not require durable memory — a server can expose stateless tools with no storage at all. The comparison here is between that stateless pattern and connecting MCP to an actual memory backend.
In the conversation transcript or whatever the client keeps in context.
In RushDB Records, queryable independently of any single conversation.
Limited to what the client re-sends as context on the next session.
Available by semantic search, exact filters, or relationship traversal at any time.
The agent relies on whatever schema notes are in the system prompt.
The agent can call a schema tool to see current labels, properties, and relationships before querying.
Each client/session may accumulate its own inconsistent notion of state.
Claude Desktop, Cursor, and other connected clients read and write the same underlying memory.
Related RushDB docs
Read the primitives behind the guide.
These docs links are the implementation references for the concepts explained on this page.