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

No annotations are provided, so the description must fully disclose behavioral traits, but it does not. 'IRB Neural Welfare Check' only vaguely suggests a read-only assessment; it does not state side effects, permissions, failure modes, or output 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?

The description is extremely short, but this is under-specification rather than effective conciseness. There is no structure, no verb, and no explanatory content beyond a label-like phrase.

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 and no annotations, the description needed to explain what the check returns and how it relates to sibling tools. Instead it leaves the agent guessing what 'IRB Neural Welfare Check' means in practice, making selection and invocation unreliable.

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 has zero parameters and the schema coverage is 100%, so there is nothing to document. The description adds no parameter semantics, but none are needed. The baseline 4 for zero-parameter tools 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 is a noun phrase, 'IRB Neural Welfare Check,' rather than a sentence with a verb and object. It hints at an ethics/welfare inspection but does not clearly say what the tool does or returns. The name itself already contains 'check,' so the description mostly restates the tool's name in different words.

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 about when to use this tool versus the many sibling status/check tools such as get_system_status, get_acm_score, or get_snn_state. No conditions, prerequisites, or alternatives are mentioned.

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 at all, the description must disclose side effects, output behavior, and access requirements, but 'Full State Snapshot' says nothing about whether the operation is read-only, what format is returned, whether data is persisted, or whether it requires special privileges. This is a total gap in behavior disclosure for a no-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?

The description is extremely short, but this is under-specification rather than conciseness. It is a single noun phrase with no structure and no breakdown of behavior, output, or use cases. It does not earn its place because it conveys almost no useful information beyond 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?

Given the absence of annotations, output schema, and parameter info, the description carries the whole burden of explaining the tool. 'Full State Snapshot' leaves the agent completely without context on what state is included, what the output looks like, how it differs from sibling state/status tools, or whether it is safe to call. The definition is inadequate for reliable selection and 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?

The tool has zero parameters, and the input schema shows an empty properties object. Since there are no parameters to document, the description does not need to add parameter semantics; the baseline of 4 applies. The description adds no param detail, but none is required.

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 'Full State Snapshot' is a noun phrase echoing the tool name 'export_snapshot' with no verb, leaving unclear whether the tool exports, returns, or saves a snapshot. It does not differentiate itself from siblings like get_snn_state, get_system_status, or wm_status, all of which could plausibly provide state-related information. This is closer to a tautology than a functional description.

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 usage context is provided. The description offers no guidance on when to call export_snapshot versus alternatives such as get_snn_state, get_system_status, or get_platform_status. The agent is given no basis for deciding between overlapping sibling 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the tool is read-only, what kind of score it returns, how the proxy is computed, whether there are side effects, or what the response contains. 'Consciousness Assessment (Proxy)' is a label rather than a behavioral disclosure.

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 short and front-loaded, but this is under-specification rather than effective conciseness. It reads as a title or label rather than a usable tool description, and the parenthetical 'Proxy' is the only substantive hint.

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 no annotations, no output schema, and a nontrivial domain of sibling tools, the description is far too incomplete. An agent cannot determine what ACM means, what the proxy is based on, what value will be returned, or how this differs from related assessment and status tools.

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 has zero parameters and the schema is empty, so there are no parameter semantics for the description to clarify. The baseline for a zero-parameter tool is appropriate here; the description adds no parameter information but none is needed.

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 the resource ('Consciousness Assessment') and adds the qualifier 'Proxy,' which suggests an indirect measure. However, it lacks a verb and does not explain what ACM stands for or what the proxy actually represents, leaving the purpose somewhat vague and not clearly differentiated from sibling tools like get_system_status or get_metrics.

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 alternatives. The description does not mention any context, prerequisites, or exclusions, and the 'Proxy' hint is too underspecified to count as usable usage direction.

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 full responsibility for disclosing behavior. It hints at a real-time read operation, but does not state whether the tool is read-only, what side effects it might have, how data is scoped, or what 'metrics' refers to.

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 only two words long and is under-specified rather than efficiently complete. It contains no verb, no object, and no supplementary detail, so it does not earn credit for conciseness.

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?

A zero-parameter tool still needs context about what it returns and how it differs from at least the most similar siblings. There is no output schema and no clarification of what counts as 'metrics,' making the description inadequate for reliable tool selection.

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 has zero parameters, so there is nothing for the description to clarify. The empty input schema covers all parameter semantics by construction, earning the baseline score of 4.

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 'Real-time Metrics' is a noun phrase rather than a statement of what the tool does. It restates the tool name ('metrics') with the modifier 'real-time,' but never specifies a verb or resource, and it does nothing to distinguish get_metrics from sibling tools like get_system_status or get_platform_status.

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 get_metrics versus any of the many sibling getter tools. The phrase 'Real-time' weakly implies current data, but no context, exclusions, or alternative conditions are provided.

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 provided, the description carries the full burden of disclosing behavior, and it discloses nothing beyond the phrase 'Bio-Computing Platforms'. It does not indicate whether this is a read-only status check, what output to expect, or whether any side effects occur.

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 short but under-specified; the phrase 'Bio-Computing Platforms' does not earn its place because it conveys no actionable information. This is not effective conciseness but rather a lack of content.

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?

Even for a zero-parameter tool, the description is incomplete: it fails to state the tool's purpose, behavior, output, or relationship to sibling status tools. An agent cannot reliably decide when to call this tool based on the provided definition.

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 input schema has zero parameters and 100% schema coverage, so no parameter descriptions are necessary. The description adds no parameter semantics, but there is no parameter gap to compensate for.

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 'Bio-Computing Platforms' is a noun phrase with no verb or explicit action, so it does not state what the tool does. The agent must infer 'get status' entirely from the tool name. It also provides no differentiation from status-related siblings like get_system_status or wm_status.

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 about when to use this tool versus alternatives such as get_system_status, get_metrics, or wm_status. The description gives no context, prerequisites, or exclusions that would help an agent 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 burden of disclosing behavior. 'SNN Engine State' reveals nothing about whether the call is read-only, what state information is returned, or any side effects.

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 brief, but brevity here is under-specification rather than effective conciseness. It lacks a verb, purpose statement, or any structural elements that would help an agent act on it.

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 and no annotations, the description should explain what 'SNN Engine State' actually contains and when the tool is useful. It does neither, leaving an agent without enough context to call it correctly or interpret its result.

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 has zero parameters and the schema coverage is 100%. With no parameters to document, the description does not need to add parameter-level detail, earning the baseline score of 4.

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 is a noun phrase, 'SNN Engine State', that essentially restates the tool name without a verb. It does not clearly state what the tool does or how it differs from sibling status tools like get_system_status or wm_status.

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 call this tool versus alternatives. Among many sibling status/state tools, no context is provided to help an agent select this specific tool.

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 of disclosing behavior, but it only names the resource. It does not state whether the call is read-only, what kinds of status data are returned, whether any side effects occur, or whether authentication or system state dependencies exist.

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 short, but it is under-specified rather than efficiently concise. It contains no predicate, no operational detail, and no information that would help an agent invoke the tool correctly.

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?

