memory_context

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

With no annotations, the description must disclose behavioral traits. It does disclose a key constraint: 'Each returned memory fits wholly within the remaining budget; budgets must be greater than zero.' However, it does not state whether the operation is read-only, what happens on insufficient budget, how activation affects results, or any ordering/pagination behavior. The single disclosed constraint is useful but incomplete.

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 extremely concise—two sentences—with the primary purpose front-loaded. Every word adds value, and the token_budget constraint is clearly separated. No filler or redundancy.

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?

Given 4 parameters, no output schema, and no annotations, the description is incomplete. It omits meanings of limit, context, and strict_context, does not describe the output format or ordering, and gives no indication of safety or side effects. It also does not help the agent distinguish this tool from memory_recall. Significant gaps remain for correct invocation and interpretation.

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 should compensate. It explains token_budget semantics explicitly, but leaves limit, context, and strict_context unexplained. The mention of 'activation' in the first sentence does not map directly to any parameter, leaving most inputs ambiguous. The partial coverage of one parameter is insufficient for a 4-parameter tool with zero schema based documentation.

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 verbs and resource: 'Return a working-memory set' selected by activation and token budget. It distinguishes itself from siblings (memory_recall, memory_store) by focusing on a set selected by activation/budget, but does not explicitly contrast with them. The purpose is specific and actionable.

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?

No guidance is provided on when to use this tool versus alternatives like memory_recall or memory_store. The description explains what it does but not under what conditions an agent should choose it. There is no mention of exclusions, prerequisites, or typical use cases.

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