memory_govern

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that actions are state-changing and gated on explicit user authorization, which is important safety-relevant context. But it doesn't detail what gets retired, merged, or changed, and it defers impact notes and confirmation semantics to the help action rather than providing them up front.

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 description is concise and front-loaded with the tool's governing purpose, then moves to the authorization guardrail and the help-first instruction. It contains no filler and each sentence contributes useful guidance. It could be slightly more structured, but it is appropriately sized.

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 description gives enough to know this is a governance tool and warns that authorization is required, but it deliberately defers exact actions, fields, impact notes, and confirmation semantics to a runtime help call. That is a reasonable pattern for a dispatcher-style tool, but it leaves an agent without full context until that help call is made.

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%, so the description must compensate. It only mentions action="help" and does not explain the data parameter or enumerate the accepted action values. The agent would have to call the tool with action="help" before it can meaningfully understand the parameters.

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 concrete governance operations: retire, merge near-duplicates, apply/replan/resolve conflicts, confirm, and manage workspaces. This is clear enough to identify the tool as the management/curation surface among siblings like memory_review and memory_repair. It lacks a single precise verb+resource phrasing, but it is not vague or tautological.

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 explicitly states a key precondition: every state-changing action requires explicit user authorization for that action, with authorized=true. It also directs the agent to call memory_govern(action="help") to learn exact actions and confirmation semantics. However, it does not discuss when to prefer this tool over memory_review or memory_repair, so sibling routing guidance is incomplete.

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