Although the zero-parameter schema keeps the call simple, the absence of an output schema, annotations, and behavioral context leaves an agent uncertain about the return format and the distinction from overlapping system-status tools. The single phrase does not provide a complete picture.

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 input schema has zero parameters and 100% schema description coverage, so there are no parameter semantics to clarify. The description does not add anything, but no parameter explanation is needed.

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 'ASTRA System Status' is a noun phrase that essentially restates the tool name 'get_system_status' with the product prefix, rather than stating a specific action and resource. It does not differentiate the tool from the sibling 'get_platform_status', which appears to overlap in purpose.

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 about when to use this tool instead of siblings such as get_platform_status, get_metrics, or get_snn_state. There is no context about typical scenarios, prerequisites, or exclusions.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It does not state that this operation modifies the network state, whether the effect is reversible, whether it requires a running simulation, or what side effects it may have. The description only names the operation without describing any 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?

The description is extremely short, but this is under-specification rather than conciseness. A concise description would use few words while packing meaningful information; this one simply restates the tool name. No useful content is front-loaded because there is no content.

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 tool that presumably manipulates a neural simulation, the description is far too minimal. It lacks any indication of effect, required state, parameters, or relationship to the surrounding toolset. With no output schema and no annotations, a two-word description leaves the agent without enough context to invoke the tool correctly.

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%, and the description adds no meaning to the parameters. It does not explain what neuronIds refers to, what strength controls, how strength interacts with neuronIds, or what typical usage looks like. The raw schema provides types and ranges, but the description contributes nothing to parameter understanding.

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 'Spike Injection' is a noun phrase that simply restates the tool name without a verb or resource. It does not explain what the tool does, what 'spikes' are injected into, or what the outcome is. This is a tautology that fails to distinguish the tool from its siblings.

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 description gives no indication of when to use this tool versus any of the many sibling tools such as snn_step, set_parameter, or simulation_control. There is no mention of contexts, prerequisites, or exclusions. An agent has no guidance on when inject_spikes is the appropriate choice.

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 must fully disclose behavior, but it only hints at the output ('descriptor + viability'). It does not state whether the operation is read-only or has side effects, nor does it mention permissions, rate limits, or failure modes.

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 short, but it is under-specified rather than concise. It reads as a fragment and omits essential information such as the action performed, making it less useful despite its brevity.

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?

Without an output schema, the description should explain what 'descriptor + viability' means in return terms, but it does not. It also fails to clarify whether this is a capture or retrieval operation, leaving major gaps in understanding the tool's purpose and behavior.

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 100% for the single parameter 'mea', which is fully described with constraints and default. The tool description adds no additional parameter meaning, but the schema already handles it, so baseline 3 is appropriate.

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 lacks a clear verb; 'Last MEA camera capture' is a noun phrase, so it's unclear whether the tool performs a capture or retrieves the last capture. It mentions the resource (MEA camera) and output (descriptor + viability), but does not explicitly state the action or distinguish from sibling tools like sensor_visual.

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. There is no mention of prerequisites, use cases, or exclusions, leaving the agent without context for selecting it appropriately.

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 present, so the description must disclose side effects and safety. It mentions optional SNN driving and ethics coupling, which hint at state changes, but does not explain whether the operation is read-only, modifies the organoid/SNN state, or what side effects occur.

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 sentence, front-loaded with the platform name and core concept. Every word contributes; no filler.

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 is moderately complex with 4 parameters and no output schema, yet the description provides only a high-level pipeline. It doesn't explain expected return values, invocation behavior, or how parameters affect the closed loop, leaving the agent under-informed.

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 schema covers 75% of parameters with descriptions. The description rarely references the parameters: 'optionally drive the SNN' corresponds to drive_snn, but window_ms and drive_strength are not addressed. The description adds minimal value beyond the schema.

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 identifies a closed-loop coupling action ('read organoid → couple to ASTRA fusion/ROS/ethics, optionally drive the SNN') but lacks an explicit verb naming the operation (e.g., 'run', 'trigger', 'configure'), making it ambiguous what invoking the tool does. It partially differentiates from siblings by mentioning ASTRA/ROS/ethics, but the purpose remains vague.

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 np_send_trigger or inject_spikes. The description implies a closed-loop use case but does not state conditions, exclusions, or alternatives.

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 of behavioral disclosure, but it only says 'Define, validate & upload.' It does not mention side effects on hardware, permission requirements, reversibility, error behavior, or confirmation of successful upload, so the agent is left guessing about what actually happens.

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 sentence that is concise, front-loaded with the action, and contains the key domain context. There is no wasted text.

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?

Despite a rich schema, the description is too sparse for an 11-parameter hardware-upload tool with no annotations and no output schema. It does not describe what the tool returns, how uploads are confirmed, failure modes, or prerequisites, so the agent would lack essential context for reliable 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 82%, so the parameters are mostly self-documenting with units, defaults, and ranges. The description adds the context of 'charge-balanced biphasic stimulation' but does not elaborate on how parameters interact or what 'validate' means for the charge-balance constraint.

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 uses a specific verb set ('Define, validate & upload') and names a concrete resource ('StimParam (charge-balanced biphasic stimulation)'), clearly distinguishing this hardware-configuration tool from siblings like np_send_trigger or np_count_spikes.

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, no prerequisites, and no exclusions. The description implies an upload/configuration action but does not explain when an agent should choose it over related np_* 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 must disclose behavior (e.g., read-only, side effects, required permissions). It only says 'Closed-loop', which is vague and does not clarify whether the operation is safe or part of an active control loop. No behavioral traits are explained.

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 sentence and does not waste words. It is front-loaded with the tool name and purpose, though the phrasing is somewhat awkward.

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 has only two parameters and no output schema, so the description does not need to be lengthy. However, it lacks context about the meaning of 'closed-loop' and does not explain what the tool returns (e.g., a list of electrode counts). This leaves gaps for a non-expert agent.

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 100% with both 'top_k' and 'window_ms' having descriptions. The description adds no additional meaning beyond the schema, so the baseline of 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 clearly indicates a spike-counting function over a time window ('spikes per electrode over an N-ms window'). However, it does not explicitly differentiate from the similar sibling tool 'np_query_spike_count', and the phrase 'Closed-loop _count_spike' is somewhat cryptic.

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 about when to use this tool versus alternatives such as 'np_query_spike_count' or 'np_query_spike_events'. There is no mention of conditions, prerequisites, or exclusions.

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 must carry the full burden of behavioral disclosure. It mentions 'NeuroPlatform v2 DB' and 'query', implying a read-only database operation, but it does not explicitly confirm read-only behavior, side effects, output format, or performance characteristics. Minimal contextual information beyond the tool's existence.

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 sentence with no filler. It immediately conveys the tool's purpose, data source, and key output metric, using a clear front-loaded 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 tool is simple and has no output schema. The description communicates the core output concept (spikes/minute per electrode) but omits details about the exact return structure, defaults, or how window_sec and nonzero_only affect the response. It is adequate for a basic query tool but leaves room for 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 descriptions cover fsname and window_sec, while nonzero_only lacks a description. The tool description's phrase 'over a time window' adds context to window_sec, but it does not explain nonzero_only or add meaning to fsname beyond the schema. With 67% schema coverage, the description only partially compensates for the missing parameter explanation.

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 defines the tool as a 'SpikeCountQuery' returning 'spikes/minute per electrode over a time window', clearly identifying the resource (spike counts per electrode) and the computation. However, it lacks an explicit verb like 'queries' or 'returns', and while it differentiates from event-based tools such as np_query_spike_events, it does not clearly distinguish from the similarly named np_count_spikes.

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 usage guidance is provided. The description does not state when to use this tool instead of siblings like np_query_spike_events or np_count_spikes, nor does it mention prerequisites, limitations, or alternative scenarios.

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 burden of behavioral disclosure. It only states that the tool returns spike timings over a window, but does not explain whether the window is relative to current time, how limit affects results, or what fsname refers to. This lacks the detail needed to anticipate tool 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?

