Propose a memory

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries the real burden and does: it discloses the asynchronous approval flow, that success means queued not stored, and that it cannot confirm its own writes. It does not contradict annotations — nothing written persists without human action.

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?

Four sentences, each doing distinct work: purpose, trigger, exclusion, and the queued-not-stored caveat. The most decision-critical fact (pending queue, no confirmed write) 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?

Covers the workflow, the async success semantics, and retry safety, which is exactly what an agent needs before calling. It lacks a note on what a rejection looks like or whether tag/vault choices affect routing to the human, a minor gap given no output schema exists.

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 baseline is 3. The description only reinforces client_id idempotency semantics, which the schema already explains in nearly identical terms; content, vault, and vector are untouched in the description.

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 (submit a memory for human approval) and resource, and immediately distinguishes the outcome from siblings: it lands in a pending queue and changes no confirmed memory. An agent can tell this apart from recall (read) and say (communication) without opening any 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?

Gives explicit positive triggers ('when the human says to remember something', 'a decision is reached that will still matter later') and explicit exclusions ('not a scratchpad for transient reasoning', 'not data you merely fetched'). The alternative/anti-pattern guidance is unusually complete for this category.

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