MemoryRouter

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

Annotations already indicate destructiveHint=true and idempotentHint=true, but the description adds critical context: the deletion is permanent, requires separate memories:delete authorization and destructive host confirmation, and cannot target individual memories. This goes well beyond the annotations and provides the safety-relevant behavioral detail needed for an irreversible destructive operation.

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 four sentences, each earning its place: the strict usage condition, the irreversible action, the exclusion of single-memory deletion, and the required authorization. It is dense with necessary safety information without being bloated, and the most critical condition is 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?

For a highly destructive tool with strong annotations and an output schema, the description fully covers prerequisites, the confirmation workflow, authorization needs, and exclusion of item-level deletion. It is complete for an agent to correctly decide when and how to invoke 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?

Schema coverage is 100%: the single `confirmation` parameter is fully described with an enum and property description. The tool description mentions the exact confirmation phrase requirement but does not add meaning beyond the schema, so the baseline 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 it permanently deletes every memory in the OAuth-selected vault, using a specific action and resource scope. This is clearly distinct from the sibling tools like search_memories or store_memory, which operate at a different granularity.

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 to use this tool only after the user requests full-vault deletion, receives a permanent whole-vault warning, and provides the exact confirmation phrase in a later turn. It also explicitly says it cannot delete one memory and directs users to the dashboard for item-level curation, providing clear when-not 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 goes beyond the readOnlyHint annotation by adding a meaningful privacy disclosure: "Does not reveal the memory key." This is valuable behavioral context for the agent. It does not describe the output format, but annotations covering safety lower the bar.

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?

A single, well-structured sentence that front-loads the primary use case and adds the key privacy caveat. 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?

As a simple status-check tool with no parameters, an output schema, and annotations covering safety, the description fully covers the scope, use cases, and a critical behavioral detail. Nothing meaningful is missing.

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 tool has zero parameters, so the schema is trivially complete and the description does not need to explain parameters. This aligns with the 0-parameter baseline of 4.

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 reports MemoryRouter connection status, the active opaque vault binding, and the number of memories/tokens in the connected vault. This clearly distinguishes it from sibling tools like search or store_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?

The description provides explicit use cases ("Use this when...") but does not mention when not to use it or name alternative tools. This gives clear context without explicit exclusions, hence a 4 rather than 5.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by revealing that searches are semantic and scoped to the OAuth-selected vault. This goes beyond the annotation safety profile, though it does not detail rate limits or other operational traits. No contradiction 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 two sentences, front-loaded with the primary use case. Every word earns its place; no redundancy or fluff. It is compact while covering purpose, scope, and non-modifying behavior.

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 simplicity, the presence of an output schema, and annotations covering side effects, the description is complete. It explains when to use, what it does, its scope, and confirms it does not modify data. No critical information is missing.

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 have clear descriptions. The tool description does not add extra semantic detail beyond the schema (the query is already described as a 'concise natural-language description', and limit has default/maximum). Thus 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 purpose: searching a connected MemoryRouter vault for prior decisions, preferences, people, projects, or facts. It uses a specific verb ('semantically searches') and resource (OAuth-selected vault), effectively distinguishing it from broader search tools. The scope is explicit and unambiguous.

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 the tool ('Use this when the user asks about a prior decision...'), providing clear context. It does not name alternatives or exclusions, but the trigger condition is sufficiently specific. No misleading usage guidance is present.

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.