The description is a single sentence with no fluff, making it concise and front-loaded with the core concept. It is not overly verbose, but it could be slightly more structured by explicitly naming parameters or the action. Still, it earns a high score for conciseness.

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 tool with 3 parameters, no output schema, and no annotations, the description is too brief. It does not describe the return format, the meaning of the parameters beyond 'window', or any edge cases or limitations. The tool may be simple, but the description lacks essential context for reliable use.

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 only 33% (only window_sec has a schema description). The description adds minimal context by mentioning 'over a window,' which aligns with window_sec, but it says nothing about limit or fsname. Thus, it does not sufficiently compensate for the low schema coverage.

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 tool returns 'individual spike timings over a window,' which identifies the resource (spike events) and distinguishes it from sibling count tools like np_count_spikes and np_query_spike_count. However, the verb is implied by the tool name ('query') rather than explicitly stated, and there's no explicit differentiation from other spike-related queries.

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 description provides no guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or comparisons to siblings such as np_query_spike_count, np_count_spikes, or np_query_triggers, leaving the agent without direction for tool selection.

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 of disclosing behavior. It does not state whether the operation is read-only, what the return format is, or whether there are side effects. It only labels the query without adding context beyond the schema's window and dedup parameters.

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 brief and front-loaded, with no filler or redundant content. It sacrifices behavioral detail for brevity, but as a one-phrase description it is efficiently structured.

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 lacks an output schema and provides no usage context, leaving gaps about response contents and differentiation from sibling tools. The parameter schema is strong, but the description alone is incomplete for an agent deciding whether to call this tool.

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 100% with both parameters (dedup and window_sec) having clear descriptions, so the description adds no extra parameter semantics. Baseline 3 is appropriate since the schema handles parameter 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 identifies the tool as a query for triggers sent to an organoid over a window, distinguishing it from trigger-sending tools like np_send_trigger. However, it lacks an explicit verb (e.g., 'Lists' or 'Retrieves'), relying on the noun phrase 'TriggersQuery'.

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 np_query_spike_events or np_query_spike_count. The description does not mention use cases, prerequisites, or exclusions.

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 full responsibility for behavioral disclosure. It does not explain side effects, safety, reversibility, permissions, or what happens when triggers are fired (e.g., hardware activation). This is a significant gap for a tool that likely has physical or system-level consequences.

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 sentence and concise, but it uses jargon ('NeuroPlatform v2', 'StimParams', '16-bit trigger array') that might reduce clarity. It is not verbose, and every word adds some information, though the structure could be improved by separating context from action.

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 has a simple schema but no output schema and no annotations. The description is insufficient for an agent to understand the full context: it lacks return behavior, side effects, prerequisites, and integration with sibling tools. For a trigger-sending tool, this is a notable 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?

The schema description covers 100% of parameters with clear descriptions for 'repeats' and 'triggers'. The description adds the context of 'uploaded StimParams' and '16-bit trigger array', which gives some extra meaning, but the schema already provides sufficient parameter documentation. Baseline 3 is appropriate.

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 tool fires triggers and executes uploaded StimParams via a 16-bit trigger array, using specific verbs like 'fire' and 'execute'. While it doesn't explicitly distinguish from siblings, the purpose is understandable, though the meaning of 'execute uploaded StimParams' could be clearer for an agent.

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 alternatives like np_configure_stim or np_query_triggers. It does not mention prerequisites (e.g., StimParams must be uploaded first) or when not to use it. The context is implied but not stated.

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 must carry the burden of disclosing behavior. The word 'Status' weakly implies a read-only operation, but the description does not explicitly state that it returns information, what information it provides, or whether any side effects exist. It adds very little beyond the tool's name.

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 short, but this is under-specification rather than effective conciseness. A single noun phrase without a verb or context does not earn its place; it reads like a title, not a functional description. There is no structure that helps an agent understand the tool's purpose.

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 the presence of numerous sibling status tools, the description is not complete enough to disambiguate. It fails to explain what 'Platform & Controller' encompasses, what output to expect, or how this differs from get_system_status, get_platform_status, or other status tools. The lack of annotations and output schema makes this minimal description insufficient.

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 has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and there is no schema information to supplement. It cannot add value beyond the empty schema, so the baseline score holds.

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 is a noun phrase ('Platform & Controller Status') rather than a clear verb-action statement. It implies the tool reports status but does not explicitly state what it does (e.g., 'Retrieves current platform and controller status'). It also does not distinguish this from several sibling status tools like get_system_status, get_platform_status, or ovo_status.

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 or how it differs from alternatives. With several status-related siblings, the description should mention that this is the go-to for platform/controller health or clarify its scope, but it omits any such context.

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 present, the description carries the burden of behavioral disclosure. It does reveal the transformation stages (Waveform → Mel → Latent), which is useful, but it does not disclose whether audio capture is real or simulated, whether the operation has side effects, whether it requires a microphone, or what the returned latent representation looks like.

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 and front-loads the core purpose and pipeline with no filler. It is more of a title than a full explanatory sentence, but every element earns its place and there is no 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?

For a tool with a nested input object, no output schema, and no annotations, the description is too thin to be fully actionable. It explains the processing pipeline but omits critical context such as expected output format, capture behavior, simulation behavior, and relationship to sibling sensor or encoding tools.

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 input schema is well-structured with defaults, ranges, and descriptions for some parameters, so the schema carries most of the parameter semantics. The tool description does not add any explanation of how parameters like source, channels, durationMs, or sampleRate affect the encoding, but the high schema coverage keeps this at the baseline score.

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 identifies a specific operation (A-JEPA audio encoding) and a clear processing pipeline from waveform to mel to latent. It clearly marks this as the audio sensor tool among siblings such as sensor_visual and sensor_olfactory, though it does not explicitly state what the encoded latent is used for.

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 description gives no explicit guidance on when to use this tool versus alternatives like sensor_fuse, sensor_process, or wm_encode. Usage is only implied by the tool name and the phrase 'Audio Encoding', with no conditions, exclusions, or references to other 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. 'Cross-Modal Attention Fusion' offers only a conceptual hint and does not state whether the operation is read-only, mutates state, depends on prior sensor data, or returns a result. This is insufficient for an agent to anticipate side effects.

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 only three words and technically concise, but it is under-specified rather than efficiently informative. It reads as a title, not as a tool description, and every necessary behavioral or semantic detail is absent.

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 annotations, no output schema, and no parameter explanation, the description leaves almost everything unspecified. An agent cannot tell what inputs to supply for a desired behavior, what the tool returns, or what effects it has on the system. The definition is not actionable.

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%, and the description never mentions includeAudio, includeVisual, or includeOlfactory. It adds no meaning about how these booleans affect fusion, such as modality selection, weighting, or output shape. The description completely fails to compensate for the absence of parameter 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 'Cross-Modal Attention Fusion' is a noun phrase rather than a clear verb-resource statement. It mostly restates the tool name and adds the vague qualifier 'attention,' leaving unclear what action the tool performs or what outcome it produces. It does not meaningfully distinguish sensor_fuse from sibling tools like sensor_process or sensor_visual.

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 about when to use sensor_fuse versus alternatives such as sensor_process, sensor_visual, sensor_audio, or sensor_olfactory. No use case, prerequisites, or exclusions are described, so an agent cannot determine the appropriate invocation context.

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?

