XMemo

Build XMemo context

recall_context

Read-onlyIdempotent

Build a read-only, bounded context pack from multiple relevant memories. Use it when an answer needs several memory items within max_items and max_tokens; use recall for a quick forgiving lookup or search_memory for strict targeted matching.

Input Schema

TableJSON Schema

Name	Required	Description
`query`	Yes	Natural-language query used to rank memories for the context pack.
`since`	No	RFC 3339 timestamp with timezone offset (e.g., '2026-09-01T00:00:00+09:00'). Trigger: Call this whenever the user query mentions any relative or absolute time constraint (今天/今日/昨天/昨日/前天/上周/8月1日/8月10日到9月1日/最近...). Model responsibility: You (the calling LLM) know current date and user local time, so you must convert natural language time expressions into absolute timestamps. Consequence: If omitted, the server falls back to heuristic guessing which may misinterpret timezone day boundaries or relative dates.
`until`	No	RFC 3339 timestamp with timezone offset (e.g., '2026-09-02T00:00:00+09:00'). When used with since, defines the half-open interval [since, until) with until > since (maximum 90 days span). Trigger: Pass when the user query specifies an end date or bounded window (e.g., 昨天 end of day, 截至8月10日, 8月10日到9月1日). Model responsibility: Convert natural language end bounds into absolute timestamps with timezone offsets. Consequence: If omitted, the window is open-ended on the upper side or derived heuristically.
`max_items`	No	Maximum memories rendered in the context pack.
`max_tokens`	No	Approximate token budget for the rendered context pack.
`query_mode`	No	Optional query intent: 'topic' (default) or 'activity_log'. Trigger: Set 'activity_log' for event feeds within a bounded [since, until) window; set 'topic' for topic retrieval. Model responsibility: 'activity_log' requires explicit bounded 'since' and 'until' timestamps. Consequence: 'activity_log' without bounds fails closed; explicit 'topic' blocks stream bypass.
`time_order`	No	Sort order for returned memories: 'desc' (newest first) or 'asc' (oldest first). Trigger: Pass 'desc' when the user asks for 'latest', 'recent', '从新到旧', or timeline recency, or 'asc' for chronological order. Model responsibility: Explicitly set desired temporal ordering when the user expresses recency intent. If omitted and since/until are omitted, default relevance ranking is used without temporal sorting.
`hypothetical_answer`	No	Optional multilingual hypothetical answer or dense semantic expansion written by the calling LLM for this query.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed5 schema fields changedSep 5, 2026

addedInput schema / properties / hypothetical_answer

Added value: +{
+  "default": "",
+  "description": "Optional multilingual hypothetical answer or dense semantic expansion written by the calling LLM for this query.",
+  "type": "string"
+}

addedInput schema / properties / query_mode

Added value: +{
+  "default": "",
+  "description": "Optional query intent: 'topic' (default) or 'activity_log'. Trigger: Set 'activity_log' for event feeds within a bounded [since, until) window; set 'topic' for topic retrieval. Model responsibility: 'activity_log' requires explicit bounded 'since' and 'until' timestamps. Consequence: 'activity_log' without bounds fails closed; explicit 'topic' blocks stream bypass.",
+  "type": "string"
+}

addedInput schema / properties / since

Added value: +{
+  "default": "",
+  "description": "RFC 3339 timestamp with timezone offset (e.g., '2026-09-01T00:00:00+09:00'). Trigger: Call this whenever the user query mentions any relative or absolute time constraint (今天/今日/昨天/昨日/前天/上周/8月1日/8月10日到9月1日/最近...). Model responsibility: You (the calling LLM) know current date and user local time, so you must convert natural language time expressions into absolute timestamps. Consequence: If omitted, the server falls back to heuristic guessing which may misinterpret timezone day boundaries or relative dates.",
+  "type": "string"
+}

addedInput schema / properties / time_order

Added value: +{
+  "default": "",
+  "description": "Sort order for returned memories: 'desc' (newest first) or 'asc' (oldest first). Trigger: Pass 'desc' when the user asks for 'latest', 'recent', '从新到旧', or timeline recency, or 'asc' for chronological order. Model responsibility: Explicitly set desired temporal ordering when the user expresses recency intent. If omitted and since/until are omitted, default relevance ranking is used without temporal sorting.",
+  "type": "string"
+}

addedInput schema / properties / until

Added value: +{
+  "default": "",
+  "description": "RFC 3339 timestamp with timezone offset (e.g., '2026-09-02T00:00:00+09:00'). When used with since, defines the half-open interval [since, until) with until > since (maximum 90 days span). Trigger: Pass when the user query specifies an end date or bounded window (e.g., 昨天 end of day, 截至8月10日, 8月10日到9月1日). Model responsibility: Convert natural language end bounds into absolute timestamps with timezone offsets. Consequence: If omitted, the window is open-ended on the upper side or derived heuristically.",
+  "type": "string"
+}

Changed1 schema field changedSep 5, 2026
- changedInput schema / properties / max_tokens / default
```
Previous value: -1500New value: +8000
```
Changed1 schema field changedSep 5, 2026
- changedInput schema / properties / max_tokens / default
```
Previous value: -8000New value: +1500
```
Changed1 schema field changedSep 1, 2026
- changedInput schema / properties / max_tokens / default
```
Previous value: -1500New value: +8000
```

Changed20 schema fields changedJul 31, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

removedInput schema / properties / agent_id

