warp-memory-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WARP_SQLITE | No | Override the database path if needed. The Warp database is otherwise located in the Group Container. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| statusA | Describe what Warp / Oz data is readable locally versus cloud-only. Use this first when coordinating with Warp's AI. |
| searchA | Search Warp memories, notebooks/plans, conversation summaries, and recent user prompts to Oz. Best first tool for 'what did Oz work on' / 'find the Warp plan'. |
| list_memoriesA | List Warp saved memories (local AIFACT 'remember this' items). |
| get_memoryA | Get one Warp saved memory by numeric id or name. |
| list_notebooksC | List Warp Drive notebooks / agent plans (full plans live here). |
| get_notebookB | Get a Warp notebook / plan by id, title, or document uid. |
| list_conversationsB | List recent Warp agent conversations (title, first prompt, linked plans). Transcripts are not stored locally. |
| get_conversationB | Get one Warp conversation: summary, linked plan notebooks, and the user prompts from that session. |
| list_queriesC | List recent user prompts sent to Warp / Oz. |
| list_project_rulesA | List Warp project rule files (AGENTS.md / WARP.md paths). |
| write_handoffC | Write a coordination note between Grok and Oz. Stored under ~/.warp/agent-coordination/handoffs (not in warp.sqlite). |
| list_handoffsC | List Grok ↔ Oz coordination handoffs. |
| get_handoffA | Read one handoff note by id. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Each tool targets a distinct resource/action: status and search serve as meta/cross-cutting entry points, list_/get_ pairs cleanly separate memories, notebooks, conversations, and handoffs, and write_handoff is clearly the only write operation. Any conceptual overlap, such as search versus list_queries, is mitigated by clear descriptions.
Most tools follow a consistent list_<plural> / get_<singular> pattern, with write_handoff fitting the verb_noun convention. The exceptions are the bare commands status and search, which would be more consistent as get_status and search_warp, but the overall pattern remains readable and predictable.
Thirteen tools is well within the ideal scope and each tool has a clear role: four list/get resource pairs, a cross-resource search, a status overview, project rule listing, and a handoff write/list/get set. No tool feels redundant or superfluous.
The server provides strong read coverage for memories, notebooks, conversations, and recent prompts, plus a complete handoff write/list/get workflow. Minor gaps exist, such as project rules being listed only as paths without a content-read tool, but the core coordination and lookup workflows are well covered.