There are no annotations, so the description carries the full burden. It only states a conceptual pipeline ('Chemoreceptor → Latent'), with no mention of side effects, return value, simulation state changes, or requirements such as a running platform. This is too opaque to predict tool 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?

The description is extremely short, which is good for speed, but it is under-specified rather than concise. It omits core behavioral information that a few extra sentences could safely supply, so brevity costs clarity.

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 tool with a nested input object, no output schema, and zero annotations, the one-phrase description leaves almost everything unknown: input semantics, output shape, and operational side effects. It is inadequate for an agent to decide whether and how to invoke this tool correctly.

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 100% and all subparameters have explicit types, defaults, enums, and ranges, so the baseline is 3. The description adds only the general chemoreceptor→latent framing and does not explain how individual parameters affect the encoding, but compensation is not required given full schema coverage.

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 a specific capability (olfactory encoding via Koniku Kore, chemoreceptor → latent) and therefore distinguishes itself from the visual/audio/fuse/process/status siblings. However, it is a noun-phrase title rather than a verb+resource sentence, so it does not explicitly state what action the tool performs or what it returns.

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 sentence explains when to use this tool versus sibling sensor tools. It implies olfactory use through the word 'olfactory', but offers no exclusions, prerequisites, or alternative routing. The agent must infer usage from the name alone.

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?

There are no annotations, and the description adds no behavioral details beyond the label 'Full Multimodal Pipeline (All Modalities → Fused z)'. It does not mention side effects, state changes, whether simulation is always used, what happens to existing sensor data, or any prerequisites for calling this 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?

The description is extremely terse and front-loaded, using a clear arrow notation to show the transformation from inputs to fused output. No filler words are present, though the brevity leaves room for important details that are handled in other dimensions.

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 no annotations, no output schema, many similarly named sibling tools, and three parameters, this description is far too sparse to be complete. An agent cannot know when to choose this tool, what invocation entails, or what the 'Fused z' output looks like.

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 the schema already explains each parameter. The description's reference to 'All Modalities' loosely maps to compounds, visualSource, and audioFrequency, but it does not add any detailed semantic meaning beyond what the schema provides. Baseline 3 is appropriate.

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 identifies this as a full multimodal pipeline that takes all modalities and produces a fused output 'z'. It conveys the core operation and is distinct from individual sensor tools like sensor_visual, sensor_audio, and sensor_olfactory, though it does not clearly distinguish itself from sensor_fuse.

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 about when to use sensor_process versus the sibling tools such as sensor_fuse, sensor_visual, or sensor_olfactory. The description implies it handles everything at once, but there are no explicit conditions, alternatives, or exclusions.

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 burden of disclosing behavior. The description does not state whether the tool is read-only, whether it has side effects, what data it accesses, or what the status covers. It provides zero behavioral context beyond the name.

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 terse, consisting of a four-word noun phrase. While there is no fluff, it is under-specified to the point of being unhelpful. A concise description must still contain an actionable verb and enough detail to guide invocation; this does not.

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 zero-parameter status tool, the description still leaves major gaps: no indication of what the status output contains, whether this covers the entire pipeline or a subset, or how it relates to sibling tools like sensor_fuse and get_system_status. The lack of an output schema increases the need for the description to explain return values, which it fails to do.

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 has zero parameters, and the input schema confirms this. With no parameters to explain, the description cannot add parameter meaning, and the baseline for a zero-parameter tool is 4. The description does not harm this dimension, but it also adds nothing extra.

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 'Multimodal Sensor Pipeline Status' is essentially a noun phrase restating the tool name. It lacks a verb like 'get' or 'retrieve' and does not distinguish this tool from siblings such as get_system_status, get_metrics, or sensor_fuse. It communicates a subject (multimodal sensor pipeline) but not the action or exact scope.

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 over alternatives. The sibling list includes get_system_status, get_metrics, and various sensor_* tools, but the description does not mention any context, exclusions, or conditions that would help an agent pick this tool.

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 must carry the full burden of behavioral disclosure. It only states the model family and input modality, but does not mention whether this is a read-only computation, what side effects exist, what the output representation is, or how parameters such as simulate and videoFrames affect 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?

The description is extremely short and contains no filler, but it is under-specified rather than effectively concise. It is a fragment with no sentence structure and no front-loaded action or output expectation.

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 and no annotations, the description should explain what the encoding returns and how the tool behaves, but it only names the model and modality. The nested input object and the image/video distinction are left entirely to the schema, so an agent cannot reliably understand the result or invocation context.

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 schema has 100% parameter documentation coverage, including descriptions for simulate and videoFrames, so the schema carries the explanatory load. The description itself adds no additional parameter meaning beyond the image/video distinction that videoFrames already expresses.

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 identifies this as V-JEPA 2 visual encoding and mentions image/video input, which weakly distinguishes it from sensor_audio and sensor_olfactory. However, it is a noun phrase rather than a clear statement of what the tool does, and it does not specify what kind of output the encoding produces.

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 description offers no guidance on when to use this tool versus alternatives such as sensor_process, sensor_fuse, or sensor_status. The intended context is only implied by the word 'visual,' with no exclusions, conditions, or named alternatives.

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 must carry the full burden of disclosing side effects and expectations. "Modify" conveys mutation, but there is no information about whether changes persist, affect a running simulation, require reset, or return any confirmation.

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 phrase is short, but under-specification is not conciseness. A single vague clause omits essential context while adding no distinctive content, so the structure does not earn its place.

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 no annotations, no output schema, and no parameter documentation, this description is far from complete. An agent cannot know which state parameter paths are valid, what value changes do, or what the result of the call is.

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 for the undocumented path and value fields. It does not: it only repeats the generic modify/parameter idea and gives no hint about path format, value range, allowed values, or units.

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?

"Modify State Parameter" essentially restates the tool name set_parameter rather than adding specific meaning. It identifies a verb and resource but does not clarify what kind of state parameter is affected, leaving the tool indistinguishable from other state-related tools like simulation_control or snn_step.

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 description offers no guidance on when to use this tool versus siblings such as simulation_control, snn_step, or wm_train_step. There are no conditions, exclusions, or alternative tools mentioned, so an agent has no basis for routing to this tool.

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 and the description discloses no behavioral traits. It does not say whether start/stop mutate simulation state, whether status is read-only, or whether commands have side effects or prerequisites.

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 only two words, which is concise but not effectively structured. It reads as a title and provides no front-loaded information that helps an agent decide to invoke the tool.

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 tool that controls simulation lifecycle, the description is far too incomplete. There is no output schema, no annotation coverage, and no explanation of command effects, return behavior, or failure conditions.

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%, and the description adds no meaning beyond the parameter name "command" and its enum values. The enum provides some self-documentation, but the description itself does not compensate for the low coverage.

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 is exactly "Simulation Control", which restates the tool name. It does not state what action the tool performs, what simulation resource it affects, or what outcome the commands produce.

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 about when to use this tool versus alternatives like get_system_status, snn_step, snn_reset, or get_platform_status. An agent would have to infer all usage context from the command enum alone.

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 full responsibility for behavioral disclosure. 'Reset' implies a state-changing, likely destructive operation, but the description does not say whether it clears all SNN state, whether it is reversible, or whether it interrupts ongoing simulation. This is a notable gap for a reset operation.

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 exceptionally concise at three words and is front-loaded with no filler. However, it adds little beyond the tool name itself, so it is efficient but not richly informative.

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 zero-parameter tool this is simple to invoke, but the absence of any note about side effects, reset scope, or relationship to the SNN lifecycle leaves the description incomplete. An agent cannot confidently determine the consequences of calling this tool.

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 has zero parameters, so the input schema already fully covers invocation needs. The baseline of 4 is appropriate; no parameter documentation is required.

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 'Reset SNN Engine' uses a specific verb and resource, and the action is clearly distinct from sibling tools like snn_step or get_snn_state. It is not a tautology, though it gives no detail on what 'reset' encompasses.

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 alternatives, no mention of prerequisites, and no indication of whether it should be run before or after other operations. The description simply states the action without any contextual direction.

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 present, the description carries the full burden and only says 'Advance SNN Simulation'. It does not disclose whether this mutates simulation state, is reversible, requires any precondition, or what the return/response looks like.

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 very short, front-loaded, and contains no filler words. It is appropriately compact for a simple tool, though it is too terse to convey parameter semantics or effects.

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 tool with one parameter, no output schema, and no annotations, the description is not complete enough: it leaves the meaning of 'steps', side effects, and the relationship to siblings unstated. An agent can take the core action but may mis-invoke the parameter or confuse it with simulation_control.

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 schema describes one parameter, 'steps', with type, default, and bounds, but the description does not explain that the value is a count of simulation steps or how it affects behavior. Since schema description coverage is 0%, the description should compensate but does not.

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 states a specific action, 'Advance', applied to 'SNN Simulation', so an agent can tell this tool moves the simulation forward. It does not, however, contrast with the sibling simulation_control or snn_reset, which could also relate to simulation progress.

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 given about when to use this tool versus alternatives like simulation_control or snn_reset. There are no exclusions, prerequisites, or context hints to route the agent to the correct sibling.

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 present, so the description carries the full burden of behavioral disclosure. It explains the internal model (action→expected-valence map) and the two query modes, implying a read-only operation, but it does not explicitly state side-effect freeness, output format, or error behavior. For a simple query tool, this is adequate but not rich.

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, tightly written sentence that front-loads the core capability and uses no filler. Every phrase contributes meaning, from the parenthetical port reference to the two-mode usage explanation.

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 tool with one optional parameter and no output schema, the description adequately covers the two main use cases and the underlying semantics. It is sufficiently complete for an agent to invoke it correctly, though it does not spell out the exact return structure or edge-case handling. Given the tool's simplicity, this is a good level of completeness.

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 schema description coverage is 100% for the sole 'action' parameter, but the description adds key semantic value by clarifying that omitting the action lists the entire capability table. This goes beyond the schema's description of 'Action label to query expected valence for' by explaining the optionality and fallback behavior.

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 a specific verb ('Query') and resource ('expected outcome of an action' or 'learned capability table'), and it is distinguishable from siblings like tcai_memory_retrieve or tcai_self_model by referencing the action→expected-valence map (EMA). The mention of 'DirectExperienceLearner port' adds specificity.

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 description outlines two distinct usage modes: querying a specific action's expected valence, or listing the full capability table when no action is provided. This provides clear context for when to use the tool, though it does not explicitly name alternatives or exclusions. It is not misleading, just lacks a formal 'when not to use' statement.

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 delivers. It explains both modes (get/set), the exact halting condition (learning velocity high, curiosity/surprise low, stability sustained over patience cycles), and cites the source. This exceeds typical transparency for a configuration 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?

Three sentences, front-loaded with purpose, then mode behavior, then halting logic. Every sentence adds value, with no repetition or filler.

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 has no output schema, and the description explains the no-arg return ('satisfaction state and active thresholds') but not the return for the with-arg mode. The halting condition is thoroughly described, and the schema covers all parameters. Minor gap on update response, but overall complete for a getter/setter.

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%, and each parameter has min/max/default in the schema. The description adds only a general reference to 'thresholds' and 'patience cycles' but doesn't add meaning beyond the schema. Baseline 3 is appropriate.

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 tool's dual function: inspect or configure the halting criterion. It specifies the resource ('recursive double-loop halting criterion') and distinguishes it from siblings by explicitly tying it to tcai_cycle's stopWhenSatisfied. The verbs 'inspect or configure' are specific and action-oriented.

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 description provides clear context on when to use the tool: with no arguments for inspection, with arguments for updating thresholds. It also explains the halting condition, offering the agent a decision framework. However, it does not explicitly exclude alternative tools or state when not to use it, but the context is sufficient.

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 burden of disclosing side effects and state changes. It explains the computation and the default broadcast source but does not state whether the tool is read-only, whether the predictor is updated, or what the return value is. This is a significant transparency gap for a tool that may have internal state.

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 compact, front-loaded with the core concept, and efficiently conveys the algorithm, interpretation, and default. The use of jargon (RND, EFE, GNW) adds density but does not waste words.

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 has no output schema and only one optional parameter, yet the description does not explain the return format (e.g., a scalar value). It provides good conceptual context but leaves out practical details about what the agent can expect as a result, making it adequate but incomplete.

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 schema covers 100% of parameters, with the 'embedding' property described as 'Representation vector (defaults to current broadcast)'. The description reinforces the default behavior but adds no new semantic information beyond what the schema already 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?

The description clearly identifies the tool as an intrinsic-reward/curiosity mechanism based on prediction error, referencing RNDCuriosity and explaining the high-error-equals-novelty relationship. It distinguishes itself from sibling tcai tools by its specific algorithm and purpose, though it lacks an explicit verb like 'computes' or 'returns'.

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 description implies usage for exploration or novelty-seeking ('exploration drive (EFE epistemic value proxy)') but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. The usage context is present but not fully articulated.

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 must carry the behavioral disclosure burden. It does explain the cycle pipeline and the early-halt behavior via stopWhenSatisfied, but it does not disclose side effects (e.g., state mutation, memory writes) or what the tool returns. This is minimally adequate 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?

Two sentences, front-loaded with the purpose. The pipeline enumeration is dense but informative, and the second sentence provides actionable halt criteria. Every sentence earns its place with no fluff.

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 14-parameter simulation loop with no output schema, the description gives the internal pipeline and halt conditions but omits expected output/return values, prerequisite system state, and how this relates to sibling cycle tools. The rich schema partially compensates, making it minimally viable but not fully 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 79%, so the schema already documents most parameters. The description adds useful context for stopWhenSatisfied and the cycle stages, but it does not compensate for the three undocumented parameters (threat, controllability, predictionConfidence). Baseline 3 is appropriate.

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 opens with 'Run one or more ACM cycles' — a specific verb plus resource. It names the port and lists the internal pipeline, making its purpose unmistakable and differentiating it from sibling state-read or single-step tools like snn_step and tcai_second_order.

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 alternatives such as snn_step, tcai_second_order, or wm_*. The only usage hint is the stopWhenSatisfied explanation, which is parameter-level guidance rather than tool-selection guidance.

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. It discloses the output dimensions (stage, stability, meta-representation score) and the behavioral trait of 'second-order self-monitoring over time.' It does not explicitly state whether the operation is read-only or whether it modifies any state, but 'tracking' implies a non-mutating observation.

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 compact, consisting of two sentences. It front-loads the core purpose and then lists specific outputs. The parenthetical 'DevelopmentTracker port' adds context but is slightly unnecessary; overall, the description is efficient and free of filler.

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 zero-parameter tool with no output schema, the description covers the essential aspects: what it does, what it produces, and its temporal nature. It does not specify return formats or units, but the low complexity makes this acceptable. The lack of sibling differentiation is a minor 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?

The tool has zero parameters, so the schema provides no parameter information. The description adds context about the data source ('running composite-proxy level') and outputs, which adequately compensates for the lack of parameters. The baseline of 4 for zero-parameter tools is appropriate.

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 tool's function: longitudinal developmental tracking with specific stage progression (nascent→reactive→integrative→reflective) and derived scores. It distinguishes itself from sibling tools by emphasizing temporal tracking and second-order self-monitoring, though it lacks an explicit verb like 'get' or 'retrieve'.

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?

Usage context is implied through 'longitudinal' and 'over time', suggesting it is for tracking development rather than one-off queries. However, there is no explicit guidance on when to use this tool versus alternatives like tcai_second_order or tcai_meta_learning, and no exclusions or conditions are stated.

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 provided, the description must disclose behavioral traits fully. It mentions 'inertia' implying statefulness or temporal dependency, but does not explain side effects, return format, or whether it modifies internal state. The absence of explicit behavioral disclosure is a significant gap.

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, tightly packed sentence with no redundant words. It front-loads the core purpose and the key behavioral nuance (inertia), making it highly efficient.

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 the absence of an output schema, annotations, and parameter descriptions, this tool description is incomplete. It does not explain return values, how parameters interact, or what 'inertia' entails operationally. The agent would struggle to correctly invoke and interpret the tool.

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 by explaining the four parameters. However, it only refers to 'raw signals' without mapping to threat, novelty, rewardSignal, or controllability. Parameter meanings are left to name inference, which is insufficient for an agent.

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 uses the specific verb 'Appraise' and clearly states the transformation into PAD emotional space (Mehrabian), which distinguishes it from sibling tcai tools focused on memory, curiosity, or meta-cognition. The inclusion of 'with inertia' further indicates a unique temporal aspect.

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. The description only states what it does, without specifying scenarios, prerequisites, or exclusions, leaving the agent to infer applicability.

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 present, so the description bears the full burden. It discloses the scoring criteria but does not explain what happens when no memories match, whether the operation is read-only, the format of returned data, or what 'blended' and 'salience' mean. 'Retrieve' implies read-only, but explicit side-effect disclosure is absent.

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 sentence, front-loaded with the verb, and contains no redundant or filler words. It is appropriately concise for a retrieval operation.

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 has 5 optional parameters, no output schema, and no annotations. The description does not mention return values, default behavior for missing parameters (only embedding has a documented default in schema), or how topK bounds results. This is insufficient for a retrieval tool where callers need to know what to expect back.

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% (4 of 5 parameters have descriptions). The description adds context by linking PAD congruence to the arousal/valence/dominance parameters, but topK remains undocumented in both schema and description. The description does not add syntax or format details beyond what the schema provides, so a baseline 3 is appropriate.

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 uses a specific verb 'Retrieve' with resource 'memories' and explicitly names the retrieval criteria: 'blended cosine similarity, PAD congruence and salience'. This clearly distinguishes it from sibling tools like tcai_memory_store (store) and wm_* (working memory) tools.

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. The sibling list includes several memory-related tools (tcai_memory_store, wm_encode, wm_recall, etc.), but the description does not mention any exclusions, prerequisites, or comparison to other retrieval mechanisms.

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 must carry the full burden. It discloses the mechanism ('attention-gated, salience-indexed'), which hints at behavioral nuances, but does not explain side effects, mutation consequences, or return values. This is marginal but not entirely absent.

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 sentence that is both concise and information-dense, front-loading the main action and adding two qualifiers. No wasteful words.

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 6 parameters, no output schema, and no annotations, the description is too brief to fully equip an agent. It omits what the tool returns, any prerequisites (e.g., existing memory store), and the practical effect of attention/salience settings. This is a significant 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?

The schema already documents parameters well (83% coverage), so the description adds limited additional meaning. It ties 'attention-gated' to attentionLevel and 'emotional memory' to affective dimensions, providing some conceptual context, but doesn't explain how each parameter maps to the storage algorithm.

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 ('Store') and the resource ('an experience in emotional memory'), making the tool's purpose distinct from siblings like tcai_memory_retrieve. However, it does not explicitly differentiate itself from other memory-related tools beyond the verb itself.

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 description implies the tool is used for saving experiences, with phrases like 'attention-gated' suggesting a condition for storing. It doesn't provide explicit when-to-use or when-not-to-use guidance, nor name alternative tools, but the context is reasonably clear from the tool name.

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 itself carries the transparency burden. It discloses that the result is a proxy rather than a measurement and lists the component dimensions, which adds meaningful behavioral context. It does not mention output format or side effects, but the zero-parameter nature strongly suggests a read-only computation.

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, well-structured sentence that front-loads the tool's identity and immediately provides the key caveat ('proxy, not measurement'). Every phrase earns its place with no 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?

For a zero-parameter tool with no output schema, the description covers the core purpose and a critical interpretive caveat. However, it lacks return scale/format details and explicit guidance on when to use this tool versus sibling meta-cognitive evaluators, leaving some ambiguity for an agent.

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 has zero parameters and schema coverage is 100%, so no parameter explanation is needed. The description adds value by explaining what the composite score is based on, exceeding the empty schema's information.

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 tool computes a weighted score over confidence calibration, learning awareness, self-continuity, and error monitoring. The 'PROXY of meta-representation capacity, not a measurement' framing distinguishes it as an evaluator rather than a direct measurement, separating it from sibling meta-cognitive tools.

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 'not a measurement' caveat implies the tool should be used as an approximate proxy, but there is no explicit when-to-use guidance or comparison with sibling tools like tcai_second_order or tcai_meta_learning. The intended context is only weakly implied.

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. It discloses the meaning of velocity and noveltySpike and notes that an RPE sample can be optionally injected, which implies a side effect. However, it does not clarify the full effects of injection, whether reading is side-effect-free, or any error conditions.

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 compact, two sentences, with no filler. It packs state interpretation and optional action into a tight structure, front-loading the primary purpose.

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 there is no output schema, the description does not explicitly state the return format or structure, though it hints at velocity and noveltySpike fields. It also doesn't elaborate on the consequences of injecting an RPE sample. For a somewhat complex state tool, this is adequate but incomplete.

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 input schema already provides 100% coverage for the single 'rpe' parameter with a clear description. The tool description adds the word 'inject' and reinforces the sample semantics, but does not add significant new meaning beyond the schema. Baseline 3 is appropriate.

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 it exposes meta-learning state, specifically learning velocity from RPE-variance dynamics, with interpretation for velocity and noveltySpike. It also mentions optional injection of an RPE sample. This goes beyond a tautology and gives a specific resource and action, though it doesn't explicitly name a verb like 'get' or 'read', it's clear enough.

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 description provides useful interpretation cues ('velocity>0 ⇒ converging; noveltySpike ⇒ novel/confusing regime') that implicitly tell when this state is relevant, but there is no explicit guidance on when to use this tool vs. siblings like tcai_convergence or tcai_curiosity, and no mention of exclusions.

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 must carry the full burden of disclosing behavior. It only provides a nominal label and metric list, without stating whether this is a read-only report, what side effects exist, or what the output looks like. This is a significant transparency gap.

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, a single fragment that efficiently lists the report type and key metrics. It is not verbose and every word adds information, though it is structurally a fragment rather than a complete sentence.

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 has no output schema and no parameters, so the description is the only source of information. It names the metrics but doesn't explain what 'composite score' means, how the report is presented, or how to interpret the values. This is a notable gap for a report tool.

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 has zero parameters, so the schema is fully covered by default. There are no parameter semantics to describe, and the baseline of 4 applies because the description doesn't need to compensate for missing parameter 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 identifies the tool as a 'Consciousness proxy report' and names specific metrics, which gives it some clarity. However, it lacks an explicit verb like 'get' or 'generate', making the action somewhat implied. It does distinguish from siblings by naming unique metrics like GNW and Φ̃-RIIU, but only partially.

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 alternatives such as tcai_self_model or get_metrics. No usage context, when/when-not conditions, or alternative references are provided, leaving the agent to guess.

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?

The description lists the affected components but does not disclose that a reset is likely destructive, irreversible, or has side effects. Since no annotations are provided, the description carries the full burden and this is a significant transparency gap.

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, concise sentence that front-loads the action and resource. It avoids redundancy and is appropriately sized for a tool with no parameters.

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?

While the description covers the basic function and scope, it lacks details about the consequences of a reset, such as whether it clears all data, requires confirmation, or affects other systems. For a mutation tool with no annotations, this leaves the agent without a complete understanding.

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 has zero parameters and the schema coverage is 100%, so there is nothing for the description to add param-wise. The baseline for 0 params is 4, and the description does not omit any necessary parameter information.

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 'Reset' and the resource 'TCAI consciousness system', listing the specific components (workspace, memory, emotion, metrics). This distinguishes it from sibling tools like tcai_cycle or tcai_workspace_state.

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 description provides no guidance on when to use this tool versus alternatives, no prerequisites, or exclusions. It only states what the tool does, not when it should be called.

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 must fully disclose behavior. Calling it a 'snapshot' suggests a read-only operation, but the phrase 'observing and correcting its own predictive capacity' introduces ambiguity about potential side effects. It does not clarify whether the tool modifies state, requires permissions, or what the return format is, leaving key behavioral traits undisclosed.

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 compact and front-loaded, with the first sentence listing the tool's purpose and contents. The second sentence adds theoretical context that is somewhat extraneous but not bloated. Every sentence contributes to understanding, though the reference to 'Legros 2026' is jargon-heavy.

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 provides a reasonable overview of the output components and positions the tool as a meta-cognitive snapshot, which is helpful given the domain's complexity. However, it lacks details on value semantics, units, or how to interpret the combined snapshot, and it does not clearly state whether the operation is purely observational. Without an output schema, more explanatory content would improve completeness.

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 has zero parameters, so the schema is empty and there is nothing to describe. The baseline of 4 applies, and the description correctly adds no irrelevant parameter details.

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 identifies the tool as a 'second-order (self-evidencing) loop snapshot' and lists the specific components it covers (meta-learning velocity, RND curiosity, capability model, meta-consciousness score, developmental stage), which distinguishes it from sibling tools that focus on individual aspects. However, it lacks an explicit verb like 'get' or 'retrieve', leaving the action somewhat implicit.

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 description implies use for obtaining a combined view of self-monitoring metrics, but it does not explicitly state when to use this tool instead of individual sibling tools like tcai_metrics or tcai_self_model. No exclusions or alternative comparisons are provided, so the usage context is only implicit.

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 of disclosing behavioral traits. It reveals the content areas of the state but says nothing about side effects, access requirements, or whether the state is computed on demand or cached. It does not explicitly state that this is a read-only operation, which is a significant gap for a tool that likely returns a snapshot.

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, compact phrase that front-loads the core concept ('Self-representation state') and then lists four concrete components. There is no redundancy or filler. Every word contributes to the meaning, making it appropriately concise and well-structured for a zero-parameter state query.

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 tool with no parameters, no output schema, and no annotations, the description gives enough to infer the tool's domain but not the full picture. It fails to mention the return type or how the state is presented (e.g., JSON object, numerical values). It is minimally viable but leaves notable gaps, especially around interpreting the listed components.

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 has zero parameters, so the baseline is 4. The description correctly does not need to elaborate on parameter meaning. The empty input schema is consistent with the description, and no further clarification is required.

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 identifies the tool as exposing 'Self-representation state' with specific components (interoception, epistemic model, etc.), which gives a clear subject area. However, it lacks an explicit verb (e.g., 'get', 'retrieve', 'display'), so the exact action is implied rather than stated. It partially distinguishes from siblings by listing unique aspects, but without a verb it remains somewhat vague.

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 description provides no guidance on when to use this tool versus alternatives like tcai_second_order or tcai_workspace_state. It does not mention any exclusions, prerequisites, or typical use cases. The reader is left to infer that this is a state query, but no explicit direction is given.

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 burden of behavioral disclosure. It only lists state labels and does not indicate whether this is a read-only operation, what the response format is, whether it triggers side effects, or any permissions required. The lack of behavioral context makes the tool unpredictable for an AI agent.

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, efficient line with no filler or unnecessary words. It is front-loaded with the main topic and then enumerates specific state aspects. The lack of a verb is a content issue, not a conciseness issue, so conciseness merits a full score.

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 annotations and no output schema, the description must stand alone, but it is too sparse. It names several state dimensions but does not explain their meaning, format, or interpretation. The tool appears to be a state accessor, but the description does not provide enough context for correct invocation or expectation of results.

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 accepts zero parameters, so there is no obligation to document parameter meaning. The schema is empty, and the baseline for zero-parameter tools is 4. The description's list of state components likely refers to output fields, not inputs, so no additional parameter semantics are needed.

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 is a noun phrase listing components ('ignition, focus, qualia, sync R, unity metrics, access history') with no verb indicating the tool's action. It doesn't explicitly state whether the tool retrieves, computes, or updates state, making the purpose ambiguous. It does list specific metric names, slightly distinguishing it from siblings, but the core action is missing.

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 description provides no guidance on when to use this tool versus alternatives like tcai_metrics, get_metrics, or tcai_self_model. There are no context cues, prerequisites, or exclusions mentioned, leaving the selection entirely to inference.

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 must carry the full burden of disclosing side effects and return behavior, but it only states the intended transformation. It does not say whether the SNN state is modified, whether a latent representation is returned, or whether any prerequisites exist, which matters for an unannotated 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?

The description is a single front-loaded sentence with no filler, and every word contributes to the operation. It is compact, though arguably too short to cover behavior; that tradeoff is better scored under contextual completeness.

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 annotation coverage, so the description should clarify what the agent receives from the encode operation and whether the operation has side effects. It does neither, leaving an agent to guess at the meaning and return value of 'latent space' in this system.

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 input schema has zero properties and schema description coverage is 100%, so the parameter baseline is 4. The description adds no parameter-level details, but none are needed because there are no parameters to describe.

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 a specific verb ('Encode'), a resource ('SNN State'), and a target ('Latent Space'), so it is not a tautology and reads as a distinct transformation operation compared to siblings like get_snn_state or wm_predict. However, it relies on the term 'Latent Space' without explaining what the output represents, so the purpose is clear but not fully specified.

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 about when to call this tool rather than get_snn_state, wm_predict, or the other wm_* siblings, and no exclusions or alternative conditions. The only clue is the verb 'encode', which implies a use case but leaves the decision entirely to inference.

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 of behavioral disclosure. It reveals the algorithm (CEM) and target (spike injection), but does not state whether the tool returns a plan, mutates system state, requires a running simulation, or has side effects.

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 short, but it is under-specified rather than efficient. It reads like a heading or tagline rather than an informative definition, and it omits essential operational context.

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 tool with no output schema, no annotations, and a nested goal object, this description is incomplete. An agent cannot tell what wm_plan returns, how it relates to inject_spikes, or what 'optimal' means in practical terms.

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 the schema already documents the goal and horizon parameters. The description adds little semantic detail beyond the schema, but it does hint that goal-driven optimization is involved.

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 identifies the tool as a planning operation for spike injection using CEM, which is more specific than a mere restatement of the name. It implies a distinction from execution tools like inject_spikes, though it does not explicitly name or contrast siblings.

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 given about when to use wm_plan versus alternatives such as inject_spikes, wm_predict, or snn_step. The intended invocation context must be inferred from the name and sibling list.

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 burden of behavioral disclosure. It only states a prediction outcome and gives no information about side effects, whether the action injection mutates state, determinism, or what is returned. This is a significant gap for a tool with no safety annotations.

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 short, front-loaded, and free of filler, which is good. However, it is under-specified for a tool with a nested action schema, and the brevity comes at the cost of useful detail.

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 annotations and no output schema, the description leaves critical details unstated: what the tool returns, how the action conditions the prediction, and how steps affects the rollout. An agent would have to rely heavily on the schema and experimentation to use this tool correctly.

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 the schema already documents the purpose of steps, action, targetNeurons, strengths, and duration. The description adds no parameter-level meaning, so the baseline score of 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 uses a specific verb ('Predict') and names a concrete resource ('Next SNN State in Latent Space'), which clearly communicates the tool's core function. It does not explicitly differentiate it from siblings like wm_plan or wm_train_step, but the core purpose is still identifiable.

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 alternatives such as wm_plan, snn_step, or wm_encode. The description provides no context, prerequisites, or exclusions to help an agent choose this tool over its siblings.

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 of disclosing behavior, and it fails to do so. It does not state whether the call is read-only, what kind of response it returns, whether it has side effects, or what 'status & metrics' actually includes.

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 only five words and technically concise, but this is under-specification rather than effective conciseness. It is a fragment rather than a complete sentence and provides no actionable information beyond 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?

Although the tool has no parameters and no output schema, the description is still incomplete because it does not explain what the returned status and metrics actually are, nor how this tool differs from the numerous sibling status/metrics tools. An agent cannot confidently select and interpret the result.

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 has zero parameters and the schema coverage is 100%, so there is no parameter documentation burden for the description to carry. The baseline of 4 for zero-parameter tools 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 'World Model Status & Metrics' is a noun phrase that essentially restates the tool name 'wm_status'. It names a resource but lacks a verb or explicit operation, and it does not distinguish this tool from siblings like get_metrics or get_system_status.

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 many related siblings such as get_system_status, get_metrics, or get_platform_status. The description provides no context, prerequisites, or exclusions, so an agent must guess which status/metrics tool to invoke.

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 disclosure burden. It only says "Detection," which weakly implies a read-like operation, but it never states side effects, internal state requirements, how the action input is applied, or what the result represents.

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 short and front-loaded, but this is under-specification rather than effective conciseness. The three-word label does not provide enough substance to earn a higher score.

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 has a nested required parameter, no output schema, and no annotations, making rich contextual guidance essential. The description explains neither the expected behavior, the return value, nor how the action input relates to surprise detection, leaving the agent without enough information to invoke it correctly.

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 the nested action object, targetNeurons, strengths, and duration are already documented in the schema. The description adds no parameter-level meaning, but it does not need to because the schema already covers the fields.

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?

"Violation-of-Expectation Detection" names a recognizable cognitive-science concept and implies the tool detects mismatches between predictions and observations. However, it is a noun phrase rather than a specific verb-plus-resource statement, and it does not explicitly distinguish wm_surprise from closely related siblings like wm_predict or wm_train_step.

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 description gives no guidance on when to use this tool instead of wm_predict, wm_train_step, or any other sibling. There is no mention of prerequisites, intended workflow, or exclusions, so an agent must infer usage from the name and schema.

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 provided, the description carries the full burden of disclosing behavioral traits, but it offers none. It does not state that this operation modifies the model, what side effects occur, whether it requires a running simulation, or what the observable consequences are. 'Training Step' vaguely implies mutation, but that is not explicit.

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 undeniably short, but it is under-specified rather than efficiently concise. It is essentially a title fragment that restates the tool name and provides no operational substance, so it does not earn its place as a useful description.

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 tool with a nested parameter object, no annotations, no output schema, and a family of closely related wm_* siblings, this description is completely inadequate. An agent cannot determine what the action object represents, how training is performed, what the return value is, or how this differs from wm_predict or wm_encode.

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%, and the nested 'action' object's properties (targetNeurons, strengths, duration) are individually described in the schema. The tool description adds no additional parameter context, so the baseline score of 3 applies: the 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?

The description 'Online World Model Training Step' simply restates the tool name in expanded form; it does not state a specific verb or resource. It gives some clue that this relates to training the world model, but it fails to distinguish this tool from siblings like wm_encode, wm_predict, or wm_plan in any meaningful way.

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 description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or any exclusion criteria, leaving the agent to infer usage entirely from the name and parameter schema.

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