XMemo
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| XMEMO_KEY | Yes | Your XMemo API token. Required for authentication. | |
| XMEMO_URL | No | The base URL of the XMemo service. Defaults to https://xmemo.dev. | https://xmemo.dev |
| MEMORY_OS_URL | No | Compatibility alias for XMEMO_URL. |
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 | {} |
| prompts | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_mcp_identityA | Checks XMemo connection status and the currently connected account/agent when the user asks whether XMemo is connected. |
| rememberA | Save durable information for future recall; skip transient chat. Existing Projects paths attach automatically. The create_project compatibility input may create a missing project only when explicitly enabled. Use add_expense for financial records and create_memory_todo for actionable work. |
| update_stateA | Create or replace one scoped working-state record for resuming a task, next action, or blocker. Requires memory:write; it versions that state slot and refreshes its expiry without deleting other memories. Use remember for durable facts or record_event for history. Provide content or a structured state field; ttl_seconds=0 means no expiry. |
| memory_relationshipsA | Read explicit personal links for one visible Memory; no automated analysis. |
| link_memoriesB | Create a Free explicit link between two visible personal Memories in the same owning store/space. |
| update_memory_relationshipA | Edit an explicit personal link kind using the last read version; stale edits conflict. |
| remove_memory_relationshipB | Remove only an explicit personal association, preserving both Memories and a retry receipt. |
| search_knowledgeA | Search authorized personal Knowledge Base content over published current revisions, or read one exact item/revision with bounded pagination. Requires knowledge:read. |
| recall_contextA | Build a read-only, bounded context pack from multiple relevant memories. Use it when an answer needs several memory items or scoped/path-filtered context; use recall for a quick best-effort lookup or get_project_context for a whole-project snapshot. max_items/max_tokens bound output: memories that do not fit are omitted and reported, so raise max_tokens or use recall when you need the records themselves. |
| get_project_contextA | Read one authorized project's bounded context pack: state, TODOs, decisions, timeline, recent memories, and optional durable recall. Requires memory:read; it does not mutate project memories, and access is audit-logged. Use an exact project_id for a whole-project snapshot; otherwise use recall_context. max_items/max_tokens bound the whole pack; recent_hours affects only timeline; durable_query requires include_durable_context. |
| query_auditA | Query audit records within the caller's authorized memory scope. source='events' selects action/time/target events; source='consolidation' selects consolidation/lifecycle/reflection history. This does not grant cross-user or system administration access. |
| record_eventA | Record a significant session event, milestone, decision, or handoff note useful for reconstructing recent work. Not for durable facts/preferences (use remember). |
| get_timelineA | Read authorized timeline events newest first. Requires memory:read and makes no memory changes. Use it for recent history or session resumption; use recall_context for semantic multi-memory context. limit is clamped to 1-500; session_id and event_type are exact filters. |
| create_memory_todoA | Creates a TODO/action item in XMemo with an optional due time when the user asks to save a task, follow-up, action item, or reminder-style item to revisit at a later time. |
| list_memory_todosA | Lists open or completed TODO/action items as a concise text answer when the user asks how many tasks, follow-ups, or saved action items are currently pending or completed; do not use it to open, browse, filter, or manage the visual TODO workspace. |
| complete_memory_todoA | Marks a TODO/action item completed when the user says a saved task is done, resolved, or no longer needed; its exact memory reference is shown by list_memory_todos. |
| update_project_todoA | Transition a project TODO's status. action must be one of: accept, assign, block, unblock, complete, cancel. assignee_agent_id is required for action='assign'; reason is required for action='block' (optional for cancel); note is optional for action='complete'. |
| update_project_decisionA | Transition a project decision. action must be one of: resolve, supersede, reopen. resolution is required for action='resolve'. new_context (and optionally options_json/impact_level/resolution_note) is required for action='supersede'. |
| create_restart_snapshotA | Save active state, recent events, TODOs, and pending decisions for restart. Relevant before handoff or when context may be lost. |
| restore_restart_snapshotB | Resume previous work from a saved snapshot. Relevant when the user asks to resume/restart or after context loss. |
| recallA | Recall a few relevance-ranked memories before answering, with path/type controls and optional working-memory preference. Unscoped by default: it searches all of your buckets; pass bucket to search only that bucket (never widened by fallback). Use it for a quick best-effort lookup; use recall_context when the answer needs a bounded multi-memory context pack. |
| update_memoryA | Updates the content, location, or type of a specific saved memory when the user asks to correct, revise, move, or reclassify it. An exact reference identifies the record. |
| forgetA | Delete one memory, TODO, or Ledger transaction by current/latest, an exact memory reference, an exact TODO ID from list_memory_todos, or an exact transaction ID from list_ledger_transactions. The default is a recoverable soft delete that restore_memory can undo; mode='hard' is permanent and unrecoverable; requires explicit user confirmation of permanent deletion. Ambiguous targets are resolved before deleting. |
| memory_statsA | Shows aggregate statistics for all saved XMemo memories — counts by type, source, location, and optional time range when the user asks for counts, breakdowns, or distributions. |
| restore_memoryA | Restore a previously deleted memory. Intended only for when the user explicitly asks to restore or undo a deletion. |
| explain_memoryA | Explains why a memory exists or matched a query whenever the user asks why something was saved there or why it was retrieved. |
| read_memoryA | Read one exact authorized XMemo memory or Document in character windows. Use a bare memory ID (e.g. returned by recall or search) for the initial read (offset 0). The response includes 'revision' (e.g. '<memory_id>@v') and 'version'. To continue reading long content across multiple pages (when 'has_more' is True), callers MUST pass the returned 'revision' as memory_id along with 'next_offset'. This pins continuation pages to that exact snapshot and prevents torn reads if concurrent updates occur between requests. Querying with a bare memory ID always resolves to the latest active version (head), which is unpinned and subject to version tearing across updates. A Document item's reference ('document:') reads the whole Document the same way. For a Document, 'anchor' (a heading path) with 'ordinal' (1 = its first chunk) starts the page at that section; continue with 'next_offset' and no anchor. 'version' pins like a revision; a Document that changed since returns version_changed=true and no content, so restart at offset 0. Embeddings are never returned. |
| list_memory_versionsA | Show version history for a memory. Relevant when the user asks for previous content or changes over time. |
| list_memory_conflictsA | List conflicting/inconsistent memories. Relevant when the user/admin asks to review unresolved conflicts. |
| resolve_memory_conflictA | Resolve a listed memory conflict. Intended only for when the user/admin explicitly chooses a resolution strategy. |
| propose_writeA | Propose a write operation (memory, todo, profile etc.) when direct modifications are denied due to tier-gating. |
| propose_todo_mutationA | Propose a todo mutation under the proposals bucket at path 'todos/{action}'. |
| propose_profile_mutationB | Propose a profile mutation under the proposals bucket at path 'profile.{field}'. |
| save_cloud_skillA | Save a reusable procedure, rule, or SOP as a Cloud Skill in XMemo for future recall across connected AI agents. Supports two usage modes (API Evolution Note: additive parameter 'url'):
|
| recall_cloud_skillA | Recall reusable Cloud Skills, instructions, or sub-resources saved in XMemo. Supports Level 0 discovery by query, Level 1 root recall, and Level 2 resource recall with pinned revision_id. |
| dream_viewC | Inspect the Dream Workspace (Ideas, Goals, Principles, Feed) for the calling identity. Read-only projection; strictly isolated by owner identity and scope. Honors R1 fail-closed hiding, egress fence, and call-time gates. |
| dream_actionA | Execute an explicit Dream Workspace user action (Idea accept, Feed save, Mute, Confirm Principle). Dispatched to approved domain service paths with immutable receipts, call-time gates, and D6 protection checks. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| remember | Save a memory to XMemo for future recall across sessions. |
| recall | Recall relevant memories from XMemo before answering a question. |
| project-context | Build a context pack from XMemo for the current project or task. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| XMemo MCP quick start | Installation, authentication, and connection guidance for XMemo MCP. |
| XMemo security and privacy | Credential handling, privacy boundaries, and destructive-action guidance. |
TDQS
Scored across 37 tools
The tool set has several clusters of overlapping retrieval/write tools, such as recall vs. recall_context vs. search_knowledge vs. read_memory, and remember vs. update_state vs. record_event. The descriptions do a good job clarifying intended boundaries, but an agent still faces multiple plausible choices for common memory tasks.
Most names use snake_case, but conventions are mixed: many are verb_noun, while others are noun-first (memory_stats, memory_relationships, dream_view) or bare verbs (remember, forget, recall). The pattern is readable but not consistently predictable.
With 37 tools, the surface is heavy for a memory assistant and includes many specialized operations across projects, dreams, cloud skills, snapshots, proposals, and audit. While the domain is broad, this is well above the typical well-scoped range and increases selection burden.
The surface is very complete for memory lifecycle management: create, recall, read, update, delete, restore, version, relate, conflict, TODO, project, snapshot, and audit operations are all represented. Minor gaps remain around full lifecycle coverage for some subdomains, such as updating/deleting Cloud Skills and explicitly listing or creating projects.