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

With no annotations, the description carries the full load and does well: it discloses atomicity ('all or nothing'), hard size limits (300 chars/line, 4000 total), the forced merge/remove behavior when full, and prefix-matching semantics for edits and removals. It stops short of stating what the response looks like or whether removed facts are recoverable.

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?

Front-loads the purpose and atomicity, then usage rules, then hard constraints, then examples — well ordered. It is wordy in places (the parenthetical 'Always send…' contrast is helpful, but the guidance portion is dense prose that could be tightened).

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?

No output schema and no annotations, so the description must define the whole contract for a single nested-array operation parameter, and it covers ops, limits, matching, and exclusions. The unmentioned `section` field and the absence of any statement about the return value are the remaining gaps.

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 0%, so the description must compensate and largely does: it explains add/patch/remove intent, one-fact-per-line, line length limits, and that an edited/removed line is matched by a fragment ('A line you change or remove is matched by a part of it'), which is the key semantic for the `old` field. It never mentions the `section` property or what values it accepts, leaving one gap.

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?

States a specific verb and resource ('Change what Caddie knows about the user') plus the critical scope detail 'line by line, all or nothing' (atomic mutation). This clearly separates it from the read-side sibling memory_read without either schema being opened.

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?

Explicitly defines when to use ('facts that will still matter in a month') and when not to ('Don't save task progress, one-off details, what you did today'), naming the alternatives for each: search_runs for activity, a skill for procedures. Routing guidance is unambiguous.

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