Removed value: -{
-  "default": "",
-  "description": "Optional client-supplied agent label for memory attribution.",
-  "title": "Agent Id",
-  "type": "string"
-}

removedInput schema / properties / agent_instance_id

Removed value: -{
-  "default": "",
-  "description": "Optional stable, non-secret agent instance ID for per-client attribution.",
-  "title": "Agent Instance Id",
-  "type": "string"
-}

removedInput schema / properties / bucket

Removed value: -{
-  "default": "%",
-  "description": "Memory bucket or namespace to read from or write to; use % only for tools that support wildcard reads.",
-  "title": "Bucket",
-  "type": "string"
-}

removedInput schema / properties / limit

Removed value: -{
-  "default": 0,
-  "description": "Maximum number of results to return.",
-  "title": "Limit",
-  "type": "integer"
-}

changedInput schema / properties / max_items / description

Previous value: -"Maximum number of memory items to include."New value: +"Maximum memories rendered in the context pack."

removedInput schema / properties / max_items / title
```
Removed value: -"Max Items"
```

changedInput schema / properties / max_tokens / description

Previous value: -"Approximate maximum response size."New value: +"Approximate token budget for the rendered context pack."

removedInput schema / properties / max_tokens / title
```
Removed value: -"Max Tokens"
```

removedInput schema / properties / memory_type

Removed value: -{
-  "default": "auto",
-  "description": "Memory type/category filter or value, such as episodic, identity, procedural, semantic, working, auto, or %.",
-  "title": "Memory Type",
-  "type": "string"
-}

removedInput schema / properties / output_json

Removed value: -{
-  "default": false,
-  "description": "Return a machine-readable JSON response instead of a human-readable summary.",
-  "title": "Output Json",
-  "type": "boolean"
-}

removedInput schema / properties / path_filter

Removed value: -{
-  "default": "%",
-  "description": "Memory path filter; % matches all paths.",
-  "title": "Path Filter",
-  "type": "string"
-}

removedInput schema / properties / prefer_working

Removed value: -{
-  "default": true,
-  "description": "Whether to prioritize working/session-state memories in retrieval.",
-  "title": "Prefer Working",
-  "type": "boolean"
-}

changedInput schema / properties / query / description

Previous value: -"Natural-language question or search text."New value: +"Natural-language query used to rank memories for the context pack."

removedInput schema / properties / query / title
```
Removed value: -"Query"
```

removedInput schema / properties / scope

Removed value: -{
-  "default": "",
-  "description": "Optional scope that narrows memory access; leave blank for the token default.",
-  "title": "Scope",
-  "type": "string"
-}

removedInput schema / properties / team_id

Removed value: -{
-  "default": "",
-  "description": "Optional team/workspace identifier for team-scoped memory access.",
-  "title": "Team Id",
-  "type": "string"
-}

removedInput schema / title

Removed value: -"recall_contextArguments"

removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
removedOutput schema / title
```
Removed value: -"recall_contextOutput"
```

First observedJun 9, 2026

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces safety with 'read-only'. It adds the useful behavioral trait that the pack is bounded by max_items and max_tokens. The parameter descriptions further disclose consequence-style behavior (e.g., heuristic fallback when since is omitted, fail-closed for activity_log without bounds), though those live in the schema rather than the top-level description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The core purpose is front-loaded, and the alternative routing follows immediately. Every clause earns its place, and the description avoids restating the title or schema contents.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter tool with a rich schema, output schema, and strong annotations, the description is sufficient: it states the resource, scope, bounds, and sibling alternatives. The schema covers the remaining parameter mechanics, and the output schema removes the need to describe return values. Nothing an agent needs to decide when to call this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The top-level description adds a small layer of meaning by explaining that the tool is appropriate when memory items fit 'within max_items and max_tokens', connecting those parameters to the tool's bounded-pack purpose. It doesn't repeat schema details, but provides selection-level context for the key bounds.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Build') with a clear resource ('read-only, bounded context pack from multiple relevant memories'). It distinguishes itself from siblings by explicitly naming recall and search_memory, so an agent knows this is the multi-memory bounded-pack tool, not the quick-lookup or strict-match tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit when-to-use: 'when an answer needs several memory items within max_items and max_tokens'. It also names the two alternatives and their distinguishing conditions: 'use recall for a quick forgiving lookup or search_memory for strict targeted matching'. This is exactly the routing guidance needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All XMemo tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation3/5

Multiple memory-retrieval tools (recall, search_memory, recall_context, read_memory, memory_overview) have overlapping purposes; detailed descriptions help but an agent could easily pick the wrong one. Similarly, ledger/open_ledger and todo/open_todo_board split text vs UI interaction, and forget overlaps with todo delete_all and ledger deletion.

Naming Consistency3/5

Most tools follow a verb_noun snake_case pattern (read_memory, update_memory, search_memory, open_ledger). However, several tools use bare nouns or verbs (forget, ledger, project, todo, recall, remember) and memory_overview is noun_noun, creating inconsistent conventions.

Tool Count3/5

19 tools is on the heavy side for the apparent scope, and the surface includes several pairs that duplicate the same domain in text vs UI form (ledger/open_ledger, todo/open_todo_board). Still, the count is defensible given the combined memory, project, TODO, and ledger coverage.

Completeness4/5

Memory has full lifecycle coverage (remember, read, search/recall, update, forget, restore), and TODO and Ledger workflows are largely complete. Minor gaps exist—no explicit project deletion and no pure text list-projects tool—but core workflows do not dead-end.

Build XMemo context

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources