MemoryRouter

Search memories by date

date_search_memories

Read-only

Use this to retrieve memories from a specific time window, for questions like 'what happened last week' or 'most important things this month or lately'. Tier guide: tier 3 holds the highest-level consolidated reflections (identity, principles, what matters most), tier 2 holds reflections of specific meaningful events, tier 1 holds raw verbatim memories. Match filters to the question. Time-bounded 'most important things last month' questions: tiers [3], importance 8 or higher, generous max_tokens. Big-picture overviews of a period like 'what do you know about July': tiers [3] with no importance filter. Specific lookups in a window like 'find the decision about X': omit tiers to include all tiers and leave importance unset; a high importance filter hides the specific detail you are looking for. Specific meaningful events without raw noise: tiers [2] or [2, 3]. Exact verbatim detail: if the detail is not already in context, drill down by lineage: search tiers [3] to find the relevant thread, then use inspect_memory on the result to see the tier 2 reflections it consolidated, then inspect those to reach the raw memories underneath. Direct tiers [1] search works when you know exact wording to match. Mixing tiers is legitimate; adjust the importance threshold to the question rather than always setting it high. Only reflections (tiers 2 and 3) carry importance ratings. Omit query for a chronological review; include query to rank by relevance within the window. Resolve relative phrases like 'lately' to concrete ISO dates before calling. Reads only the OAuth-selected vault and does not modify it.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No	Window end, ISO 8601 date or datetime. Optional, defaults to now.
`from`	Yes	Window start, ISO 8601 date or datetime (e.g. 2026-08-10 or 2026-08-10T00:00:00Z). Required. Must be a concrete date, not a relative phrase.
`query`	No	Optional relevance query. Omit for a pure chronological browse; include to rank results within the window.
`tiers`	No	Restrict results to these memory tiers. 3 highest-level consolidated reflections (identity, principles, what matters most), 2 reflections of specific meaningful events, 1 raw verbatim memories. Use [3] for broad 'most important' or big-picture questions, [2] or [2, 3] for specific meaningful events, [1] for exact verbatim detail when you know the wording to match; otherwise drill down from [3] with inspect_memory. Omit to search all tiers blended, the right default for specific lookups. Mixing tiers is fine. Only tiers 2 and 3 carry importance ratings.
`importance`	No	Minimum importance threshold, 1 to 10. Only reflections (tiers 2 and 3) carry ratings, so raw memories are excluded whenever this is set. Use 8 or higher with tiers [3] for broad 'most important' questions. Leave unset for general or specific searches; a high threshold hides relevant material.
`max_tokens`	No	Token budget for returned results. Server default 50000; use a smaller value like 5000 for a quick look. When a page is truncated, continue with the returned next_to or next_from cursor.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`to`	No
`from`	Yes
`count`	Yes
`window`	No
`next_to`	No
`memories`	Yes
`next_from`	No
`truncated`	No

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds significant behavioral context: it reads only the OAuth-selected vault, does not modify it, explains truncation with max_tokens and cursor continuation, and details how tiers and importance interact. No contradictions with annotations.

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

Conciseness4/5

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

The description is long but well-structured, with clear sections (tier guide, parameter advice, usage patterns). Every sentence earns its place, though the wall-of-text format could be slightly more scannable with bullet points. Still, it is appropriately sized for the tool's complexity.

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

Completeness5/5

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

Given the tool's complexity (6 parameters, output schema exists, annotations present), the description covers all essential aspects: parameter behavior, tier hierarchy, importance semantics, pagination hints, and relationship with inspect_memory. No significant gaps remain.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds strategic value beyond the schema: for example, it explains when to omit tiers ('specific lookups'), when to set importance high ('most important' questions), and how to combine parameters. This additional context elevates the score above baseline.

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

Purpose5/5

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

The description starts with a specific verb+resource ('retrieve memories from a specific time window') and immediately provides concrete examples ('what happened last week', 'most important things this month'). It clearly distinguishes from sibling tools like search_memories and inspect_memory through the tier guide and explicit mention of drill-down behavior.

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

Usage Guidelines5/5

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

The description offers extensive when-to-use guidance: tier selection rules, importance filter heuristics, query omission for chronological browse, and explicit instruction to resolve relative phrases to ISO dates. It also implies when to use inspect_memory as an alternative (drill-down from tier 3). No gaps in usage context.

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

All MemoryRouter tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation4/5

The tools are mostly distinct, but search and search_memories overlap in purpose, with search being a legacy alias with fewer features. The consolidation workflow tools (consolidate_memories and commit_reflections) are very specific, but their descriptions clearly delineate their roles. Overall, minor overlap exists.

Naming Consistency4/5

Tool names use a consistent verb_noun pattern (e.g., commit_reflections, consolidate_memories, date_search_memories). The only minor inconsistency is the pair search and search_memories, where search deviates from the descriptive pattern of its counterpart. Otherwise, naming is clear and predictable.

Tool Count5/5

The server has 10 tools, which is appropriate for a memory management system. Each tool covers a distinct operation (CRUD, search, consolidation, inspection), and the count is neither too few nor too many for the stated purpose of managing and querying a personal memory vault.

Completeness4/5

The tools provide complete CRUD (store, search, retrieve, delete) plus consolidation and inspection workflows. Gaps are minor: there is no explicit tool to list all top-level categories or tags, and update_memory is absent, though consolidation and deletion cover lifecycle needs. The surface is nearly complete.

Resources

Need Help?