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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description does not need to reiterate safety. It adds value by disclosing scoping ('Scoped to your identifier') and pairing with remember/forget. It does not describe return format or performance, but given the simplicity and annotation coverage, this is sufficient.

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, each with clear purpose. First sentence states the core action. Second explains when to use. Third adds important context about scoping and pairing. No redundant or vague language. Perfectly 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?

With no output schema, the description should explain what the tool returns (e.g., value format, list of keys). It only says 'retrieve a value' and 'list all saved keys' but does not specify the data structure or type. However, given the tool's simplicity and symmetry with remember, this is a mild omission. It is adequate but not fully complete.

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 the schema already explains the key parameter and omission behavior. The tool description reinforces this with additional context about listing all keys and the use case. It adds marginal value but is consistent and clear.

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?

Description clearly states verb 'Retrieve' and resource 'value previously saved via remember' or 'list all saved keys'. It distinguishes from siblings by naming remember and forget, and explains when to use each mode (omit key for listing). The use case is concrete: look up stored context like ticker or address.

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?

Description explicitly states to use this tool to retrieve previously stored context without re-deriving. It implies when not to use (when you want to save, use remember; to delete, use forget). However, it could be more explicit about situations where recall is inappropriate (e.g., stale data). Nonetheless, the guidance is clear and actionable.

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