XMemo
Server Details
User-owned memory for AI agents, Copilot, Claude, IDEs, CLIs, and chat apps over remote MCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- yonro/memory-os-cli
- GitHub Stars
- 12
- Server Listing
- XMemo
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 23 of 23 tools scored. Lowest: 2.9/5.
Most tools have distinct purposes, but recall and recall_context are very similar (both retrieve memories), and propose_write overlaps with other propose tools. Overall, descriptions help differentiate.
Majority follow verb_noun convention (e.g., add_expense, list_memory_todos), but a few deviate with single verbs (recall, remember, forget) or missing verb (memory_stats). This creates mild inconsistency.
23 tools is on the high side for a memory/ledger assistant. Some tools could be consolidated (e.g., memory retrieval variants). Still within manageable range, but feels slightly bloated.
Covers core CRUD for memories and ledger, plus todos and proposals. However, ledger lacks update/delete operations, and there is no explicit search for memories. Notable gaps exist.
Available Tools
23 toolsadd_expenseAdd an expense to XMemoAInspect
Record one expense in the XMemo Ledger. Call this whenever the user states a concrete expense, purchase, income, or refund — for example, 'I spent 25 on lunch' or 'log this expense' — not only on an explicit 'record this'. Capture date, amount, currency, item, and merchant/category when present.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | The purchased item or service, for example 2 watermelons or Nintendo Switch 2. | |
| note | No | Optional completion note. | |
| path | No | A simple user-facing category or path for this memory, such as preferences, projects/xmemo, or personal/travel. | finance/ledger/expenses |
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| amount | Yes | Positive transaction amount as a number. | |
| bucket | No | Memory bucket or namespace to read from or write to; use % only for tools that support wildcard reads. | private |
| team_id | No | Optional team/workspace identifier for team-scoped memory access. | |
| agent_id | No | Optional client-supplied agent label for memory attribution. | |
| category | No | Optional spending category, such as food, transport, or electronics. | |
| currency | No | Currency code or label, such as CNY, RMB, JPY, yen, or USD. For ledger search/list tools, leave blank unless the user explicitly requested one currency; labels are normalized to codes. | CNY |
| merchant | No | Optional merchant or store name. | |
| device_id | No | Optional client-supplied device identifier for attribution. | |
| device_label | No | Optional human-readable device label for attribution. | |
| payment_method | No | Optional payment method, such as card, cash, Alipay, or WeChat Pay. | |
| transaction_date | No | Transaction date in YYYY-MM-DD. Leave blank to use today's UTC date. | |
| agent_instance_id | No | Optional stable, non-secret agent instance ID for per-client attribution. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations have readOnlyHint=false and destructiveHint=false, indicating mutation. The description adds 'Record one expense' but does not disclose side effects, authorization needs, error handling, or constraints beyond basic usage. More behavioral context is needed.
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, front-loaded with the core purpose, and uses only a few sentences without unnecessary words. Every sentence adds value.
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?
Given the output schema exists (return values presumably covered), the description adequately addresses the tool's purpose and key parameters. It does not explain error states or edge cases, but for a parameter-rich tool with many optionals, this is sufficient.
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%, so baseline is 3. The description adds value by listing key fields to capture (date, amount, currency, item, merchant/category) but does not explain their meaning beyond the schema's descriptions.
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 tool records one expense in the XMemo Ledger, provides examples, and distinguishes from generic recording by specifying it's for concrete expenses, purchases, incomes, or refunds.
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 says when to call the tool (user states concrete expense/purchase/income/refund) and provides examples. It implies not to call on explicit 'record this' only, but does not mention alternatives or specific exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
complete_memory_todoComplete XMemo memory TODOAInspect
Mark a TODO/action item completed. Call this when the user says a saved task is done, resolved, or no longer needed; use the exact reference from list_memory_todos.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional completion note. | |
| todo_id | Yes | The memory TODO/action-item ID to complete. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive, and non-idempotent behavior. The description adds the 'mark completed' semantic but does not disclose additional behavioral traits such as reversibility or side effects 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 two sentences, directly conveying purpose and usage guidance. Every sentence is meaningful with no extraneous 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?
Given the presence of an output schema and the tool's simplicity (status update), the description adequately covers purpose, usage, and parameter hints. It provides sufficient context for an AI agent to select and invoke the tool correctly.
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%, and both parameters are described in the schema. The description adds minimal value, only noting to use the exact reference from list_memory_todos for todo_id. This meets the baseline for high 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?
The description clearly states the tool marks a TODO/action item as completed, using specific verbs and resource. It distinguishes from siblings by referencing list_memory_todos for the exact reference, aiding differentiation.
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 provides clear context for when to call the tool (user says task is done, resolved, or no longer needed) and advises using the exact reference from list_memory_todos. However, it does not explicitly exclude alternative tools like complete_reminder.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_memory_todoCreate XMemo memory TODOAInspect
Create a TODO/action item in XMemo with an optional due time. Call this when the user asks to save a task, follow-up, action item, or reminder-style item to revisit later.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| bucket | No | Memory bucket or namespace to read from or write to; use % only for tools that support wildcard reads. | work |
| due_at | No | Optional due time for a memory TODO/action item, preferably ISO 8601. | |
| content | Yes | Text body to save, such as a memory, TODO/action item, event note, or state summary. | |
| metadata_json | No | Optional JSON object string with extra metadata for the operation. | {} |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description's mention of 'Create' is consistent. However, it adds no further behavioral details (e.g., overwriting behavior, permission requirements) beyond what annotations provide.
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 two sentences: one stating purpose and one giving usage guidance. No unnecessary words or details.
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?
Given the 5 parameters (1 required), output schema existence, and annotations, the description covers the main purpose and usage. It does not explain return values, but the output schema likely covers that.
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 description coverage is 100%, so the description does not need to add much. It mentions 'optional due time' corresponding to due_at, but does not add new meaning beyond the schema for other parameters.
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 'Create' and the resource 'TODO/action item in XMemo' with an optional due time. This distinguishes it from siblings like 'create_reminder' and 'complete_memory_todo'.
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 says 'Call this when the user asks to save a task, follow-up, action item, or reminder-style item to revisit later.' This provides clear usage context, though it does not mention when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_memoryExplain XMemo memoryARead-onlyIdempotentInspect
Explain why a memory exists or matched a query. Call this when the user asks why something was saved or why it was retrieved.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Natural-language question or search text. | |
| memory_id | Yes | Exact XMemo memory reference shown by search or recall. | |
| output_json | No | Return a machine-readable JSON response instead of a human-readable summary. | |
| include_embedding | No | Whether to include embedding/vector metadata in the returned explanation. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, covering safety and side effects. The description adds the purpose of explaining existence/matching but no additional behavioral traits (e.g., permissions, rate limits). It complements annotations without contradicting them.
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, no extraneous information. Each sentence serves a distinct purpose: stating functionality and providing usage guidance. Highly concise.
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, combined with comprehensive schema descriptions and annotations, covers the essential context for this relatively simple tool. The output schema exists, so return values are documented. Sibling tools are numerous, but the description helps distinguish the tool's purpose. Could be slightly improved by specifying that it requires a memory_id, but that is already in the 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?
Schema coverage is 100% with clear descriptions for each parameter. The tool description does not add extra meaning beyond the schema, so the baseline score of 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 the verb 'explain' and the resource 'memory', specifying two distinct scenarios: existence and retrieval matching. It effectively distinguishes from siblings like 'recall' or 'search_memory' by focusing on explanation rather than retrieval or 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 says 'Call this when the user asks why something was saved or why it was retrieved.' This provides clear when-to-use guidance but does not mention when not to use it nor suggest alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetForget XMemo memoryADestructiveInspect
Permanently delete one memory or Ledger transaction by natural target ('latest', 'current', an exact memory ID, or an exact Ledger transaction ID from list_ledger_transactions). This cannot be undone or restored. Call this only when the user explicitly asks to delete a specific memory or expense/income record; search or check activity first if the target is ambiguous.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Deletion mode for forget_memory, such as soft_delete, hard_delete, or redact when supported. | hard |
| reason | No | Optional user-facing reason for the deletion. | |
| target | No | The memory to forget: current or an exact memory ID shown by search. | current |
| query_hint | No | Input value for the Forget tool. | |
| metadata_json | No | Optional JSON object string with extra metadata for the operation. | {} |
| replacement_content | No | Replacement text to store when redacting or replacing deleted memory content. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds crucial context: the deletion is permanent and cannot be undone or restored. It also clarifies that the tool can delete both memories and Ledger transactions.
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 sentences with no redundancy. Front-loaded with the core action (permanent delete) and scope. Every sentence adds essential 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?
Given the complexity (6 optional parameters, multiple target types), the description covers core behavior well. It could mention the 'mode' parameter briefly, but since the tool has an output schema, return values are excluded per rules.
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 description coverage is 100%, so the schema already documents all 6 parameters. The description adds value by elaborating on the 'target' parameter (listing valid formats), but does not substantially enhance understanding of other parameters 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 uses a specific verb ('Permanently delete') and clearly identifies the resource (one memory or Ledger transaction). It enumerates valid target types ('latest', 'current', exact ID), distinguishing it from sibling tools like 'remember' or 'update_memory'.
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 call ('only when the user explicitly asks to delete...'), when not to call ('search or check activity first if target is ambiguous'), and implies alternative actions (search, check activity).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_mcp_identityCheck XMemo connectionARead-onlyIdempotentInspect
Check XMemo connection status and the connected account/agent. Call this when the user asks whether XMemo is connected.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds minor context about checking connected account/agent, but does not reveal additional behavioral traits beyond what annotations provide.
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, no wasted words. Front-loaded with purpose in 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?
For a simple read-only check with no inputs, the description is adequate. An output schema exists to detail return values, so no need to describe them in text.
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?
No parameters exist, and schema coverage is 100%. Baseline for 0 parameters is 4; description adds no parameter info but not required.
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 'Check' and the resource 'XMemo connection status and the connected account/agent'. It distinguishes itself from sibling tools (which deal with memory, expenses, etc.) by being the only connection check.
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 says 'Call this when the user asks whether XMemo is connected.' No exclusions needed as no alternative tools exist for this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_monthly_ledger_summaryShow XMemo monthly spending summaryARead-onlyIdempotentInspect
Summarize Ledger totals by month and currency. Call this when the user asks for monthly spending, income, refunds, net balance, budget review, or spending trends.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| bucket | No | Memory bucket or namespace to read from or write to; use % only for tools that support wildcard reads. | % |
| months | No | Number of recent ledger months to summarize. | |
| currency | No | Currency code or label, such as CNY, RMB, JPY, yen, or USD. For ledger search/list tools, leave blank unless the user explicitly requested one currency; labels are normalized to codes. | |
| output_json | No | Return a machine-readable JSON response instead of a human-readable summary. | |
| transaction_type | No | Optional ledger type filter: expense, income, refund, or transfer. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, providing a strong safety profile. The description adds that it 'summarizes totals by month and currency,' which is accurate but adds minimal new 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?
Two concise sentences that front-load the core function and then provide clear usage triggers. Every sentence adds value with zero waste.
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?
Given the output schema exists and the tool is a straightforward summary, the description covers the essential behavior and usage triggers. It does not detail the effect of scope/bucket parameters, but those are standard memory tool parameters explained in the schema. A minor omission is the behavior when currency is blank (assumes all currencies), but it's implied.
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 description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond what each parameter's schema description already provides (e.g., months: number of recent months, currency: currency code). No additional parameter guidance is given.
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 uses a specific verb 'Summarize' with clear resources 'Ledger totals by month and currency.' It distinguishes from sibling tools like list_ledger_transactions (which lists individual transactions) by focusing on summary. Examples of queries that trigger it further clarify purpose.
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 states when to call the tool: 'when the user asks for monthly spending, income, refunds, net balance, budget review, or spending trends.' It does not explicitly exclude alternatives or specify when not to use it, but the guidance is clear and direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_project_contextGet Project ContextCRead-onlyIdempotentInspect
Assemble a structured project context pack for the given project.
Args:
project_id: Project identifier (the project scope).
bucket: Bucket filter (default "%" for all buckets).
team_id: Optional team focus.
max_items: Maximum context items.
max_tokens: Maximum rendered tokens.
include_durable_context: Whether to include long-lived durable context.
durable_query: Optional query to focus durable context.
recent_hours: Hours of recent activity to include.
output_json: Return the full JSON pack instead of a text summary.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket | No | Memory bucket or namespace to read from or write to; use % only for tools that support wildcard reads. | % |
| team_id | No | Optional team/workspace identifier for team-scoped memory access. | |
| agent_id | No | Optional client-supplied agent label for memory attribution. | |
| max_items | No | Maximum number of memory items to include. | |
| max_tokens | No | Approximate maximum response size. | |
| project_id | Yes | Input value for the Get Project Context tool. | |
| output_json | No | Return a machine-readable JSON response instead of a human-readable summary. | |
| recent_hours | No | Input value for the Get Project Context tool. | |
| durable_query | No | Input value for the Get Project Context tool. | |
| agent_instance_id | No | Optional stable, non-secret agent instance ID for per-client attribution. | |
| include_durable_context | No | Input value for the Get Project Context tool. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the concept of assembling a context pack but does not disclose additional behavioral traits beyond what annotations provide.
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 a lengthy list of parameter comments without a concise summary. It lacks front-loading of essential information and could be significantly shortened.
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?
Given the high parameter count (11) and the presence of output schema, the description could provide more guidance on how parameters interact or prioritize. It is not complete enough for an agent to confidently use the tool without additional context.
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%. The description adds minimal meaning beyond the schema, like default values and a brief clarification for bucket. However, many schema descriptions are generic, and the description does not fully compensate.
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 tool assembles a structured project context pack, using a specific verb and resource. However, it does not differentiate from sibling tools like 'recall_context' or 'get_timeline' which may have similar purposes.
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?
No guidance is provided on when to use this tool versus its siblings. There are no prerequisites, exclusions, or context signals indicating optimal use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_timelineGet TimelineARead-onlyIdempotentInspect
Show recent events. Call this when the user asks what happened recently or when resuming work that may depend on recent events.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. | |
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| bucket | No | Memory bucket or namespace to read from or write to; use % only for tools that support wildcard reads. | % |
| event_type | No | Timeline event type, such as event, milestone, decision, or handoff. | |
| session_id | No | Optional session identifier associated with the event, timeline query, or snapshot. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's safety profile is well-covered. The description adds no further behavioral traits (e.g., chronological ordering, pagination), but it does not contradict 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?
The description is two sentences: the first states the action, the second gives usage context. Every word earns its place; there is no redundancy or 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?
With an output schema present, the description need not detail return values. However, it does not explain how the optional parameters (scope, bucket, event_type, session_id) affect the results. The schema fills this gap, but the overall description is minimal for a tool with 5 parameters.
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 description coverage is 100% (all 5 parameters have descriptions). The tool description itself adds no meaning beyond what the schema provides, so the baseline score of 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 the tool's purpose as showing recent events and ties it to user requests about what happened recently or resuming work. This specific verb+resource combination distinguishes it from siblings like record_event (write) and memory activity tools.
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 explains when to call the tool: 'when the user asks what happened recently or when resuming work that may depend on recent events.' It does not mention when not to use it or provide alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_ledger_transactionsShow XMemo expensesARead-onlyIdempotentInspect
Show XMemo Ledger records. Call this when the user asks about past expenses, purchases, or spending history, or before answering a finance question that depends on recorded transactions. For item searches use query and leave currency blank unless a currency was requested.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. | |
| query | No | Natural-language question or search text. | |
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| bucket | No | Memory bucket or namespace to read from or write to; use % only for tools that support wildcard reads. | % |
| offset | No | Number of matching records to skip for pagination. | |
| date_to | No | Only include ledger transactions on or before this YYYY-MM-DD date. | |
| category | No | Optional spending category, such as food, transport, or electronics. | |
| currency | No | Currency code or label, such as CNY, RMB, JPY, yen, or USD. For ledger search/list tools, leave blank unless the user explicitly requested one currency; labels are normalized to codes. | |
| date_from | No | Only include ledger transactions on or after this YYYY-MM-DD date. | |
| max_amount | No | Only include ledger transactions with amount less than or equal to this value. | |
| min_amount | No | Only include ledger transactions with amount greater than or equal to this value. | |
| output_json | No | Return a machine-readable JSON response instead of a human-readable summary. | |
| transaction_type | No | Optional ledger type filter: expense, income, refund, or transfer. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no new behavioral traits beyond stating it 'shows' records, which is consistent. 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 sentences, front-loaded with purpose, each sentence adds necessary information. 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?
For a tool with 13 parameters, 100% schema coverage, and output schema present, the description covers usage scenarios and provides parameter guidance. It is complete enough for an agent to use correctly.
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 description coverage is 100%, so baseline is 3. The description adds value by guiding use of query and currency parameters (e.g., leave currency blank unless explicit request), which goes beyond schema descriptions.
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 tool shows XMemo Ledger records and provides specific use cases like past expenses and spending history. It distinguishes from siblings implicitly by mentioning ledger records, but does not explicitly differentiate from tools like 'get_monthly_ledger_summary'.
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 call (past expenses, spending history, before finance questions) and gives parameter guidance (use query for item searches, leave currency blank unless requested). Lacks explicit when-not-to-use or alternatives beyond the hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_memory_todosList XMemo memory TODOsARead-onlyIdempotentInspect
List open or completed TODO/action items. Call this when the user asks what tasks, follow-ups, or saved action items are pending or done.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. | |
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| bucket | No | Memory bucket or namespace to read from or write to; use % only for tools that support wildcard reads. | % |
| due_before | No | Only show memory TODO/action items due before this time. | |
| item_status | No | Optional memory TODO/action-item status filter. | open |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds the 'open or completed' clarification and usage context, but no additional behavioral traits like pagination or default scope beyond what annotations provide.
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 concise sentences with no fluff. The purpose and usage trigger are front-loaded and clear.
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?
Output schema exists, so return values are covered. The description adequately explains what the tool does and when to use it. It does not mention parameter caveats like bucket wildcards, but the schema covers those. Overall sufficient.
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%, so all parameters are documented. The description adds no extra meaning beyond mentioning 'open or completed', which aligns with the item_status parameter. 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 the verb 'List' and the resource 'TODO/action items from XMemo memory'. It distinguishes from sibling tools like create_memory_todo and complete_memory_todo by specifying it lists items.
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 provides explicit guidance: 'Call this when the user asks what tasks, follow-ups, or saved action items are pending or done.' It does not explicitly mention exclusions or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_memory_versionsList Memory VersionsARead-onlyIdempotentInspect
Show version history for a memory. Call this when the user asks for previous content or changes over time.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes | Exact XMemo memory reference shown by search or recall. | |
| output_json | No | Return a machine-readable JSON response instead of a human-readable summary. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the primary behavioral traits are captured. The description adds minimal extra context (e.g., 'changes over time') but does not reveal rate limits, authentication needs, or other nuances beyond what annotations imply.
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 extremely concise—two sentences with no filler. The first sentence delivers the core purpose, and the second adds usage context. Every word contributes meaning.
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?
Given the output schema exists (so return structure is documented elsewhere), and the tool is a simple version-listing operation, the description covers the essential context—purpose and when to use. Some might want more detail on what 'version history' entails, but it is sufficient.
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% and both parameters have clear descriptions in the input schema (e.g., 'Exact XMemo memory reference'). The description does not add any additional semantic value beyond what the schema already provides, warranting a baseline score.
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 action ('Show') and the resource ('version history for a memory'), making the tool's purpose unambiguous. It effectively distinguishes itself from sibling tools like 'list_memory_todos' or 'get_timeline' which serve different purposes.
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 states when to call the tool ('when the user asks for previous content or changes over time'), providing clear usage context. It lacks explicit when-not-to-use guidance but the positive indicator is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_statsShow XMemo memory statisticsARead-onlyIdempotentInspect
Show aggregate statistics for XMemo memories — counts by type, source, location, and optional time range. Call this when the user asks for counts, breakdowns, or distributions.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| since | No | Only include memories or activity on or after this ISO 8601 timestamp. | |
| top_n | No | Maximum number of aggregate groups to return. | |
| until | No | Only include memories or activity on or before this ISO 8601 timestamp. | |
| group_by | No | Optional grouping: none, month, agent, location, memory_type, type, source, path, bucket, day, or comma-separated advanced fields. | |
| memory_type | No | Memory type/category filter or value, such as episodic, identity, procedural, semantic, working, auto, or %. | % |
| output_json | No | Return a machine-readable JSON response instead of a human-readable summary. | |
| path_filter | No | Memory path filter; % matches all paths. | % |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, matching the description's stateless read nature. The description adds useful behavioral context (aggregate stats, optional time range) 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?
Extremely concise: one sentence stating purpose and one sentence for usage guidance. No wasted words; front-loaded with core function.
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?
Given 8 optional parameters, an output schema exists, and the description covers purpose and usage. Could elaborate on grouping behavior, but adequate for an aggregate stats 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?
Schema coverage is 100% with good parameter descriptions. The description adds some context (e.g., 'counts by type, source, location') but does not significantly enhance understanding 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 specifies exactly what the tool does: 'Show aggregate statistics for XMemo memories — counts by type, source, location, and optional time range.' It clearly distinguishes from sibling tools like search_memory or recall by focusing on aggregations.
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 clear when-to-use guidance: 'Call this when the user asks for counts, breakdowns, or distributions.' Lacks explicit when-not-to-use or alternatives, but the context makes it sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
propose_profile_mutationPropose Profile MutationAInspect
Propose a profile mutation under the proposals bucket at path 'profile.{field}'.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | Input value for the Propose Profile Mutation tool. | |
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| value | Yes | Input value for the Propose Profile Mutation tool. | |
| team_id | No | Optional team/workspace identifier for team-scoped memory access. | |
| agent_id | No | Optional client-supplied agent label for memory attribution. | |
| metadata_json | No | Optional JSON object string with extra metadata for the operation. | {} |
| agent_instance_id | No | Optional stable, non-secret agent instance ID for per-client attribution. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal disclosure beyond annotations; 'propose' suggests a non-final action but no details on side effects, approval, or rollback. Annotations show readOnlyHint=false but description adds no clarity on mutation specifics.
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 concise sentence with essential information front-loaded; no wasted words.
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?
Output schema exists, so return values are covered. However, the description lacks behavioral context for a 7-parameter proposal tool; more detail on proposal semantics would improve completeness.
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 100% but descriptions are generic (e.g., 'Input value'). Description adds path context for 'field' but does not compensate for the poor schema descriptions.
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?
Description clearly states the action ('propose'), resource ('profile mutation'), and location ('proposals bucket at path profile.{field}'), distinguishing it from sibling tools like propose_todo_mutation and propose_write.
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?
No explicit when-to-use or when-not-to-use guidance, but the path pattern 'profile.{field}' implies it is for profile field mutations, differentiating from alternatives only by domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
propose_todo_mutationPropose Todo MutationCInspect
Propose a todo mutation under the proposals bucket at path 'todos/{action}'.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| action | Yes | Usage action or audit-event action filter, depending on the tool. | |
| content | Yes | Text body to save, such as a memory, TODO/action item, event note, or state summary. | |
| team_id | No | Optional team/workspace identifier for team-scoped memory access. | |
| agent_id | No | Optional client-supplied agent label for memory attribution. | |
| metadata_json | No | Optional JSON object string with extra metadata for the operation. | {} |
| agent_instance_id | No | Optional stable, non-secret agent instance ID for per-client attribution. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) but not destructive (destructiveHint=false). Description adds 'proposals bucket' hinting at non-finality, but fails to explain side effects, persistence, or required confirmation. More context needed.
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?
One sentence, 12 words, no filler. Concise but could be more structured with front-loaded key information. Still 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?
Despite full schema coverage and annotations, description is too brief for a 7-parameter tool with 2 required. No explanation of proposal lifecycle, return value, or example usage. Incomplete given complexity.
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 description coverage is 100% (baseline 3). Tool description does not add parameter-specific meaning beyond schema. Generic schema descriptions like 'Text body to save' are adequate but not enriched.
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?
Description specifies verb 'propose' and resource 'todo mutation under proposals bucket at path 'todos/{action}''. It indicates the action is a proposal, but lacks differentiation from sibling tools like propose_profile_mutation or propose_write, which reduces clarity.
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?
No guidance on when to use this tool versus alternatives such as create_memory_todo, complete_memory_todo, or propose_write. No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
propose_writePropose WriteAInspect
Propose a write operation (memory, todo, profile etc.) when direct modifications are denied due to tier-gating.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | A simple user-facing category or path for this memory, such as preferences, projects/xmemo, or personal/travel. | |
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| bucket | No | Memory bucket or namespace to read from or write to; use % only for tools that support wildcard reads. | proposals |
| content | Yes | Text body to save, such as a memory, TODO/action item, event note, or state summary. | |
| team_id | No | Optional team/workspace identifier for team-scoped memory access. | |
| agent_id | No | Optional client-supplied agent label for memory attribution. | |
| metadata_json | No | Optional JSON object string with extra metadata for the operation. | {} |
| agent_instance_id | No | Optional stable, non-secret agent instance ID for per-client attribution. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by clarifying that this tool only proposes a write rather than executing it. Annotations indicate readOnlyHint=false (not read-only) but do not capture the proposal nature. The description explains the tier-gating constraint, which is helpful for understanding side effects.
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 a single sentence that is front-loaded with the action and context. Every word is informative and there is no unnecessary detail. It is efficient and clear.
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?
Given the tool complexity (8 parameters, 2 required) and the presence of an output schema, the description is complete enough. It explains the purpose and when to use it. The output schema covers return values, so the description does not need to elaborate further.
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 description coverage is 100%, so the burden on the description is lower. The description does not add additional meaning to parameters beyond what the schema provides. It is a baseline score as the description does not need to compensate for missing schema information.
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 tool proposes a write operation (memory, todo, profile) and specifies the condition 'when direct modifications are denied due to tier-gating'. The verb 'propose' combined with the resource 'write operation' is specific and distinguishes it from sibling tools like remember or update_memory that perform actual writes.
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 states when to use this tool ('when direct modifications are denied due to tier-gating'), providing clear context. It implies that for direct writes, other tools should be used, but does not explicitly list alternatives. The guidance is clear enough for an agent to differentiate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallRecall XMemo memoryARead-onlyIdempotentInspect
Recall the few most relevant saved memories before answering, when prior preferences, known facts, past decisions, or project context may directly affect the response. Use recall_context when many memories are needed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. | |
| query | Yes | Natural-language question or search text. | |
| explain | No | Whether to include retrieval explanation details with search or recall results. | |
| agent_id | No | Optional client-supplied agent label for memory attribution. | |
| memory_type | No | Memory type/category filter or value, such as episodic, identity, procedural, semantic, working, auto, or %. | % |
| path_filter | No | Memory path filter; % matches all paths. | % |
| prefer_working | No | Whether to prioritize working/session-state memories in retrieval. | |
| agent_instance_id | No | Optional stable, non-secret agent instance ID for per-client attribution. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context about retrieving the few most relevant memories and that it is used before answering, which is useful 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?
Two concise sentences with no wasted words. First sentence states purpose and usage, second provides alternative.
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?
Given the tool has an output schema (not shown), the description is complete enough. It covers what it does and when to use it, with schema handling parameter details.
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 good descriptions for all parameters. The description adds minimal extra meaning beyond the schema, so 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 the verb 'Recall' and resource 'saved memories', and distinguishes from sibling 'recall_context' by specifying when many memories are needed.
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 (when prior preferences, known facts, etc., affect response) and provides a clear alternative (recall_context for many memories).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recall_contextBuild XMemo contextARead-onlyIdempotentInspect
Build a context pack from XMemo memories. Call this before answering or planning when the task could benefit from multiple saved memories — preferences, prior conversations, projects, decisions, TODOs, or long-running work.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. | |
| query | Yes | Natural-language question or search text. | |
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| bucket | No | Memory bucket or namespace to read from or write to; use % only for tools that support wildcard reads. | % |
| team_id | No | Optional team/workspace identifier for team-scoped memory access. | |
| agent_id | No | Optional client-supplied agent label for memory attribution. | |
| max_items | No | Maximum number of memory items to include. | |
| max_tokens | No | Approximate maximum response size. | |
| memory_type | No | Memory type/category filter or value, such as episodic, identity, procedural, semantic, working, auto, or %. | auto |
| output_json | No | Return a machine-readable JSON response instead of a human-readable summary. | |
| path_filter | No | Memory path filter; % matches all paths. | % |
| prefer_working | No | Whether to prioritize working/session-state memories in retrieval. | |
| agent_instance_id | No | Optional stable, non-secret agent instance ID for per-client attribution. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds behavioral context: it builds a 'context pack' from multiple memories, meant for holistic preparation. No contradictions.
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, front-loaded with the primary purpose and usage guidance. No filler. Every word earns its place.
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?
Given 13 parameters, output schema present, and rich annotations, the description adequately covers the 'why and when'. It does not explain the return format (but output schema does) or parameter details (schema covers them). Could mention that it returns a structured context pack, but overall sufficient.
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 13 parameters have descriptions in the schema (100% coverage). The tool description does not elaborate on any parameter beyond the schema. The overall purpose is clear, but parameter-specific semantics are fully delegated to 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 a clear verb ('Build') and resource ('context pack from XMemo memories'), and provides concrete examples of when to use it (preferences, prior conversations, projects, etc.). It implicitly distinguishes from siblings like 'recall' or 'search_memory' by focusing on multiple memories.
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 tells when to call: 'before answering or planning when the task could benefit from multiple saved memories'. Provides examples of memory types. Lacks explicit 'when not to use' or alternative tool names, but the context signals list many siblings, so it's reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
record_eventRecord EventAInspect
Record a significant session event, milestone, decision, or handoff note useful for reconstructing recent work. Not for durable facts/preferences (use remember).
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| bucket | No | Memory bucket or namespace to read from or write to; use % only for tools that support wildcard reads. | work |
| content | Yes | Text body to save, such as a memory, TODO/action item, event note, or state summary. | |
| event_type | No | Timeline event type, such as event, milestone, decision, or handoff. | event |
| session_id | No | Optional session identifier associated with the event, timeline query, or snapshot. | |
| metadata_json | No | Optional JSON object string with extra metadata for the operation. | {} |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-readOnly and non-destructive traits. Description adds context that events are for transient reconstruction, but could clarify whether events are appended or overwritten. Nonetheless, adds value 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?
Two sentences: first states purpose and examples, second states exclusion. Front-loaded and 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?
With output schema present, return values are covered. Tool is simple record operation, description covers what, when, and alternatives. Complete for this complexity.
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 has 100% description coverage, so baseline is 3. Description does not add parameter-specific meaning beyond 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?
Description clearly states the tool records session events, milestones, decisions, or handoff notes, and explicitly distinguishes from 'remember' for durable facts.
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 (significant session events for reconstructing recent work) and when-not-to-use (durable facts/preferences, with alternative tool named 'remember').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberRemember in XMemoAInspect
Save a memory so it can be recalled in future conversations. Call this whenever the user states a durable fact, preference, instruction, identity or profile detail, project detail, or recurring workflow likely useful later — you do not need an explicit 'remember this'. Skip transient chit-chat. For spending, income, refunds, or bookkeeping requests, use add_expense.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | A simple user-facing category or path for this memory, such as preferences, projects/xmemo, or personal/travel. | |
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| bucket | No | Memory bucket or namespace to read from or write to; use % only for tools that support wildcard reads. | public |
| dedupe | No | Whether to check for and merge likely duplicate memories before saving. | |
| content | Yes | Text body to save, such as a memory, TODO/action item, event note, or state summary. | |
| team_id | No | Optional team/workspace identifier for team-scoped memory access. | |
| agent_id | No | Optional client-supplied agent label for memory attribution. | |
| device_id | No | Optional client-supplied device identifier for attribution. | |
| memory_id | No | Exact XMemo memory reference shown by search or recall. | |
| confidence | No | Confidence score for the saved or updated memory, from 0.0 to 1.0. | |
| expires_at | No | Optional ISO 8601 expiration timestamp for the memory. | |
| importance | No | Importance score for the saved or updated memory, from 0.0 to 1.0. | |
| memory_type | No | Memory type/category filter or value, such as episodic, identity, procedural, semantic, working, auto, or %. | auto |
| device_label | No | Optional human-readable device label for attribution. | |
| semantic_key | No | Optional stable semantic key used to identify or upsert a memory concept. | |
| metadata_json | No | Optional JSON object string with extra metadata for the operation. | {} |
| embedding_json | No | Optional JSON array or object containing a precomputed embedding; leave blank for normal use. | |
| provenance_json | No | Optional JSON object string describing memory source, evidence, or attribution. | {} |
| agent_instance_id | No | Optional stable, non-secret agent instance ID for per-client attribution. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so description carries the burden. It explains basic write behavior but does not disclose whether saves always create new memories or update existing ones (despite dedupe parameter), what happens on duplicate, or any response details. Acceptable but leaves some ambiguity.
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 sentences, front-loaded with purpose, followed by usage guidelines and alternative. No filler or repetition; every sentence earns its place.
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?
For a tool with 19 parameters and an output schema, the description provides core purpose and usage context but could elaborate on behavioral nuances like deduplication or update semantics. Still, it is largely complete for an agent to decide when to invoke.
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%, so parameters are already documented. The description adds no additional meaning beyond what the schema provides, meeting the baseline for high coverage but not exceeding it.
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?
Description clearly states the tool saves a memory for future recall, specifies what constitutes a durable fact (preferences, instructions, etc.), and distinguishes from add_expense. It answers the 'what' and 'when' unambiguously.
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 says when to use (user states durable fact, preference, etc.) and when not to (transient chit-chat). Provides alternative tool (add_expense) for bookkeeping requests, fulfilling the when/when-not/alternatives criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
restore_memoryRestore XMemo memoryAInspect
Restore a previously deleted memory. Call this only when the user explicitly asks to restore or undo a deletion.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Optional user-facing reason for the deletion. | |
| memory_id | Yes | Exact XMemo memory reference shown by search or recall. | |
| metadata_json | No | Optional JSON object string with extra metadata for the operation. | {} |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutation that is not destructive. The description adds a precondition (memory must be previously deleted) but does not elaborate on other behavioral aspects like permissions or side effects.
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 consists of two concise sentences, each adding value. The first states the action, the second provides a clear usage rule. No redundancy or 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?
For a simple restore operation, the description fully covers the tool's purpose and usage condition. An output schema is present, so return values are already documented.
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 description coverage is 100%, with each parameter having a clear description (e.g., memory_id: 'Exact XMemo memory reference'). The tool description adds no additional parameter meaning beyond what the schema 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?
The description clearly states 'Restore a previously deleted memory' with a specific verb and resource. It distinguishes from sibling tools by including a usage condition that narrows its purpose to explicit restore/undo requests.
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 provides explicit guidance: 'Call this only when the user explicitly asks to restore or undo a deletion.' This clarifies when to use the tool, though it doesn't explicitly mention alternative tools for other contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_memoryUpdate XMemo memoryAInspect
Update the content, location, or type of an existing memory. Call this only when the user explicitly asks to correct, revise, move, or reclassify a specific saved memory.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | A simple user-facing category or path for this memory, such as preferences, projects/xmemo, or personal/travel. | |
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| bucket | No | Memory bucket or namespace to read from or write to; use % only for tools that support wildcard reads. | |
| status | No | Memory status filter or update value, such as active, archived, deleted, or %. | |
| content | No | Text body to save, such as a memory, TODO/action item, event note, or state summary. | |
| team_id | No | Optional team/workspace identifier for team-scoped memory access. | |
| memory_id | Yes | Exact XMemo memory reference shown by search or recall. | |
| confidence | No | Confidence score for the saved or updated memory, from 0.0 to 1.0. | |
| expires_at | No | Optional ISO 8601 expiration timestamp for the memory. | |
| importance | No | Importance score for the saved or updated memory, from 0.0 to 1.0. | |
| memory_type | No | Memory type/category filter or value, such as episodic, identity, procedural, semantic, working, auto, or %. | |
| semantic_key | No | Optional stable semantic key used to identify or upsert a memory concept. | |
| metadata_json | No | Optional JSON object string with extra metadata for the operation. | {} |
| merge_metadata | No | Whether to merge new metadata with existing metadata instead of replacing it. | |
| provenance_json | No | Optional JSON object string describing memory source, evidence, or attribution. | {} |
| detect_conflicts | No | Whether to detect possible conflicts with existing memories during an update. | |
| merge_provenance | No | Whether to merge new provenance with existing provenance instead of replacing it. | |
| supersession_reason | No | Reason the updated memory supersedes older content. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (mutation) and destructiveHint=false (not destructive). The description adds no further behavioral details (e.g., whether updates are reversible, permissions needed). It does not contradict annotations but adds minimal extra value.
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 consists of two concise, front-loaded sentences with no wasted words. Every sentence serves a clear purpose: stating function and usage condition.
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?
Given the tool's complexity (18 parameters, output schema present), the description adequately covers high-level behavior. It could provide more context about what the update returns or side effects, but the output schema fills some gaps.
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 in the input schema. The tool description does not add any additional meaning beyond what the schema already provides. 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 the verb 'Update' and the resource 'existing memory', and specifies the aspects that can be updated ('content, location, or type'). It effectively distinguishes from sibling tools like 'remember' (create) and 'forget' (delete).
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 states when to call this tool: 'only when the user explicitly asks to correct, revise, move, or reclassify a specific saved memory.' This provides clear usage conditions and implies when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_stateUpdate StateAInspect
Save the current working state during long-running work — active task, next action, or blocker — so future turns/sessions can resume. For durable user facts use remember.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Optional scope that narrows memory access; leave blank for the token default. | |
| bucket | No | Memory bucket or namespace to read from or write to; use % only for tools that support wildcard reads. | work |
| content | No | Text body to save, such as a memory, TODO/action item, event note, or state summary. | |
| state_key | No | Working-state key to save, snapshot, or restore, such as active_task. | active_task |
| next_action | No | Next action to persist so future turns can resume the work. | |
| ttl_seconds | No | Time-to-live in seconds for working state or restart snapshot records. | |
| current_task | No | Current task or work item to persist for later resume. | |
| metadata_json | No | Optional JSON object string with extra metadata for the operation. | {} |
| blocked_reason | No | Short explanation of why the current work is blocked. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's a write but not destructive. The description adds context about working state and TTL (implied by default), but doesn't disclose all behavioral traits like whether it overwrites or appends.
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, no fluff: first states purpose, second provides usage guidance. Well-structured and front-loaded.
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 an output schema and full parameter documentation, the description adequately explains the use case and session resumption utility. Could be slightly more detailed on behavior like overwrite semantics.
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%, so baseline 3 is appropriate. The description mentions 'active task, next action, or blocker' which maps to some params, but adds no additional meaning beyond the schema descriptions.
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 'save' and the resource 'current working state', and explicitly distinguishes from the sibling tool 'remember' for durable facts.
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?
It explicitly says when to use ('during long-running work') and when not to ('For durable user facts use remember'), providing clear context signals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.