Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
XMEMO_KEYYesYour XMemo API token. Required for authentication.
XMEMO_URLNoThe base URL of the XMemo service. Defaults to https://xmemo.dev.https://xmemo.dev
MEMORY_OS_URLNoCompatibility 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

CapabilityDetails
tools
{}
prompts
{}
resources
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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'):

  1. Direct creation: Provide non-empty 'name' and 'instructions'.

  2. Remote import: Provide 'url' (ClawHub slug/URL, GitHub repo/tree/raw URL, or direct HTTPS zip/markdown).

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

NameDescription
rememberSave a memory to XMemo for future recall across sessions.
recallRecall relevant memories from XMemo before answering a question.
project-contextBuild a context pack from XMemo for the current project or task.

Resources

Contextual data attached and managed by the client

NameDescription
XMemo MCP quick startInstallation, authentication, and connection guidance for XMemo MCP.
XMemo security and privacyCredential handling, privacy boundaries, and destructive-action guidance.

TDQS

B3.4/5.0

Scored across 37 tools

Disambiguation3/5

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.

Naming Consistency3/5

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.

Tool Count2/5

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.

Completeness4/5

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.

Maintenance

ActivityActive
ResponsivenessWithin a week