memory_propose

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

No annotations exist, so the description bears the full behavioral burden. It does disclose a genuinely important trait — writes may not take effect but instead become a proposal awaiting user review, or be silently collapsed into an existing duplicate — but it omits irreversibility, permission needs, and what a caller gets back on each of the three paths.

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?

Three tight sentences with the core claim front-loaded and the three outcomes packed into one line. The final sentence is a useful pointer rather than filler, though it is doing work the definition itself should do.

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?

The tool is conceptually simple from the caller's view and an output schema exists, so return values need not be explained. Still, a mutation tool whose sole required parameter has zero schema coverage leaves the agent unable to construct a valid call without fetching external instructions.

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% and the ops array items are untyped objects with additionalProperties, so the schema conveys almost nothing. The description does not compensate: it only says "see the server instructions for the op formats," which pushes the critical information outside the definition, and the reason parameter is never mentioned.

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 only way to change memory" states the resource and its role as the sole mutation entry point, and the three-way outcome (apply, merge as duplicate, pending proposal) tells an agent what the tool actually produces. It falls short of 5 because it never says what an "op" is, so the concrete operation being performed stays abstract.

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?

"The only way to change memory" implicitly routes all memory writes here and no alternative is named or needed among the read-oriented siblings. However, there is no when-not guidance, no statement of prerequisites or approval implications that should shape the decision to call it.

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