Remember a correction the user gave

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

With no annotations present the description carries the full burden, and it does: persistence is disclosed ('kept in a local journal on this machine'), the downstream effect is spelled out ('every later design_brief applies it'), and the propagation mechanism is separated by type (image corrections become prompt instructions, text/logo corrections become compositing_rules). The brand-leakage warning ('so it never leaks into another brand's work') is exactly the kind of cross-call side effect an agent cannot infer from the 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?

The trigger is front-loaded in the first sentence, followed by persistence, propagation, scoping, actions and the file flag — a sensible order with no filler. It is dense to the point of being a single run-on block, which costs a little scanability but wastes no sentences.

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 an 8-parameter, annotation-free, no-output-schema tool this covers the essentials: when to call, what is stored, how it is later applied, how to scope it, and how to inspect or delete entries. It falls short only on asset_type and the applies_to override, and on what a 'list' entry actually looks like — the latter matters because 'time' must come from that listing to forget an entry.

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 75%, but the description still adds meaning beyond it: brand scoping is explained with a concrete example and the note that it matches brand.name in design_brief, and 'Pass file to mark that draft rejected' clarifies the add-mode effect of that parameter. However, applies_to and asset_type — two parameters that shape how the correction is applied — are never mentioned in the description, leaving the agent to rely on schema text alone for them.

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?

It states a specific action (record/correct) and resource (user feedback/journal entries) and ties it to a concrete trigger: 'When the user says something about a result was wrong ... call this right away with what was wrong and what they want instead.' The distinction from design_brief is made explicit through the propagation rule, so an agent can tell the two apart without opening either schema.

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 gives an explicit when-to-use trigger (a correction about colour, crop, empty band, text, wrong logo), a when-to-scope rule ('Set brand when the correction is about one brand'), and per-action guidance (list shows stored entries, forget removes one by time, file marks a rejected draft). Nothing about the mode selection is left to inference.

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