Montycat MCP

MCP Server for Shared AI Agent Memory

AI agents start every session blank, and each one keeps whatever it learns to itself. Montycat MCP is a self-hosted Model Context Protocol server that gives them one memory instead — Claude, Codex, Cursor, and open-source agents on local models writing and reading the same facts, recalled by meaning, by keyword, or both. Your engine, your hardware, no hosted memory service.

Get the Claude Desktop extension

What is an MCP memory server?

The Model Context Protocol is how an AI client hands its model a set of tools. An MCP memory server is one that offers tools for remembering and recalling, so the model can store a fact during one conversation and retrieve it in the next — without you building storage into every agent you write.

Most memory servers stop there: one process, one memory, one client. Montycat MCP puts the memory in a real database instead, so several agents and several clients can share it, and so recall is a proper search rather than a file scan.

Shared memory is the point

A memory only one agent can read is a cache. Sharing is what makes it infrastructure:

  • Point Claude Desktop, Claude Code, Codex, and Cursor at the same engine and keyspace, and they read and write one memory.
  • Scopes decide where a memory lives — a private namespace per person, a shared one per team, or a common one for everything.
  • An agent can wait for another agent to write, so a researcher agent can hand off to a writer agent without either polling.
  • Sharing requires the same engine and keyspace: two separate local engines do not synchronize, which is what keeps a private scope private.

Install it in your client

Each client has its own path, and none of them need a cloud account:

  • Claude Desktop — download the .mcpb bundle and drag it in. No Python required.
  • Claude Code — /plugin marketplace add MontyGovernance/montycat-mcp, then /plugin install montycat-mcp@montygovernance.
  • Codex — codex mcp add montycat -- uvx montycat-mcp.
  • Cursor and any other MCP client — point its stdio configuration at uvx montycat-mcp (Python 3.10+).
  • Open-source agent frameworks — anything with an MCP client can launch uvx montycat-mcp over stdio, whatever model is behind it.

Open-source agents and local models

Montycat MCP has no model dependency. Its only two dependencies are the MCP SDK and the Montycat client — there is no Anthropic or OpenAI SDK in it, and it never sends a prompt anywhere. It answers tool calls over stdio, so whatever model is driving the agent is entirely your business.

That makes it a fit for open-source stacks in a way hosted memory services are not. Run Llama, Qwen, Mistral, or anything else through Ollama or vLLM, drive it with a framework that speaks MCP — LangGraph, Pydantic AI, the OpenAI Agents SDK, Goose, Cline, Continue — and point that framework at uvx montycat-mcp. Check your framework’s MCP client support; the transport is stdio.

Assembled that way the whole stack is local: the model, the agent, the memory server, the database, and the embeddings. Nothing leaves the machine, which is the point for air-gapped, regulated, and privacy-sensitive work — and it means a self-hosted agent gets the same memory a frontier model does, and can share one with it.

The engine behind it

Memory lives in a self-hosted Montycat Semantic engine, which Montycat MCP will start locally for you. Point it at an engine you already run with MONTYCAT_URI, or start one with Docker.

Because the engine is a NoSQL store and a vector index in one, a memory is a real record: searchable by meaning, filterable by indexed metadata and timestamp, and retrievable by exact key. Keyword and hybrid ranking need Montycat Semantic 1.3.4 or newer.

What the agent can actually do

Twenty-three tools, named montycat_*, grouped by what they are for:

  • Store — montycat_remember, montycat_remember_bulk, montycat_update, montycat_forget.
  • Recall — montycat_semantic_search, montycat_recall, montycat_list_memories.
  • Collaborate — montycat_await_memory_change, which blocks until another agent writes.
  • Namespaces — montycat_list_keyspaces, montycat_create_keyspace, montycat_remove_keyspace.
  • Operate — semantic status and re-embedding, external vector enrollment, snapshots, and policy inspection.
  • Destructive tools are declared as such in MCP metadata, so your client applies its normal confirmation rules.

Add it to any MCP client

# Codex
codex mcp add montycat -- uvx montycat-mcp

# Any stdio MCP client: run `uvx montycat-mcp`, optionally against
# an engine you already run
export MONTYCAT_URI="montycat://memory-agent:password@localhost:21210/memories"

# Then just talk to your agent:
#   "Remember that the team chose PostgreSQL for the billing service."
#   "What did we decide about the billing database?"
#   "Save this to the shared engineering scope."

Download the Claude Desktop extension · Montycat MCP on GitHub

FAQ

What is Montycat MCP?

A self-hosted Model Context Protocol server that exposes a Montycat engine as shared, persistent memory for AI agents. Any MCP client — Claude Desktop, Claude Code, Codex, Cursor — can store facts and recall them later by meaning, by keyword, or by exact key.

Can two different AI agents share one memory?

Yes. That is the design. Every client connected to the same engine and keyspace reads and writes the same memory, and an agent can wait for another agent to write rather than polling. Separate local engines do not synchronize.

Does my data leave my machine?

No. The MCP server and the engine run locally by default, embeddings are computed on-device, and there is no hosted memory service or cloud embedding API in the path. Montycat MCP ships no telemetry that sends memory contents anywhere.

How is this different from a file-based memory server?

Memory lives in a database rather than a directory, so recall is vector, BM25, or hybrid ranking with metadata and time filters — not a file scan. It also means several agents can share it safely, and memory survives independently of any one client.

Does it work with open-source LLMs and local models?

Yes. The server never calls a model — it answers MCP tool calls over stdio — so a Llama, Qwen, or Mistral agent running through Ollama or vLLM uses it exactly like Claude does, and can share the same memory. The only requirement is that your agent framework has an MCP client.

Can the whole stack run offline?

Yes. With a local model, a local agent framework, Montycat MCP, and a self-hosted Montycat engine, every part runs on your machine — embeddings included, since they are computed on-device. There is no hosted memory service and no cloud embedding API in the path.

Do I need to run a separate vector database?

No. The Montycat engine stores the records and their embeddings together, so there is one service to run and nothing to keep in sync.

Which clients are supported?

Anything that speaks MCP over stdio. Claude Desktop installs a .mcpb bundle, Claude Code installs a plugin, and Codex, Cursor, and others run uvx montycat-mcp. Python 3.10 or newer is required for the uvx, pipx, and pip paths.

Explore