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

With no annotations, the description carries the full burden and does well: it discloses that as_kind=note writes to memory returning an [ev:id] and as_kind=cube only produces a draft rather than creating a cube, and it explicitly states "Does not run the advice." It omits whether unselected answers are discarded by "keep" and whether repeat calls are idempotent.

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, front-loaded with the core action and then the two mode behaviors. The key_value shorthand is dense but readable; a short gloss of what "synthesis" means would have helped.

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 three-parameter mutation with no annotations and no output schema, the description covers both modes' return shapes inline, which is the main gap filled. It still leaves the source of consult_id and the fate of the non-kept answers unstated, which matters for a tool whose name implies selection at the expense of others.

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 0%, so the description must compensate, and it does for two of three parameters: it supplies the allowed values for which and as_kind (neither of which is an enum in the schema) plus the side effect of each as_kind. Only consult_id is left unexplained beyond its name.

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?

"Keep one consult answer" gives a specific verb (persist) and resource (a consult answer), and the which=synthesis|claude|gpt enumeration makes clear it selects among candidate answers produced by a prior consult. It is distinguishable from siblings like consult or cube_create, though it never names the producing tool explicitly.

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 clause "to submit only after the advice proved itself" gives a real when-to-use condition for the as_kind=cube path, and "saves it to memory" distinguishes the note path. However, there is no explicit statement that consult must be called first, no when-not guidance, and the sibling consult is never named.

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