memory_assemble_context

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool retrieves rather than mutates, filters for 'high-salience', enforces a 'strict token-budget', and formats into XML. This is useful, though it doesn't explain how salience is determined or how failures/token-truncation are handled.

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 a single dense, front-loaded sentence with no filler. It names the primary action, the input type, the processing behavior, and the output format in an efficient structure.

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 covers the key output (XML prompt block) but leaves important gaps for a tool with five parameters and no annotations: the meaning of each `mode`, how `scope` is applied, the effect of `include_shared`, and expected behavior when the token budget is exceeded. The schema fills some gaps, but the description alone isn't fully complete for correct invocation.

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 80%, so the schema already documents most parameter meanings. The description adds some context around token budgeting and salience, but it doesn't elaborate on the `mode` enum, `scope` object, or `include_shared` flag beyond what the schema fields already say. This is adequate but not additive.

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 clearly states the action ('Retrieve and format') and resource ('high-salience memories'), and specifies the unique output format: 'strict token-budgeted XML prompt block ready for direct agent context injection.' It doesn't explicitly name sibling alternatives, but the XML formatting and context-injection purpose distinguish it from tools like memory_recall or memory_timeline.

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 intended use is implied: assemble memory context for direct agent injection. It does not name when to use this over alternatives, nor provide any when-not-to-use guidance. The phrase 'ready for direct agent context injection' gives some context, but an agent would need to infer the comparison with memory_recall.

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