Can MCP Tools Remember Things Between Calls?

MCP (Model Context Protocol) is designed for stateless tool execution, meaning each tool invocation is independent of any previous calls. But many real-world agent workflows need memory or context the ability to remember facts between calls or share state across steps. This article explores how to design MCP-based tools that maintain context across calls, while honoring MCP's stateless and serverless nature. We’ll look at strategies like token passing, external memory stores, chained planning, and best practices from recent research and tooling.

Stateless by Design

MCP was created as a standardized, stateless protocol for interacting with AI tools. It avoids maintaining tool-specific memory across calls, simplifying scalability and inter-service consistency. Each tool invocation receives a payload, executes, and returns a response nothing more.

Stateless Nature of MCP Tools

• MCP tools are atomic and isolated. They don't preserve session history, shared variables, or runtime context. If a tool depends on counters, memory, or internal references, it cannot function as a pure MCP tool.¹
• MCP servers may be stateless or stateful, but clients should not assume state persistence unless the server provides it explicitly.²
• Statelessness facilitates horizontal scaling, easier tool discovery, and federation of tool networks but it also limits the tool's ability to "remember."²

Approaches to Add Memory Between Calls

Despite stateless constraints, several design patterns enable persistent context for MCP tools. Here are the most effective strategies:

1. Token-Passing

How it works: The agent maintains the context. Each call includes a “token” or context snippet like conversation history or state that the tool can consume and possibly update.

Why use it:

• Keeps MCP tools stateless they still rely solely on provided data.
• Agent orchestrates memory; tools don’t need to store state.

Trade-offs:

• Context size may grow rapidly, consuming tokens.
• Agent must manage, trim, and structure context.

2. External Memory Stores (e.g., Redis)

How it works: MCP server or a separate memory service (like Redis) stores state outside the agent. Tools retrieve context via key or session ID, operate, and then update memory.

Evidence & Tools:

• Redis offers a dedicated Agent Memory Server with MCP interface: supports working and long-term memory, with REST & MCP APIs, session isolation, and authentication.³
• In-memory state stores (Python dictionaries, databases, vector stores) function as context stores within MCP servers.⁴
• Redis MCP integrations (e.g., mcp‑redis, mcp‑redis‑cloud) let MCP clients directly query structured data, embeddings, or key-value pairs.⁵
• Example of real memory: CCMem (Claude Code Memory) uses SQLite via MCP to maintain project-aware memory across coding sessions.⁶

Example call flow:

1. Agent calls MCP memory tool with session ID.
2. Tool retrieves memory (e.g., project notes).
3. Agent includes updated memory in next prompt or tool call.

Trade-offs:

• Requires server or memory store deployment.
• More overhead, but enables rich context without token bloat.

3. Chained Planning Tools

How it works: Orchestrate multi-step workflows where each step invokes a tool via MCP, and the agent collects outputs to pass to the next step.

Advantages:

• Keeps each MCP tool call atomic.
• Memory is managed through chain output, not internal state.

Useful patterns:

• MCP-Zero: dynamically selects tools via structured requests, reducing prompt cost and enabling multi-step planning efficiently.⁷
• MemTool: a short-term memory framework that supervises dynamic tool calling across multi-turn conversations; supports autonomous, workflow, or hybrid modes.⁸

Trade-offs:

• More logic on the agent side.
• Requires careful chaining and output handling.

4. Hybrid Strategies

Combine approaches based on needs:

• For short-term state, use token-passing.
• For persistent or larger memory, leverage external storage like Redis or SQLite via MCP servers.
• For multi-step reasoning, chain tool calls and manage state outputs centrally.

Behind the Scenes: How MCP Enables or Restricts Memory

Understanding MCP internals is key to designing memory workflows.

MCP Protocol Fundamentals

• MCP is an open protocol introduced by Anthropic in November 2024, using JSON‑RPC over stdio or HTTP, with optional SSE streaming.⁹
• Implementations include SDKs in Python, TypeScript, Java, C#. MCP servers can connect AI agents to tools like GitHub, Slack, Stripe, or databases, with secure, structured interfaces.⁹

Stateless vs Stateful MCP Servers

• MCP servers can be stateless, handling one-off operations (e.g., search), or stateful, maintaining context across sessions via in-memory or persistent storage.²
• Stateful servers support longer-lived connections via session orchestration or mcp_connection context managers.²

Real-World Implementations

• Context store examples: In-memory dicts, databases, vector stores are backbones for MCP memory tools, allowing caching and speed improvements.⁴
• Redis MCP integration: Enables efficient memory lookup for agents, combining tool outputs and memory management securely.³⁵
• CCMem: A practical project to give Claude Code persistent project memory via SQLite, shows how MCP tools can hold memory across sessions.⁶

My Thoughts

In my view, helping stateless MCP tools remember things hinges on smart agent design combined with lightweight memory infrastructure.

• Token-passing works well in small-scale, low-memory scenarios. It’s simple and elegant, but token constraints limit scalability.
• External memory storage is more robust and adaptable. Redis-backed MCP memory tools give agents powerful context retention, session isolation, and scalable performance.
• Chained planning (via frameworks like MCP-Zero or MemTool) provides structure and modularity, supporting complex, multi-step workflows.
• Efficient memory strategies will likely combine these methods: in-memory short-term with database-backed long-term, all orchestrated via chain-based tool workflows.

As MCP adoption grows in enterprise tools and serverless agents, memory support will be a key evolution, especially as the protocol matures and server personalization becomes more sophisticated.

References