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

No annotations are provided, so the description carries the full burden. It does disclose useful traits: sub-1ms latency and the three possible verdicts ('avoid', 'safe', 'neutral'), implying a non-mutating check. It never states that it has no side effects, what happens with an empty/unpopulated memory, or how reliable the verdict is, which are meaningful gaps for a zero-annotation tool.

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?

Two tight sentences, front-loaded with the latency figure and the core action, then the return values. Every clause earns its place with no repetition.

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?

With no output schema, the description usefully enumerates return values, and the two parameters are simple and fully documented in the schema. But with no annotations, it still leaves behavior (side effects, behavior on empty memory, trust in the verdict) unexplained, so it is adequate rather than complete.

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 100% for both parameters (code and optional context), so the schema already does the work. The description adds no format or size hints beyond 'proposed code', so the baseline 3 applies.

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 gives a specific verb ('check') and resource ('associative memory of proposed code against past rewarded or punished bug patterns'), which is clearly distinct from the sibling write tool remember_code_outcome. It stops short of naming a sibling to route away from, so it is clear but not fully differentiated.

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?

Use is implied: you call this with proposed code to see whether past rewarded/punished patterns suggest avoid, safe, or neutral. However, there is no explicit when-to-use/when-not-to-use guidance and no routing against the overlapping query_associative_memory or remember_code_outcome siblings, which an agent would need to choose correctly.

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

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. The verb 'Returns' implies a non-mutating read, and the enumerated outputs give the agent a sense of the result shape, but nothing is said about cost, side effects, or state changes (contrasted with the sibling reset_memory, which clearly mutates).

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?

A single tight sentence that front-loads the return payload. No filler, no restatement of the tool name.

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?

With no parameters, no output schema, and no annotations, the description is the only source of information about results, and it names the three returned categories. It is nearly complete for such a simple tool, though the meaning of 'Mushroom Body' and 'synaptic weight distribution' remains domain jargon an agent may not resolve.

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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly reflects that this is a parameterless snapshot call, leaving nothing ambiguous on the input side.

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?

States a clear verb ('Returns') and enumerates the specific payload: total active memories, synaptic weight distribution, and health statistics. This distinguishes it from siblings like query_associative_memory and remember_code_outcome. It stops short of explicitly naming which sibling it replaces, so a 4 rather than 5.

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 statement of when this tool should be used versus check_code_reflex, query_associative_memory, or reset_memory. The diagnostic character of the tool is only inferable from the listed return values; there is no explicit triggering condition or exclusion.

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

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

With no annotations, the description carries the full behavioral burden. It implies a non-mutating read via 'Searches' and names a similarity metric, but says nothing about ranking semantics, result format, latency/scale limits, or empty-result behavior. Naming the algorithm is not the same as disclosing observable behavior.

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?

A single front-loaded sentence with no padding, which is appropriately sized for a two-parameter tool. It loses a point only because the algorithm name occupies space without informing the caller's decision.

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?

There is no output schema and no annotations, so the description is the only source of return-value information, yet it never says what a match looks like, how scores are represented, or that top_k bounds the result count. For a search tool returning ranked neighbors, that is a meaningful gap.

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 100% for both parameters, so the schema already documents query_code and top_k (including its default of 5). The description adds no parameter-level meaning beyond that, which is the baseline 3 when the schema does the work.

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?

States a specific verb ('Searches') and resource ('stored code patterns'), so an agent can tell it is a read/query tool distinct from write-oriented siblings like remember_code_outcome and reset_memory. The trailing 'Fly-LSH sparse binary Hamming similarity' is unexplained jargon that adds little recognition value, and it does not differentiate from the potentially overlapping check_code_reflex.

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?

There is no guidance on when to use this tool versus the four siblings, and no stated prerequisites or triggering conditions. The agent must infer from the name alone that this is the retrieval counterpart to remember_code_outcome.

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

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

No annotations are provided, so the description carries full burden. It discloses the one-shot nature and that it modifies synaptic weights (mutation), and maps success/failure to reward/punishment. But it omits whether this is irreversible, what happens on repeated calls, or any side effects beyond weight changes. For a mutation tool with no annotations, it adds some behavioral context but not enough to fully guide safe use.

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?

Single sentence, front-loaded with the core action, and no wasted words. Allowed use of parentheses is efficient and does not obscure meaning.

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 mutates memory with no output schema and no annotations, yet the description lacks crucial details: how the reward/punishment affects future behavior, whether it can be undone, and what the return value is. Given the complexity of synaptic weight updates and the absence of structured behavioral data, the description is insufficient for an agent to understand the full implications.

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 100%, so parameter meanings are fully documented in the schema. The description only clarifies the effect of outcome ('success' rewards, 'failure' punishes), which slightly reinforces the schema but adds little since the schema already states this. Baseline 3 is appropriate when schema does the heavy lifting.

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?

States a specific verb+resource: applies reward/punishment to Mushroom Body synaptic weights. It clearly describes the core action and distinguishes itself from siblings like query_associative_memory or inspect_memory_state. However, 'Mushroom Body' is jargon that may be opaque, and it doesn't explicitly say it remembers code outcomes, which is the tool's name. Still, the action is clear.

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?

Implies usage when a test passes or fails, but doesn't state when to call this vs. alternatives like check_code_reflex or query_associative_memory. No explicit when-not or prerequisites. The outcome parameter ties to tests, but the description does not guide the agent on timing relative to other memory tools.

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

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

With no annotations, the description carries the full burden and does not meet it. It implies destruction ('resets or prunes... back to baseline') but never states that existing memory is destroyed, whether the operation is reversible, or how a backup interacts with the reset, leaving the agent to infer the safety profile from the schema alone.

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?

A single tight sentence with the action front-loaded and no filler. It is efficient, though the mixed jargon 'synaptic weights' versus 'associative memory' is slightly redundant rather than clarifying.

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?

This is a destructive mutation tool with no annotations, no output schema, and no usage guidance. An agent cannot tell from the description what exactly is lost, whether the reset is reversible, or when this should be preferred over inspecting memory first.

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 100%, so both 'confirm' and 'backup' are already documented in the schema, which sets the baseline at 3. The description adds no syntax, default, or consequence detail beyond what the schema provides.

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?

States a concrete action on a concrete resource: resets/prunes synaptic weights and associative memory to baseline. The verb pair 'resets or prunes' is slightly hedged, and nothing distinguishes it from siblings like inspect_memory_state or query_associative_memory, so it stops short of a 5.

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?

There is no statement of when to reset versus inspect or query memory, no prerequisites, and no named alternative among the four sibling tools. The only usage signal is the required 'confirm' flag in the schema, which the description never explains.

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