agent-memory

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

With no annotations, the description carries full responsibility for disclosing the destructive nature. It says 'Delete all memories' but does not mention that this is permanent, irreversible, or that it affects the entire namespace without confirmation. For a high-impact destructive operation, this is a significant gap.

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 clear sentence with no wasted words. It precisely conveys the action and object in a concise manner.

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?

While the tool is simple in structure, it performs a destructive bulk operation. The description lacks essential context such as irreversibility, behavior on non-existent namespaces, and any safety warnings. Given the absence of annotations and output schema, the description should carry more load to be 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?

The schema covers 100% of the parameters, and the description for namespace ('Namespace to clear') is minimal but adequate. The description itself adds no extra semantic detail 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 a specific action and resource: 'Delete all memories in a namespace.' The phrase 'all memories' distinguishes it from the sibling tool delete_memory, which presumably deletes a single memory. No 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?

The description does not provide any guidance on when to use this tool versus alternatives. It does not mention that it should be used for bulk clearing rather than iterating with delete_memory, nor does it state any prerequisites or warnings. Usage is only implied by the content.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action 'delete' but does not describe side effects (e.g., whether the deletion is permanent), error handling for non-existent IDs, or any required permissions. This is a significant gap for a 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 a single, concise sentence that front-loads the essential information. There is no redundancy or wasted text, making it easy to parse quickly.

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 destructive nature and lack of annotations, the description is insufficiently complete. It fails to address return values, error behavior, or how it differs from the sibling clear_namespace. The agent receives the minimum viable information but lacks critical context for safe and correct invocation.

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 parameter 'id' with a description of 'Memory ID'. The description's phrase 'by ID' adds no new semantic information beyond what the schema already provides, so the baseline score of 3 for high schema coverage 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 'Delete a specific memory by ID' clearly states the verb (delete), the resource (memory), and the scope (specific, by ID). This distinguishes it from sibling tools like get_memory, store_memory, search_memories, and clear_namespace, which handle different operations.

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 implies usage when you have a specific memory ID to delete, but provides no explicit guidance on when to use this tool versus alternatives such as clear_namespace. There is no mention of exclusions or prerequisites, leaving the agent to infer the appropriate 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation via 'retrieve' but does not disclose potential error behavior, return format, or what happens if the ID is not found. This is minimal transparency beyond the verb itself.

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, front-loaded sentence with no unnecessary words. It is appropriately sized for the simplicity of the tool.

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?

The tool has only one parameter and no output schema or annotations, so the description must provide sufficient context. It states the action but omits expected return values, error handling, or any details about the memory resource itself. An agent lacks enough information to fully anticipate the tool's behavior.

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 describes the only parameter ('id' with 'Memory ID'), so schema coverage is 100%. The description adds no additional meaning beyond what the schema already provides, warranting the baseline score of 3.

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 a specific verb ('retrieve') and resource ('a specific memory by ID'), and this is distinct from siblings like search_memories, delete_memory, and store_memory. It precisely communicates the tool's function.

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 implies the tool should be used when a specific memory ID is known, but it provides no explicit guidance on when to choose this over search_memories or other alternatives. There is no mention of contexts, prerequisites, or exclusions.

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?

No annotations are provided, so the description must fully disclose behavioral characteristics. It only states what the tool does (searches) but does not explicitly state that it is a read-only operation, what it returns (e.g., matching memories), or any details about ordering, pagination, or error behavior. The absence of this information leaves significant room for interpretation.

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, front-loaded sentence that states the verb, resource, and key parameters. It contains no redundant information and is immediately scannable, earning maximum conciseness.

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 search tool with three well-documented parameters and no output schema, the description provides the essential context (search by namespace, optional text query). While it lacks some behavioral details like return format, the schema covers parameter semantics, making it adequately complete for this straightforward tool. The lack of an output schema means some return-value explanation would be helpful, but it is not critical.

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 provides complete descriptions for all three parameters (namespace, q, limit) with 100% coverage. The description adds minimal semantic value beyond the schema, only referring to 'optional text query' which matches the 'q' parameter description. Since the schema already does the heavy lifting, a baseline score 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 identifies the action ('Search') and the target resource ('memories'), and specifies the key scoping attribute ('by namespace') and the optional filter ('text query'). This clearly differentiates it from sibling tools like clear_namespace, delete_memory, get_memory, and store_memory, which perform different operations on memories.

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 implies usage for searching within a specific namespace, but it does not provide explicit guidance on when to choose this tool over alternatives like get_memory (which likely retrieves a single memory by ID). There is no mention of when not to use it or a named alternative, so it only provides minimal implied 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?

With no annotations, the description must disclose behavioral traits. It only states that the memory 'persists across sessions,' but does not mention whether it overwrites existing memories, how it interacts with namespaces, or what the return value is. This is insufficient for a mutation tool.

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 extremely concise — two short sentences — and front-loads the primary action. Every word adds value, with 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?

The tool has four parameters including nested objects and no output schema. The description is minimal and fails to explain what happens after storing, return values, or any side effects. For a mutation tool with zero annotations, this is incomplete.

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 schema already documents all four parameters. The description adds no extra meaning beyond what the schema provides, thus 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 the operation: 'Store a memory for an AI agent' with a specific verb and resource. It also adds durability context ('Persists across sessions') and indirectly distinguishes from sibling tools like delete_memory, get_memory, and search_memories.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention that this is for creating new memories, nor any exclusions or prerequisites. The sibling tools exist but are never referenced.

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