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

The description asserts '(READ-ONLY: mutations refused)' while the annotations declare readOnlyHint=false for a tool whose entire purpose is writing memories. This directly misleads the agent about the tool's side effects. The otherwise useful notes ('returns real counts', 'refuses malformed input') are eclipsed by the contradiction.

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?

A single dense sentence that front-loads the accepted input forms, which is good. But the trailing parenthetical is both misleading and costs space that could have carried the dry-run default, so the sentence does not fully earn its length.

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?

Eight optional parameters, no output schema, and no annotations the agent can rely on given the contradiction. Most importantly, the description omits that dry_run defaults to true, meaning a naive call may write nothing – a critical fact for correct invocation that the schema states only tersely.

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 baselines at 3. The description does usefully group the four input variants (items / items_jsonl / text / source) into one sentence, but adds nothing about the behaviorally decisive parameters: dry_run defaulting to true and redact defaulting to true.

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 names a specific operation (batch ingest into memory) and enumerates the accepted input forms (items / items_jsonl / text inline, or source file) routed via the batch-create path. It is distinguishable from memory.create only obliquely, via 'batch-create path'; it never names a sibling.

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?

There is no statement of when to choose this over memory.create, memory.update, memory.batch_read or the search tools. The batch-vs-single distinction with memory.create is only hinted at by the phrase 'batch-create path', leaving the agent to infer the selection rule.

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