19 MCP Tools for AI Memory: What MemPalace's Read-Write Pattern Teaches Meeting Builders

The read-only era is ending

Most MCP servers in production today follow the same blueprint. Wrap an existing API, expose a search and a get, ship it. The agent can query your data. It cannot change it or accumulate knowledge across sessions. Every meeting tool that shipped an MCP server in the last six months followed this pattern: Otter, Fireflies, Granola, Read.ai, Circleback, tl;dv. Search past meetings. Retrieve a transcript. That's it.

On April 6, 2026, MemPalace launched with something different: 19 MCP tools spanning reads, writes, knowledge graph mutations, navigation operations, and agent diary writes. It hit 23,000 GitHub stars in 72 hours. The benchmark numbers were inflated (we'll get to that). The celebrity angle — actress Milla Jovovich as co-creator — was loud. But underneath the noise is an architectural pattern that matters.

If you build MCP servers for meetings, knowledge bases, support tickets, or any corpus where knowledge changes over time, this is the reference implementation to study. Not because you'd use MemPalace directly — it has no meeting support — but because its tool surface defines what "memory MCP" looks like when you move past retrieval.

Quick context on MemPalace

MemPalace is an open-source AI memory system co-created by Jovovich (concept and architecture) and engineer Ben Sigman (code), built with Claude Code over several months. MIT license, Python 3.9+, install via pip install mempalace. Storage backend: ChromaDB for vectors, SQLite for the knowledge graph. The "palace" metaphor — wings, rooms, halls, drawers — is a spatial mental model layered on top of standard ChromaDB metadata filtering. The spatial metaphor is useful for humans thinking about where knowledge lives; the technical mechanism underneath is metadata-scoped vector search. Read our broader analysis of the AI memory week for context on how MemPalace fits into the Karpathy LLM wiki conversation that went viral the same week.

The 19 tools, organized by intent

Connect via: claude mcp add mempalace -- python -m mempalace.mcp_server

Here's the full tool surface, grouped by what they do.

Palace read tools (7)

• mempalace_status — Palace overview. Also injects a PALACE_PROTOCOL instruction telling the AI: "BEFORE RESPONDING about any person, project, or past event: call mempalace_kg_query or mempalace_search FIRST. Never guess — verify." Prompt-injection-as-a-feature.
• mempalace_list_wings — Lists all top-level domains (wings) with drawer counts.
• mempalace_list_rooms — Sub-topics within a specific wing.
• mempalace_get_taxonomy — Full wing-to-room-to-count hierarchy tree.
• mempalace_search — Semantic search with optional wing/room metadata filters. Scoping to wing + room yields +34% retrieval improvement over unfiltered search, per the project's benchmarks on 22,000+ memories.
• mempalace_check_duplicate — Similarity pre-flight check before filing. Prevents the most common write-tool failure mode: duplicate entries from retries.
• mempalace_get_aaak_spec — Returns the AAAK compression dialect spec. AAAK is the project's lossy abbreviation system for token density.

Palace write tools (2)

• mempalace_add_drawer — File verbatim content into a specific wing/room with auto-dedup. Drawer IDs are deterministic: drawer_{wing}_{room}_{md5(source_file + chunk_index)[:16]}. Same content, same ID — retries are safe.
• mempalace_delete_drawer — Remove a drawer by ID.

Two write tools. But they change the entire architectural character. A memory system with only read tools is a search engine. With write tools, it's a knowledge accumulator.

Knowledge graph tools (5)

• mempalace_kg_query — Entity relationships with temporal filtering. Every fact has valid_from and valid_to. You can ask "what did we know about Project X as of March 15?"
• mempalace_kg_add — Add facts as subject-predicate-object triples. Stored in SQLite.
• mempalace_kg_invalidate — Mark a fact as ended by setting valid_to. Non-destructive: old facts preserved, history retained.
• mempalace_kg_timeline — Chronological entity story across all validity windows.
• mempalace_kg_stats — Graph overview: entity count, triple count, active vs. invalidated.

The KG runs on SQLite — a single file on disk. Compare to Zep's Graphiti engine, which requires Neo4j or FalkorDB plus embedding infrastructure.

Navigation tools (3)

• mempalace_traverse — Walk the graph from a room across wings via BFS. Up to 2 hops, max 50 results. Cross-domain discovery.
• mempalace_find_tunnels — Find rooms bridging two wings. A "tunnel" is a room name appearing in multiple wings.
• mempalace_graph_stats — Connectivity overview.

Agent diary tools (2)

• mempalace_diary_write — AAAK-compressed diary entry for a named agent. Separate from the shared palace.
• mempalace_diary_read — Read recent diary entries for a named agent.

The diary tools are the sleeper feature. A named agent can leave notes for itself across sessions without polluting the shared knowledge base. Steph Ango (Obsidian's co-creator) recommended exactly this pattern for the Karpathy wiki: keep agent-maintained content separate from human-maintained content to prevent hallucination contamination. MemPalace shipped it as a first-class tool.

A note on the tool count

The README says 19. Leonard Lin's independent code review (github.com/lhl/agentic-memory) counted 20. Alexey Grigorev's analysis counted 24 in the actual MCP server file. The exact number isn't the point — the categories are. Read tools, write tools, knowledge graph tools, navigation tools, diary tools. That's the shape that matters.

The architectural pattern: tools that mutate state

This is the deeper observation. Forget MemPalace specifically. Look at the pattern.

Read tools alone are not memory. They're search. Every session starts from the same base. The agent re-derives the same answers from the same raw material on every query. Nothing compounds. This is what every meeting MCP does today.

Write tools turn memory into a first-class architectural component. When an agent can call add_drawer, kg_add, or diary_write, it persists what it learned for future sessions. The agent that processed 12 meetings on Monday leaves structured artifacts that Friday's agent builds on. This is the difference between RAG (retrieve and forget) and a knowledge base (retrieve, learn, persist, compound).

Mutation operations need different conventions than retrieval. When your MCP accepts writes:

• Idempotency. Retries shouldn't create duplicates. MemPalace handles this with deterministic drawer IDs and the check_duplicate pre-flight tool. Any write-capable MCP needs an equivalent.
• Temporal validity. "Kai works on Orion" was true in January but not March. MemPalace's kg_invalidate sets a valid_to date instead of overwriting. History preserved, new fact coexists. The right pattern for any knowledge that changes over time.
• Separation of concerns. Agent-generated content should not contaminate human-maintained content. MemPalace's diary tools create a separate workspace per agent. Without this, hallucinations silently enter the knowledge base.

The diary pattern is novel. MemPalace distinguishes between drawers (verbatim content) and diary entries (agent notes). When a meeting-summarizing agent writes "I think Sarah's concern about Q2 might conflict with what Erik said in March," that belongs in a diary, not the knowledge graph. MemPalace got this right.

What MemPalace gets right architecturally

Credit where it's due.

Local-first by default. SQLite + ChromaDB, no cloud dependencies. Compare to Mem0 ($249/month for graph features) or Zep (Neo4j + embedding infrastructure). For enterprises with data sovereignty requirements, local-first is a hard requirement.

The 4-layer loading system. L0 (identity, ~50-100 tokens) always loads. L1 (critical facts, ~120 tokens compressed) auto-loads the top 15 drawers by importance. L2 (room recall) loads on demand. L3 (deep search) fires only when asked. Startup cost bounded; query cost scales with intent. Independent analysis suggests L0 + L1 is closer to 600-900 tokens than the claimed 170, but the principle holds: don't load everything on startup.

Auto-dedup as a first-class operation. check_duplicate runs similarity before filing; add_drawer uses deterministic IDs preventing re-insertion. If you're building a write-capable MCP without a dedup strategy, you'll have a database full of near-duplicates within a week.

Temporal validity windows. Every fact has valid_from and valid_to. Queries filter: AND (t.valid_from IS NULL OR t.valid_from <= ?) AND (t.valid_to IS NULL OR t.valid_to >= ?). Updates don't destroy history. The correct pattern for meeting-derived facts where decisions get revised and commitments shift.

The OpenAPI of memory tools. Even if MemPalace doesn't survive long-term, the tool surface is now a reference. Read, write, KG mutation, navigation, diary — this taxonomy will be the benchmark for future memory MCP servers.

What MemPalace gets wrong (or overpromised)

Honest assessment.

The wings/rooms/halls metaphor is mostly metadata filtering. Leonard Lin's independent analysis (github.com/lhl/agentic-memory) confirmed: everything lives in a single ChromaDB collection called mempalace_drawers. The +34% retrieval boost is standard metadata filtering. The spatial metaphor is a useful mental model, not a technical innovation. Call it a well-designed UX convention on top of commodity vector search.

Contradiction detection is in the README, not in the code. The README shows examples like "AUTH-MIGRATION: attribution conflict — Maya was assigned, not Soren" but knowledge_graph.py contains zero occurrences of "contradict." A separate fact_checker.py exists but isn't wired into KG operations. For meeting builders: contradiction detection across meetings is one of the hardest problems in the space. MemPalace's docs made it look solved. The code shows it isn't.

The "30x lossless" AAAK compression claim was retracted. Both words were wrong. Real token counts via OpenAI's tokenizer: an English example of 66 tokens produced an AAAK version of 73 tokens. AAAK mode scores 84.2% Recall@5 on LongMemEval versus raw mode's 96.6% — a 12.4pp regression. The README now correctly calls AAAK "a lossy abbreviation system... an experimental compression layer that trades fidelity for token density."

The 100% LongMemEval used three targeted patches. From BENCHMARKS.md: hybrid v4 hit 100% (500/500) by adding three fixes for three specific failing questions. GitHub Issue #29 by dial481: "Three patches for three questions. Then the result is reported as 'first perfect score on LongMemEval, 500/500.'" The held-out 450 questions scored 98.4% — still excellent, more honest. The project's own BENCHMARKS.md calls this "teaching to the test."

Recall@5 is not end-to-end QA accuracy. MemPalace measures retrieval recall; Mem0 (49.0%), Zep (63.8%), and Hindsight (91.4%) report end-to-end QA. These are not comparable metrics. As dial481 put it: "A system that retrieves perfectly and then answers wrong scores 100% under recall_any@5 and 0% on the leaderboard." The BEAM 100K benchmark (GitHub Issue #125) tested MemPalace end-to-end: temporal reasoning 69%, contradiction resolution 40%, summarization 35%.

The credit: the project corrected most issues within 72 hours. Sigman publicly acknowledged criticism, updated the README, retracted false claims: "Thank you to everyone who poked holes in this. Brutal honest criticism is exactly what makes open source work." The 96.6% raw retrieval score — independently reproduced by @gizmax on an M2 Ultra (Issue #39) — is real and stands on its own.

What's missing entirely: meetings

Here's the bridge to the meeting builder audience.

MemPalace's documentation and codebase contain zero mentions of "meeting" or "transcript." The conversation miner (normalize.py) expects chat-style turn-taking (> markers, short exchanges) that don't map to meeting transcripts (speaker labels, timestamps, monologues, agenda flow). Supported formats: Claude Code JSONL, Claude.ai JSON, ChatGPT conversations.json, Slack exports, general text. No VTT, SRT, Zoom, Teams, or Meet.

Not a criticism — MemPalace was built for developer conversations and personal knowledge. But the architectural patterns need to be re-implemented, not reused, for meeting-native MCPs. The tool surface transfers. The ingest pipeline doesn't.

What a meeting-native read-write MCP would look like

Map each MemPalace tool category onto meeting-specific equivalents.

Read tools — these are the table stakes that already exist in various forms:

• list_recent_meetings(limit, since) — bounded enumeration with date filters
• get_transcript(transcript_id) — full transcript with speaker labels and timestamps
• search_transcripts(query, limit) — semantic search across the library
• get_meeting_notes(transcript_id) — structured notes, decisions, action items
• find_action_items(item_type, only_open, limit) — commitments across meetings

Write tools — the missing layer that no meeting MCP ships today:

• add_decision(meeting_id, text, participants, status) — assert a decision from a meeting
• add_action_item(meeting_id, assignee, text, due_date) — create a tracked commitment
• link_meetings(meeting_id_a, meeting_id_b, relationship) — connect related meetings
• merge_speakers(source_id, target_id) — resolve speaker identity conflicts across meetings

Knowledge graph tools — temporal validity applied to meeting facts:

• track_commitment(person, commitment, meeting_id) — record what someone committed to, with a validity window
• invalidate_decision(decision_id, superseded_by, meeting_id) — mark a decision as replaced by a later one
• query_project_timeline(project_name) — chronological story of a project across all meetings
• find_speaker_history(speaker_name, topic) — everything a person has said about a topic across meetings

Navigation tools — graph operations across the meeting library:

• traverse_decisions_for_project(project_name) — walk from a project to all related decisions, commitments, and meetings
• find_speakers_across_meetings(meeting_id) — discover who in this meeting also appears in other meetings, and what they discussed
• surface_contradictions(project_name, date_range) — flag decisions that conflict with earlier decisions

Agent diary tools — separate workspace for meeting-processing agents:

• meeting_agent_notes(meeting_id, agent_name, content) — let the summarization agent leave notes about its confidence, flagged uncertainties, and extraction quality without those notes entering the shared knowledge base

This is the shape of the next generation of meeting MCPs. Most of the read tools exist today. The write tools are the missing layer — and they're the layer that turns a meeting search engine into a meeting knowledge base.

The Proudfrog MCP server

The Proudfrog MCP server currently ships 5 read tools:

• list_recent_meetings(limit, since) — recent meetings with metadata
• get_transcript(transcript_id) — full transcript with speaker labels and timestamps
• search_transcripts(query, limit) — full-text search across the library (semantic search coming in v1.1)
• get_meeting_notes(transcript_id) — structured notes including decisions, action items, key topics
• find_action_items(item_type, only_open, limit) — commitments filtered by type and status

Authentication via WorkOS AuthKit (OAuth). Rate-limited per email. Each tool wraps output in <proudfrog_data> delimiters for prompt-injection mitigation — a convention borrowed from Anthropic's own MCP security recommendations. Connect via standard MCP setup in Claude Desktop, ChatGPT, Cursor, or any MCP client.

v1.1 will add semantic search and the first write tools. The full specification follows the patterns described above: read-write, knowledge-graph-aware, meeting-native. We're building toward the tool surface outlined in the previous section — not because MemPalace told us to, but because the read-write pattern is the obvious next step when you've been building read-only tools and watching agents try to accumulate knowledge without persistence.

For the broader product context, Proudfrog is a meeting transcription tool with speaker diarization, entity extraction, and a knowledge graph. We built it at Up North AI because we kept seeing the same gap on consulting engagements: organizations generate most of their knowledge in meetings, and none of that knowledge compounds.

For developers building similar MCPs for their own corpus — meetings, support tickets, CRM notes, code reviews — the patterns matter more than the implementation. Steal them. We did.

The next 12 months for memory MCPs

The read-only era is ending. Read-write memory MCPs are coming, and the convergence is happening fast.

MemPalace defined the tool surface: read, write, mutate, navigate, diary. Karpathy defined the ingest philosophy: raw sources compiled into structured wikis. Mem0 defined the commercial category with $24M in funding and 48,000 GitHub stars. The architectural ideas are converging. The MCP protocol itself is mature enough to support all of it.

What's still missing is domain-specific implementations that treat their source material as first-class. Meeting transcripts are the obvious gap: they're the largest pool of unstructured organizational knowledge, they change constantly, and every existing MCP for them stops at retrieval. But the same gap exists for support ticket histories, sales call libraries, code review threads, and any corpus where knowledge evolves session to session.

The builder who ships the first meeting MCP with write tools, temporal knowledge graph mutations, and an agent diary will own a category that doesn't exist yet. We're building toward that with Proudfrog. If you're building in this space — for meetings or for any other high-value corpus — the MemPalace tool surface is your starting blueprint, and the patterns we've outlined for meetings are the domain-specific extension.

Get in touch. We've been thinking about this for a while.

Frequently Asked Questions

What's the difference between MemPalace's read-write MCP and existing meeting tool MCPs?

MemPalace ships tools that mutate state — agents can add knowledge, update the knowledge graph, and write diary entries. Every meeting MCP in production today (Otter, Fireflies, Granola, Read.ai, Circleback) is read-only: agents can query past meetings but cannot persist what they learn. The read-write pattern means knowledge accumulates across sessions. The read-only pattern means every session starts from scratch. For a deeper analysis of the read-only meeting MCP landscape, read our piece on meetings as first-class sources.

Is MemPalace production-ready?

For personal use and small teams, it works today. pip install mempalace, connect to Claude, start filing memories. The local-first architecture (ChromaDB + SQLite) means no infrastructure to manage. For enterprise use, the answer is more cautious: contradiction detection isn't wired in despite what the README implies, AAAK compression regresses retrieval by 12.4 percentage points, and the project is three days old. The 96.6% raw retrieval score on LongMemEval is independently verified and real. The 100% hybrid score is benchmark-specific optimization. Use the raw mode, skip AAAK, and treat the knowledge graph as append-mostly until contradiction detection ships.

Why is the read-write distinction so important for memory MCPs?

Because read-only MCP is search, not memory. An agent that can only query past data re-derives the same answers from the same raw material on every session. An agent that can write — persist decisions, update knowledge graphs, leave diary notes — builds a compounding knowledge base. The difference shows up most clearly over time: after 50 meetings, a read-only MCP still answers questions by scanning all 50 transcripts. A read-write MCP has already extracted, structured, and cross-linked the knowledge from those meetings into a queryable graph.

How does the Proudfrog MCP server compare?

Proudfrog ships 5 read tools today — meeting listing, transcript retrieval, search, meeting notes, and action item queries. MemPalace ships 19 tools including writes and KG mutation. But MemPalace has zero meeting support — no transcript formats, no speaker identification, no agenda awareness. Proudfrog is meeting-native with speaker diarization, entity extraction, and structured note generation baked into the transcription pipeline. v1.1 will add semantic search and the first write tools. The goal is to reach the full read-write tool surface described in this article, purpose-built for meeting knowledge.

Can I use MemPalace's pattern with my own corpus?

Yes — that's the real takeaway. The tool categories (read, write, KG mutation, navigation, diary) transfer to any domain. If you're building an MCP for support tickets, replace "wings" with ticket categories, replace "rooms" with customer accounts, replace "drawers" with ticket contents. Keep the dedup pre-flight check, the temporal validity windows on your knowledge graph, and the agent diary separation. The patterns are general. The implementation is domain-specific.

What does "knowledge graph mutation" mean in practice?

It means your MCP tools can change the relationships between entities, not just query them. In MemPalace, kg_add creates a new fact ("Kai works_on Orion"), kg_invalidate marks a fact as ended ("Kai no longer works_on Orion as of March 15"), and kg_query filters by temporal validity to return only facts that were true at a given point in time. For meetings, this maps to tracking decisions that get revised, commitments that get reassigned, and project scopes that shift between sessions. Without mutation tools, your knowledge graph is a snapshot. With them, it's a timeline.