Shared persistent memory across Claude Chat, Code, and Cowork.
┌───────────┐ ┌───────────┐ ┌───────────┐
│ Chat │ │ Code │ │ Cowork │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
└────────┬────────┴────────┬─────────┘
│ │
┌─────▼─────────────────▼─────┐
│ Acheron MCP │
│ ┌───────────────────────┐ │
│ │ ~/.acheron/bridge.db │ │
│ └───────────────────────┘ │
└─────────────────────────────┘
Local · No cloudSave a decision in Chat. Retrieve it in Cowork. Search for it from Code. All local, all offline, zero configuration.
This connects Acheron to all surfaces — Chat, Code, Cowork, and Dispatch. This is the recommended setup for full cross-surface bridging.
Open Claude Desktop → Settings → Developer → Edit Config, then add:
{
"mcpServers": {
"acheron": {
"command": "npx",
"args": ["-y", "acheron-mcp-server"]
}
}
}Restart Claude Desktop.
If you only need Acheron in Claude Code (terminal / IDE):
claude mcp add acheron -- npx -y acheron-mcp-serverRequires Node.js 20+. Native build tools may be needed for better-sqlite3 (details).
Related MCP server: ClaudeX
Just talk naturally. Acheron's tool descriptions are written so Claude uses them automatically.
Save context — say "remember this", "save this decision", "note that we chose X":
"Remember: we're using Next.js App Router for the acme-site project."
Search context — say "what did I decide about...", "find my notes on...":
"What did we decide about the authentication approach?"
Browse context — say "show me my preferences", "list all decisions for this project":
"Show me everything saved for acme-site."
Acheron is an MCP server. It stores context in a local SQLite database (~/.acheron/bridge.db) with full-text search. No cloud, no network calls, no telemetry. Data never leaves your machine.
Six tools, all prefixed bridge_:
Tool | Purpose |
| Remember decisions, preferences, insights, notes |
| Retrieve full details of a saved context |
| Full-text search across all saved contexts |
| Browse and filter by project, surface, type, tags |
| Forget a saved context |
| Overview of what's stored |
better-sqlite3 install fails? You need native build tools:
macOS: xcode-select --install
Linux: sudo apt install build-essential
Windows: Visual Studio Build Tools
Database issues? Delete ~/.acheron/bridge.db — Acheron recreates it on next start.
MIT
Permanently delete a saved context. Use when the user says "forget this", "delete that", "remove that note", "I don't need that anymore", or "that's outdated, remove it". Requires the context ID — use search or list first to find it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The UUID of the context to delete. Find it first using search or list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds 'permanently delete' and need for context ID, but annotations already signal destructiveHint=true. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers purpose, usage, and parameter acquisition for a delete action with 1 param and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds guidance on how to obtain the ID via search or list, beyond the UUID format in schema. 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'delete' and resource 'saved context'. Distinguishes from siblings like get, list, save, search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use examples ('forget this', 'delete that'), prerequisite to find ID first via search or list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full details of a previously saved context by its ID. Use this after finding a context via search or list, when the user wants to see the complete content of a specific saved memory. Typically used as a follow-up: "show me that decision", "give me the full details on that one".
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The UUID of the context to retrieve. Get this from search or list results. | |
| response_format | No | Response format: json or markdown | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover key behavioral traits. The description adds context that it retrieves 'full details' but does not contradict annotations. It provides minimal additional transparency beyond what annotations convey, so a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences. The first sentence immediately states the action, the second provides usage context, and the third gives concrete examples. No unnecessary words or redundancy. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (retrieve by ID with two params) and has rich annotations. The description explains when to use it and gives examples, but could be more complete by describing the return structure (e.g., fields of the context). However, given no output schema, the description is adequate for a straightforward get tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already explains both parameters (id and response_format). The description adds a bit of context for 'id' (get from search/list) and mentions response_format implicitly via 'full details', but does not add significant meaning beyond the schema. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and the resource 'full details of a previously saved context by its ID'. It distinguishes from sibling tools like bridge_search_context by specifying it is used after finding a context via search or list, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when to use the tool: after finding a context via search or list, with example user requests like 'show me that decision'. It implies the prerequisite of having an ID, but does not explicitly state when not to use it. This is clear and useful but could be more thorough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse and filter all saved contexts. Use when the user asks "what have I saved?", "show me my decisions", "what do I have for this project?", "list my preferences", "what did we do recently?", "show everything tagged with...", or "what happened in Cowork?". Unlike search (keyword-based), this tool browses by category — filter by project, surface, type, tags, or date. Returns newest entries first.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Show contexts with ALL of these tags. Use when user asks "show everything tagged with auth" or "find frontend + react entries". | |
| type | No | Show only a specific type. "decision" for "show my decisions", "preference" for "what are my preferences", "workflow" for "what processes do we have", etc. | |
| limit | No | Maximum number of results to return (1-50, default 20) | |
| since | No | Only show contexts saved after this date (ISO 8601). Use when user asks "what did I save this week?" or "anything new since Monday?". | |
| offset | No | Number of results to skip for pagination | |
| project | No | Show only contexts for this project. Use when user asks "what do we have for [project]?" or "show me everything on [project]". | |
| source_surface | No | Show only contexts from a specific surface. Use when user asks "what did I save in Chat?" or "what happened in Cowork?". | |
| response_format | No | Response format: json or markdown | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns newest entries first, which is useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is packed with information in two sentences and a phrase. It is front-loaded with purpose and usage, but could be slightly streamlined by removing the list of example queries from the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage guidance, and parameter semantics well. With 8 optional parameters and no output schema, it could mention pagination behavior or response format more explicitly, but the schema descriptions for limit/offset and response_format already exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have descriptions in the schema (100% coverage). The description adds specific usage examples for each parameter, such as 'use when user asks "show me my decisions"' for type, significantly enriching the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Browse and filter all saved contexts' and lists specific user queries that trigger this tool. It clearly distinguishes from sibling tool 'search' by stating it browses by category rather than keyword search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool with example queries like 'what have I saved?' and contrasts with search: 'Unlike search (keyword-based), this tool browses by category'. This provides clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remember something for later. Use this when the user says things like "remember this", "save this", "note this", "keep this for later", "don't forget", or when an important decision, preference, or insight comes up that should persist across conversations. This saves context that will be available in ALL Claude surfaces (Chat, Code, Cowork) — even in future sessions. Use proactively when you recognize something worth remembering: a decision made, a user preference expressed, a lesson learned, a key file identified, or a workflow established.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Short labels for categorization. Examples: ['frontend', 'react'], ['deploy', 'ci-cd'], ['auth']. Helps with filtering later. | |
| type | Yes | Classify the context: "decision" when the user chose between options (e.g. "let's use PostgreSQL", "we'll go with REST not GraphQL"). "preference" when the user expresses how they like things done (e.g. "I prefer tabs", "use French for conversation", "keep responses short"). "insight" when a fact or lesson is discovered (e.g. "the API rate-limits at 100 req/s", "that bug was caused by timezone handling"). "file_ref" when a key file is identified (e.g. "src/auth.ts handles all JWT logic"). "workflow" for processes (e.g. "deploy flow: merge → CI → staging → prod"). "note" for anything else worth remembering. | |
| content | Yes | What to remember. Write it clearly so it will be useful when retrieved later by any Claude surface. | |
| project | No | Project name if this context is project-specific. Use the same name consistently (e.g. "acme-site", "payments-api"). Omit for personal preferences or general notes. | |
| source_surface | Yes | Where this conversation is happening. "chat" for Claude.ai chat, "code" for Claude Code (terminal/IDE), "cowork" for Claude Cowork sessions. | |
| response_format | No | Response format: json or markdown | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with a write operation. Description adds that saved context persists across all surfaces and sessions, which is key behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then usage triggers and examples. Every sentence adds value, though slightly verbose; could be streamlined slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and no output schema, the description adequately explains usage, types of content, and cross-surface persistence. Lacks return value details but output schema is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description enriches the 'type' enum with detailed examples and context, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remember something for later' with specific triggers and examples of what to save, clearly distinguishing from siblings like bridge_delete_context or bridge_get_context which handle retrieval/deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance (user phrases like 'remember this', proactive saving) and what types of info to save, but doesn't explicitly exclude scenarios or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search through everything that has been saved across conversations. Use when the user asks "what did I decide about...", "what do we know about...", "did I save anything about...", "find my notes on...", "what was that thing about...", or any question that might be answered by previously saved context. Also use proactively when the user asks a question that saved context might answer — check before saying "I don't have that information". Searches across all surfaces (Chat, Code, Cowork) and all projects.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Narrow search to a specific type. Use "decision" when user asks "what did I/we decide about...", "preference" for "what are my preferences for...", etc. | |
| limit | No | Maximum number of results to return (1-50, default 10) | |
| query | Yes | Keywords to search for. Use natural terms like 'authentication' or 'deploy process'. Supports quoted phrases like '"react hooks"' and operators AND/OR/NOT. | |
| offset | No | Number of results to skip for pagination | |
| project | No | Narrow search to a specific project. Omit to search across all projects. | |
| source_surface | No | Narrow search to contexts saved from a specific surface. Omit to search all surfaces. | |
| response_format | No | Response format: json or markdown | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint=false. Description adds context that searches across all surfaces and projects, and encourages proactive use. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, efficient paragraph front-loads purpose, then provides usage examples and scope. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of return value format (no output schema), but given the rich schema and annotations, the description adequately covers when and how to use the tool. Could add what results contain, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter descriptions. The tool description adds usage context but does not significantly enhance parameter meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches saved context across conversations, provides specific example queries from users ('what did I decide about...'), and distinguishes from siblings by focusing on search rather than CRUD operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit guidance on when to use: when user asks certain types of questions, and proactively when saved context might answer. Suggests checking before claiming ignorance. Effectively differentiates from other tools like save/delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show a summary of all saved knowledge: how many contexts are stored, broken down by surface (Chat/Code/Cowork) and type (decisions, preferences, insights, etc.), database size, and date range. Use when the user asks "how much have I saved?", "give me an overview", "what's in my memory?", or "how big is my context database?".
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Response format: json or markdown | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; description adds that it returns counts, breakdowns, size, and date range. Does not completely detail output format but is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first describes output, second gives usage examples. Efficient and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one optional parameter; description fully explains functionality, output components, and use cases. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter that has enum and description; description does not add additional meaning beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states that it shows a summary of all saved knowledge with breakdowns by surface and type, database size, and date range. Distinguishes from sibling tools which focus on individual context operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists example user queries that trigger this tool, such as 'how much have I saved?' or 'give me an overview', and implies that more specific queries should use siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0bridge_delete_contextbridge_get_contextbridge_list_contextsbridge_save_contextbridge_search_contextbridge_statusEach tool targets a distinct action (save, get, list, search, delete, status) on contexts with no overlap. The descriptions clearly differentiate when to use each.
All tool names follow a consistent pattern: bridge_verb_context (e.g., bridge_save_context, bridge_list_contexts). The verbs are clear and uniform.
Six tools cover the essential operations for a context management system (CRUD plus search and overview) without being excessive or sparse.
The tool set provides create, read, list/ browse, search, delete, and status. An update operation is missing, but contexts may be intended as immutable entries, making the set largely complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/timmx7/acheron-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
