WorkingMemory

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

Annotations are minimal, so the description carries the burden. It discloses key behaviors: returns immediately while extraction happens in the background, stores facts automatically, and requires conversation_id. This adds significant behavioral detail not present in annotations or schema.

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?

Two sentences, front-loaded with the core purpose. Every sentence earns its place: one explains the what/when, the other provides the key usage instruction (conversation_id) and behavior (immediate return, background processing). No filler 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?

For a 3-parameter tool with no output schema and weak annotations, the description covers purpose, usage context, async behavior, and a critical parameter requirement. It doesn't address error cases or what happens on extraction failure, but that is not essential for 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%, so baseline is 3. The description adds value by emphasizing the need to always include conversation_id in client, which is useful because client is optional in the schema. It also reinforces what to pass for task_content, though the schema already documents that.

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 captures durable facts from a just-completed task as an automatic byproduct, with the user doing nothing. It specifies the input (task output/content) and the process (extracted and stored automatically), distinguishing it from sibling tools like save_memory by emphasizing the hands-off, automatic nature.

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 clear context: use after completing a task (drafting email, summarizing doc, making decision) and pass the task output. It implies when to use this instead of manual memory tools, but does not explicitly name alternatives or exclusions like save_memory or search_memory.

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 mark this as destructive (destructiveHint=true) and not read-only. The description adds valuable context by specifying 'soft delete — recoverable for 30 days', which goes beyond the mere destructive flag and informs the user about recovery options. This is meaningful additional behavioral transparency.

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?

Two sentences, front-loaded with the core purpose. Every sentence earns its place: the first states what the tool does, the second provides the necessary precondition and usage hint. No 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?

For a simple two-parameter delete tool with no output schema, the description covers the essential context: what it does, how to use it (search first), and key behavior (soft delete). The annotations handle safety, and the schema handles parameter details. The description is fully sufficient for an agent to select and 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 covers 100% of parameters (action, id). The description adds semantic value by stating deletion is by id and clarifying that 'Currently supports deleting' means action is limited to delete. It also explains the effect of the delete (soft delete with 30-day recovery), which is 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's function: 'Manage an existing memory item' with the current capability of 'deleting a memory by id'. It specifies the action (delete), the resource (memory item), and distinguishes from sibling tools like capture_memory and save_memory by noting this is for existing items and supports only deletion.

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 instructs users to 'Use search_memory to find the id first', which is a direct usage guideline. It also implies the tool is for deletion only ('Currently supports deleting'), so users are directed away from using it for creation or searching. This is clear when/what/why 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 provide no hints (all false), so the description carries the burden. It discloses that text is parsed into structured memory items, becomes searchable later, and that pasted text is automatically split. However, it omits important behavioral details such as whether saves are idempotent, whether duplicates are created, or what the output/return value looks like. The disclosed behaviors are useful but incomplete for a write 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 concise and well-structured: three sentences that state the core purpose, highlight the parsing behavior, and provide a specific use case with instructions. Every sentence earns its place without 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 no output schema, no useful annotations, and moderate complexity (nested object), the description covers the main operational aspects: what to save, how it is processed, and how to use it for a special case (pasted memories). It lacks details on return values or error conditions, but for a simple save tool, it is reasonably complete and unlikely to confuse an agent.

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 baseline is 3. The description adds value by explaining that the 'text' parameter can contain multiple memories that will be split automatically, and that pasted notes should be passed in full. This goes beyond the schema's simple 'thought or note to save' and clarifies intent.

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 identifies the tool's function: saving thoughts, insights, facts, or todos to Working Memory. It also distinguishes itself from search_memory by noting the saved items become searchable a moment later, and addresses a specific use case (importing memories from another assistant) that sets it apart from likely sibling 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?

The description explicitly states when to use this tool: for saving thoughts/insights/facts/todos, and for pasted memories/notes from another assistant. It names search_memory as the counterpart for retrieving saved items. However, it does not explicitly say when NOT to use it or how it differs from capture_memory/manage_memory, but the given use cases provide adequate contextual 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 adds a key behavioral requirement: 'Always include your conversation id in client.conversation_id.' This goes beyond the readOnlyHint annotation, which already signals safety. The description also clarifies the tool operates on 'past notes and facts' in Working Memory. 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?

Two concise sentences that front-load the purpose and usage. Every sentence adds value: the first states what it does, the second gives when-to-use and a critical parameter instruction. 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 read-only search tool with full schema coverage and no output schema, the description covers purpose, usage, and the required conversation_id. It doesn't explain return format or dedup behavior, but these are secondary given the tool's simplicity and the readOnlyHint annotation.

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 each parameter is fully described in the schema. The description reinforces the importance of client.conversation_id but doesn't provide additional semantic detail beyond the schema (e.g., query syntax, format of conversation_id).

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 verb 'Search' and the resource 'the user's Working Memory' for relevant past notes and facts. It distinguishes itself from sibling tools (capture_memory, save_memory, manage_memory) which are write-oriented, by explicitly focusing on retrieval.

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 guidance on when to use the tool: 'Use this when the user references something they may have stored earlier, or to find related context before answering.' It doesn't explicitly mention when not to use or alternatives, but the context is clear enough for an agent to differentiate.

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