Say what a document is about

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

With no annotations, the description carries the full burden and largely does: it discloses that the value is local-only and never syncs, that it is not part of the document, and that the person does not see it — non-obvious traits an agent cannot infer elsewhere. It also explains the staleness mechanic: stored against the current text, so a later write marks it as describing an older version.

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?

It is front-loaded with the purpose, but the prose is long and meandering for a three-parameter store operation, with several repeated cautions (not part of the document / person does not see it / read it first). The value is there, but the sentences are not maximally economical.

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 local write with no annotations and no output schema, the description covers what the data is, where it lives, who can see it, when it goes stale, and how to write it. No return-value description is needed since there is no output schema, and the only minor gap is whether an existing summary is overwritten or merged.

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 schema already defines `doc`, `summary`, and `notes`. The description reinforces the distinction between summary and notes and the fact that `doc` must be the id not the title, but adds no syntax or format beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.

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 states a specific act — recording what you worked out about a document so it need not be re-read — and distinguishes the two payloads: `summary` for what it says, `notes` for what someone working with it should know. It is clear enough to separate from `note`, `reword_note`, or `describe`, though the verb is metaphorical ("leave what you worked out") rather than a direct "store a summary on a document", which costs it a point.

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 explicit when/when-not: "write it after reading a long document, never instead of reading one", plus a content rule (write what it says, not what you'd like it to say). That is real routing guidance. It stops short of naming siblings, so it doesn't reach the top score.

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