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

Annotations already indicate the operation is read-write (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds the important behavioral constraint that type is immutable and suggests a workaround. It doesn't disclose whether unspecified fields are preserved or overwritten, but the minimal annotations keep the bar low.

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 with no filler: the first states the action and targets, the second explains an immutable property and its workaround. Every sentence contributes essential information, and the key constraint 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?

The definition is compact but sufficient for a straightforward update operation. The schema covers parameter meanings, the output schema covers return values, and the description covers the one non-obvious rule (type immutability). The only minor gap is not explicitly stating that partial updates preserve omitted fields, but this is not critical given the other structured information.

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%, with each parameter already documented (id from prior recall_memory result, name kebab-case slug, content body, description summary). The description's reference to 'name, description, or content' restates the schema without adding further semantic nuance, so the baseline 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 clearly states the verb 'Update' and the resource 'existing memory', and lists the mutable fields (name, description, content). It also explicitly notes that type is immutable, which distinguishes it from reclassifying 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 implicitly defines when to use this tool (updating an existing memory) and explicitly provides an exclusion: if you need to change the type, 'forget and store again'. It doesn't explicitly name store_memory as the alternative for new memories, but the phrase 'existing memory' makes that clear enough.

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