MemoryRouter

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

The description adds detail beyond annotations: it explains the server stores reflections, links them to source memories, and marks sources consolidated. It also clarifies idempotency ('committing the same batch twice returns the original result'), enriching the idempotentHint annotation. 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?

Three sentences, all high-value: purpose, content of submissions, and server behavior plus idempotency. No redundancy or fluff. Information is front-loaded with the primary use case.

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 existence of an output schema and sibling tools, the description covers the workflow context (consolidation), the expected input format, and the outcome (storage, linking, consolidation marking). It is complete for an 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?

Despite 0% schema coverage, the description explains both parameters: 'batch' (batch_id) as the checked-out batch, and 'entries' as 'standalone prose with an importance rating from 1 to 10'. This gives functional meaning that complements the schema's structural constraints.

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 function: 'complete a consolidation started with consolidate_memories' and 'Submits the reflection entries'. It identifies the specific resource (checked-out batch) and distinguishes from sibling tools by framing it as the commit step in a workflow.

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 'Use this to complete a consolidation started with consolidate_memories', giving clear context and a prerequisite. Also notes 'Safe to retry' with idempotent behavior, guiding when re-invocation is appropriate. Alternative tools are not needed because this is a specific workflow step.

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

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

Discloses a 15-minute lease, the return of 'texts plus server instructions', the need to follow those instructions, and that 'Nothing is modified until commit'. This is critical side-effect information beyond the generic annotations, which only say readOnlyHint=false and destructiveHint=false.

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 paragraph of four sentences, each adding critical information: trigger, action, follow-up instruction, and side-effect note. It is somewhat dense but not wasteful. Front-loaded with the usage trigger, then mechanism, then safety. Slightly long for a description but justified by the complexity.

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 existence of an output schema, the description does not need to list return fields. It covers the complete user journey: when to invoke, what the tool does, what to do with the results, and what is not changed. It also acknowledges the memory_status/search context, making it complete for an AI agent selecting this 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?

The input schema already covers both parameters (tier and max_tokens) with complete descriptions (100% schema coverage). The tool description does not add extra meaning about these parameters, but it does mention 'batch_id' in the workflow, which is presumably returned by this tool and used in the follow-up. 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 uses specific verbs and resources: 'Checks out a batch of unconsolidated memories from the connected vault under a 15 minute lease'. This clearly distinguishes the checkout action from the later commit step (commit_reflections) and other sibling tools like delete_memories 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 states when to use: 'when the user asks to consolidate, reflect on, or organize their memories, or when memory_status or a search result reports that consolidation is available'. It also gives follow-up guidance: 'call commit_reflections with the batch_id', clearly pointing to an alternative/succeeding tool.

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

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.

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.

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.

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.

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.

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.

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

While annotations already include destructiveHint=true and readOnlyHint=false, the description adds critical behavioral details beyond annotations: 'This cannot be undone' (irreversibility), 'Deleting a raw memory does not delete reflections built from it' (side-effect boundary), and requiring user confirmation. These details meaningfully inform the agent about consequences and limitations.

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-load the core usage constraint, then state the action and side effects, and end with an alternative. Every sentence carries essential information with zero redundancy or filler.

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 moderate complexity, presence of an output schema, and robust annotations, the description covers all necessary context: when to use, what it does, side-effect nuance, irreversibility, and a sibling alternative. Nothing critical is missing for an agent to select and invoke this 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?

Input schema covers both parameters with descriptions (100% coverage), so baseline is 3. The description adds context that IDs come 'from search or inspect results', which helps the agent know where to source IDs. However, the description does not elaborate on the confirmation parameter, though the schema already fully explains it. Adds modest value 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?

The description clearly states the tool 'Permanently deletes the identified memories from the connected vault by their ids' and explicitly distinguishes it from forget_all_memories for whole-vault deletion. The verb 'delete' plus resource 'specific memories' and scope makes the purpose unambiguous and distinct from siblings.

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 'Use this only when the user explicitly asks to delete specific memories and confirms after seeing what will be deleted' and provides a clear alternative: 'For deleting everything, forget_all_memories is the separate whole-vault tool.' This gives both when-to-use and when-not-to-use guidance.

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

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

The description discloses the permanent and destructive nature of the operation, the need for separate memories:delete authorization, and the requirement for destructive host confirmation. This adds valuable context beyond the annotations, which already indicate destructiveness, by explaining the security and confirmation flow.

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, using four short sentences that each carry essential information: usage precondition, action, alternative, and authorization requirement. There is no fluff or redundancy.

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 destructive nature of the tool, the description fully covers when to use it, what it does, its alternative, and prerequisites such as user confirmation and authorization. The presence of an output schema means return values do not need to be explained in the description.

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?

The single parameter 'confirmation' is fully documented in the schema with an enum and a clear description. The tool description reiterates the confirmation phrase but adds no new information beyond what the schema already provides, so it meets the baseline for high schema 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 that the tool permanently deletes every memory in the OAuth-selected vault, using a specific verb and resource. It also distinguishes itself from delete_memories, which handles specific items, removing ambiguity.

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 provides the exact conditions for use: the user must explicitly request a full-vault deletion, receive a permanent warning, and provide the confirmation phrase in a later turn. It also directs the user to delete_memories for targeted deletions, offering a clear alternative.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by detailing the directional behavior: for a reflection ID it returns lower-tier memories, for a raw memory it returns reflections it was consolidated into. This goes beyond 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?

The description is concise (five sentences) with front-loaded usage guidance, a clear action statement, and a drill-down usage pattern. Every sentence earns its place with no redundancy or filler.

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 tool with one parameter and a known output schema, the description covers purpose, usage, behavioral details, and safety. It is complete without needing to describe return values since an output schema exists.

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%, providing a clear description for memory_id. The description repeats that the ID comes from a search result or previous inspect, but adds no new structural or semantic detail beyond what the schema already contains. 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 explicitly states the tool inspects memory lineage by returning lower-tier memories or reflections based on a memory ID. It clearly distinguishes itself from sibling tools like search_memories (searching) and delete_memories (deleting) through its specific verb and resource.

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 when-to-use guidance: 'Use this when the user asks why the assistant believes something, or wants to see the source memories behind a reflection.' It also suggests using repeatedly to drill down. It does not explicitly state when not to use, but sibling context implies alternatives exist.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds valuable context about what information is revealed (connection, vault binding, counts) and what is not (memory key), going 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?

The description is a single sentence that is front-loaded with the usage trigger and lists specific information it provides. Every word earns its place, with no fluff or repetition.

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 zero-parameter status tool with an output schema present, the description covers all relevant aspects: when to use it, what it reports, and a key limitation. It is complete for the tool's simplicity.

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?

The input schema is empty and parameter count is zero, so there are no parameters to document. Baseline for zero params is 4, and the description adds no unnecessary parameter information, which 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 explicitly states what the tool does: it checks whether MemoryRouter is connected, which opaque vault binding is active, and how many memories/tokens the vault contains. This distinguishes it from sibling tools by focusing on status/connection info rather than mutations or searches.

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 provides explicit 'Use this when...' conditions covering the exact user questions that should trigger this tool. It also includes a clear limitation ('Does not reveal the memory key'), which helps set appropriate expectations. While no alternative tools are named, the scope is precise enough to avoid misuse.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this by saying 'without modifying it'. It adds extra behavioral context by disclosing limitations (no citable item permalinks, no Company Knowledge fetch support), which goes beyond the safety 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 three sentences, each serving a distinct purpose: usage context, function, and limitation/alternative. It is front-loaded with the key usage instruction and contains no filler.

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 one-parameter search tool with rich annotations and an output schema, the description covers purpose, usage, limitations, and alternatives. It provides sufficient context for an agent to decide when to invoke it and what to expect.

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?

The input schema fully documents the single 'query' parameter with a description (100% coverage). The description does not add additional parameter semantics, but the schema already covers it, 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 tool's function as a legacy compatibility alias that searches the MemoryRouter vault. It uses specific verbs ('searches') and resource ('MemoryRouter vault'), and distinguishes itself from the preferred search_memories tool by noting limitations.

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: when a client requests a tool named 'search'. It also provides an alternative: 'prefer search_memories' for normal recall, and explains the trade-off (no citable permalinks or Company Knowledge support).

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

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.

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.

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.

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.

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.

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.

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

Annotations are all false, providing no safety hints, so the description carries the burden. It discloses that the tool is a write operation (saves), requires user approval, and interacts with an OAuth-selected vault. It also explicitly warns against silent capture, adding meaningful behavioral context beyond the annotation defaults.

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, front-loaded with the critical usage rule, then states the purpose and an exclusion. Every word earns its place, with 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?

Given the simple tool (2 params, 1 required), an output schema is present, and a rich description covering purpose, usage, and exclusions, the description is sufficiently complete. It leaves out edge cases like duplicate handling or overwrite behavior, but these are not essential for a basic store operation.

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%, and both parameters (content and tags) have detailed descriptions in the schema itself. The tool description adds no parameter-specific detail beyond what the schema already provides, so the baseline score of 3 applies.

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 explicitly states the action ('Saves'), the resource ('content to the OAuth-selected vault'), and the scope ('user-approved content'). It also differentiates from sibling tools by being the only write operation to store memories, contrasting with search, forget, and status 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?

Provides explicit criteria for use: 'Use this only when the user explicitly asks to remember something or confirms a proposed durable fact.' It also gives a clear exclusion: 'do not use it for silent conversation capture.' This effectively guides selection against alternatives.

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