XMemo

Query Audit

query_audit

Read-onlyIdempotent

Query audit records within the caller's authorized memory scope. source='events' selects action/time/target events; source='consolidation' selects consolidation/lifecycle/reflection history. This does not grant cross-user or system administration access.

Input Schema

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.
`since`	No	RFC 3339 timestamp with timezone offset (e.g., '2026-09-01T00:00:00+09:00'). Set this whenever the user query mentions any relative or absolute time constraint in any language (e.g., today, yesterday, last week, last month, recently, Aug 1, Aug 10 to Sep 1, since Monday, before Sep 15, in Q3). Relative and natural language time expressions are given as absolute timestamps in the user's local time. If omitted, the server falls back to heuristic guessing which may misinterpret timezone day boundaries or relative dates.
`until`	No	RFC 3339 timestamp with timezone offset (e.g., '2026-09-02T00:00:00+09:00'). When used with since, defines the half-open interval [since, until) with until > since (maximum 90 days span). Set this when the user query specifies an end date or bounded window in any language (e.g., yesterday end of day, by Aug 10, Aug 10 to Sep 1). Natural language end bounds are given as absolute timestamps with timezone offsets. If omitted, the window is open-ended on the upper side or derived heuristically.
`action`	No	Usage action or audit-event action filter, depending on the tool.
`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.
`source`	No	Optional source filter for system statistics.	events
`target_id`	No	Optional audit target ID to filter audit events.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026

changedInput schema / properties / since / description

Previous value: -"RFC 3339 timestamp with timezone offset (e.g., '2026-09-01T00:00:00+09:00'). Trigger: Call this whenever the user query mentions any relative or absolute time constraint in any language (e.g., today, yesterday, last week, last month, recently, Aug 1, Aug 10 to Sep 1, since Monday, before Sep 15, in Q3). Model responsibility: You (the calling LLM) know current date and user local time, so you must convert natural language time expressions into absolute timestamps. Consequence: If omitted, the server falls back to heuristic guessing which may misinterpret timezone day boundaries or relative dates."New value: +"RFC 3339 timestamp with timezone offset (e.g., '2026-09-01T00:00:00+09:00'). Set this whenever the user query mentions any relative or absolute time constraint in any language (e.g., today, yesterday, last week, last month, recently, Aug 1, Aug 10 to Sep 1, since Monday, before Sep 15, in Q3). Relative and natural language time expressions are given as absolute timestamps in the user's local time. If omitted, the server falls back to heuristic guessing which may misinterpret timezone day boundaries or relative dates."

changedInput schema / properties / until / description

Previous value: -"RFC 3339 timestamp with timezone offset (e.g., '2026-09-02T00:00:00+09:00'). When used with since, defines the half-open interval [since, until) with until > since (maximum 90 days span). Trigger: Pass when the user query specifies an end date or bounded window in any language (e.g., yesterday end of day, by Aug 10, Aug 10 to Sep 1). Model responsibility: Convert natural language end bounds into absolute timestamps with timezone offsets. Consequence: If omitted, the window is open-ended on the upper side or derived heuristically."New value: +"RFC 3339 timestamp with timezone offset (e.g., '2026-09-02T00:00:00+09:00'). When used with since, defines the half-open interval [since, until) with until > since (maximum 90 days span). Set this when the user query specifies an end date or bounded window in any language (e.g., yesterday end of day, by Aug 10, Aug 10 to Sep 1). Natural language end bounds are given as absolute timestamps with timezone offsets. If omitted, the window is open-ended on the upper side or derived heuristically."

AddedSep 11, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description contributes the meaningful extra constraint that this does not grant cross-user or admin access. It says nothing about result volume, pagination semantics, or the 90-day span limit that lives only in the schema.

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

Conciseness5/5

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

Three short sentences, front-loaded with purpose and scope, then the source semantics, then the access boundary. No filler and nothing buried.

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

Completeness4/5

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

An output schema exists and nine parameters are fully documented, so the description needn't explain returns. It covers scope, source modes, and the access boundary, but leaves the agent to discover pagination (limit/offset defaults) and the since/until window rules from the schema alone.

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

Parameters4/5

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

Schema coverage is 100%, so baseline would be 3, but the description adds real semantics for the source parameter that the schema obscures ('source' is described generically as a 'source filter for system statistics'). Clarifying that 'events' returns action/time/target events while 'consolidation' returns consolidation/lifecycle/reflection history is genuine value beyond the structured field.

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

Purpose4/5

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

States a specific verb and resource ('Query audit records') plus the scoping constraint ('within the caller's authorized memory scope'), and enumerates the two source modes. It doesn't differentiate from nearby siblings like get_timeline or explain_memory, so an agent must infer which one to reach for.

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

Usage Guidelines3/5

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

The source='events' vs source='consolidation' split gives implied usage guidance for choosing a record class. However, there is no explicit statement of when to use this tool versus the audit-adjacent siblings (get_timeline, memory_stats, explain_memory), and no prerequisites are spelled out.

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

All XMemo tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.