MemoryRouter

Search memories

search_memories

Read-only

Use this when the user asks about a prior decision, preference, person, project, or other fact that may be in their connected MemoryRouter vault. Semantically searches only the OAuth-selected vault and does not modify it. 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. Broad 'most important things we have done' questions: tiers [3], importance 8 or higher, large limit such as 250. Big-picture overviews like 'what do you know about this area or period': tiers [3] with no importance filter. Specific lookups like 'find the decision about X': omit tiers to search all tiers blended 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. For time-window questions like 'what happened last week' or 'lately' use date_search_memories instead.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum number of relevant memories to return. Use a large limit such as 250 for broad 'most important things' questions over tiers [3].
`query`	Yes	A concise natural-language description of the past context to recall.
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`count`	Yes
`query`	Yes
`memories`	Yes
`consolidation_available`	No

TDQS

A5/5.0

Behavior5/5

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

The description explicitly states the tool does not modify the vault, complementing the readOnlyHint annotation. It also discloses important behavioral nuances: importance filtering excludes raw memories, tier semantics, and the need to omit tiers for blended searches. This adds significant 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.

Conciseness5/5

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

The description is lengthy but every sentence is purposeful, providing actionable guidance. It is well-structured, starting with the primary use case, then tier guide, then specific strategies. Despite its length, it avoids fluff and maintains focus.

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 (tiered memory system, multiple parameters, and a sibling for date searches), the description covers all necessary aspects: when to use, how to filter tiers, importance semantics, and drill-down workflows. The output schema exists, so return values are not required. This is comprehensive.

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

Parameters5/5

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

With 100% schema coverage, the baseline is 3, but the description adds substantial value by explaining parameter interplay, such as how importance thresholds interact with tier selections and how to set limit for broad queries. It also clarifies when to omit parameters entirely, which is not in the schema.

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 clearly states that the tool semantically searches the user's MemoryRouter vault for prior decisions, preferences, people, projects, and facts. It distinguishes itself from siblings by specifying it only searches (does not modify) and points to date_search_memories for time-based queries.

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 provides exceptionally detailed usage guidance, including when to use it (user asks about prior information), when not to (time-window questions should use date_search_memories), and alternative tools (inspect_memory for drill-down). It gives tier-specific strategies for different question types, which is far beyond typical guidance.

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?