edit_memory

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

With no annotations provided, the description carries the full burden and does well: it discloses that changes are update commits, history is preserved, content edits re-derive summaries and auto-tags, and knowledge-graph links are included in the same commit. This gives a rich picture of side effects without requiring the user to infer them from schema or 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 long, front-loaded with the primary action, and each clause adds critical information: commit behavior, history preservation, summary/tag re-derivation, and KG links. No wasted words.

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 params, no annotations) but with an output schema present, the description covers the key non-obvious aspects: safety (never overwrites history), side effects (re-derives summary, auto-tags), and the relationship to memory_history. This is sufficient for an agent to correctly invoke the tool and understand its behavioral footprint.

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 the baseline is 3, but the description adds meaningful context beyond the schema: it explains that content edits trigger summary re-derivation and auto-tag merging, and that new knowledge-graph links ride in the same commit. This enriches the semantic understanding of the 'content' and 'tags' parameters beyond their simple 'New content' and 'Replacement tag list' descriptions.

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 action ('Edit a wiki page') and the resource (memory), and distinguishes itself by emphasizing the update-commit behavior and non-destructive nature, which differentiates it from sibling tools like memorize or forget_memory. It also mentions memory_history for revisions, reinforcing its specific role.

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 clear context: edits are committed and never overwrite history, and it points to memory_history for viewing revisions, which implicitly indicates when to use that alternative. However, it does not explicitly contrast with memorize/forget_memory or state explicit 'when to use' conditions beyond the basic action.

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