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

Annotations already declare non-readOnly, non-idempotent, non-destructive, so safety profile is covered. The description adds real behavioral value beyond them: it discloses the side effect of disengaging active inputs and enumerates what comes back (transition status, disengaged inputs, unstick diagnostics). It does not mention authorization requirements or whether abort is recoverable.

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?

Front-loaded with the operations and kept to three tight sentences. The action set is repeated in the parenthetical after already being named, which is mild redundancy, but nothing else is wasted.

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 5-parameter mutation tool with no output schema, the description covers purpose, the sibling alternative, and the return payload, which is enough to invoke it correctly. It omits prerequisites (need for an existing execution/trace context) and the relationship between the four actions, leaving minor gaps.

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 action enum is already documented with per-value semantics, so the schema carries the load. The description only restates the action list and adds no format or interaction detail for reason/project/trace_id/execution_id, making the baseline 3 correct.

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?

Names the concrete operations (abort, pause, resume, unstick) against a specific resource (behavior execution) and states the side effect (disengaging active inputs). It also names the sibling it is not (register_trigger), so an agent can distinguish it without opening either schema.

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?

Explicitly routes the agent: 'Use abort_behavior instead of register_trigger when manually halting or recovering execution rather than configuring automatic condition interrupts.' That gives a clear alternative plus the selecting condition. It stops short of 5 because it offers no guidance on choosing among the four actions (abort vs pause vs unstick vs resume) at this level.

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?

Annotations declare readOnlyHint=true and idempotentHint=true, but the tool exposes a drain_spool action returning 'drained entry counts' — draining consumes/removes spool entries, which is a state mutation and is not idempotent. The description thus contradicts the read-only/idempotent safety profile for at least one action, and it never warns that one action differs in side effects from the rest.

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?

Front-loads the resource list, then routes to the alternative, then summarizes returns — a sensible order. The 'Returns telemetry metrics...' sentence largely re-states the opening list, and the action enum is repeated from the schema, adding minor 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 7-param, 6-mode read/mutate hybrid with no output schema, the description does cover purpose, alternatives, and return categories. However it fails to disambiguate the side-effect profile across actions (drain_spool vs read-only modes), which is exactly the information an agent needs before invoking, so it is adequate but with a material gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented, and the description merely repeats the action enum verbatim. It adds no syntax, format, or meaning (e.g., how trace_id interacts with execution_id filter, or what behavior_name expects) beyond the schema, matching the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Retrieve) plus the concrete resource set: runtime telemetry, tick durations, stuck events, category statistics, and 60Hz action outcome spool entries. It also names the sibling it differs from (get_status) and the axis of difference (performance/spooled outcomes vs active node traversal), so an agent can separate the two without opening either schema.

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?

Contains an explicit when-to-use/when-not clause: 'Use get_metrics instead of get_status when evaluating tick performance, reading spooled action outcomes, or inspecting aggregated statistics rather than active node traversal.' The alternative tool and the selecting condition are both named.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that by enumerating what is returned (execution status, node path, tick counters, duration, error states), which matters since there is no output schema. It stops short of noting auth requirements, rate limits, or pagination behavior for history.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the action modes and the routing rule front-loaded, followed by the return summary. Very little waste, though the parenthetical enum listing is mildly redundant with the schema.

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 read-only query tool with full schema coverage and safety annotations, the definition covers purpose, alternatives, and return fields, compensating for the absent output schema. Minor gaps remain around history pagination and default-to-latest execution 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 description coverage is 100%, so the schema already documents action, project, execution_id, and limit. The description's parenthetical restates the action enum but adds no new syntax or format detail. Baseline 3 is appropriate when the schema carries the parameter burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Query) and resource (behavior execution status/history/tree traversal), and enumerates the three action modes. It also names the sibling get_metrics and explains the distinction, so an agent can differentiate without opening any schema.

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?

Explicitly says to use get_status instead of get_metrics and gives the selecting condition: inspecting active execution state and node traversal paths vs. aggregated runtime performance telemetry. This is a full when/when-not/alternative 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description usefully adds what the call returns (handle, runtime state, active node, session/intention bindings) and the hot-swap semantics, but it never explains what unload or swap destroys or what happens to an in-flight tree, which is the key behavioral gap for a destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the operation and its action modes, followed by the sibling-disambiguation rule and the return summary. No padding or repetition of the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing returns, which it does compactly, and it routes between sibling tools. The remaining gap is the unaddressed destructive side of unload/swap, which matters for a nine-parameter mutation 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 100%, so every parameter is already documented in the schema, establishing a baseline of 3. The description adds no syntax or format detail beyond naming the actions and the return fields, so it does not raise the 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?

States a specific verb set (load, unload, hot-swap) on a concrete resource (a behavior tree instance in the browser runtime) and enumerates the three action modes. It also explicitly contrasts itself with the sibling manage_behaviors, so an agent can distinguish the two without opening either schema.

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?

Gives an explicit when-to-use rule: use load_behavior rather than manage_behaviors when executing an active behavior tree instance at runtime instead of registering or inspecting definitions. The alternative and the selecting condition are both named.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, and the description adds meaningful context: definitions are 'immutable' and content is SHA-256 verified. However, it never distinguishes which of the four actions mutate state (register/synthesize) versus which are reads (list/get), nor mentions the idempotency key parameter despite idempotentHint=false. With annotations covering the safety profile, the added value is real but partial.

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 and action enumeration followed by the sibling rule and return values. Slight redundancy in restating the tool name in the second sentence, but otherwise efficient and well ordered.

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?

Compensates for the absent output schema by naming return shapes ('tree definition, version metadata, SHA-256 content hash, or synthesis DAG'). For a 10-parameter, nested-object, multi-action tool, the remaining gap is the lack of per-action parameter guidance, since different actions clearly need different subsets of the 10 fields.

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% across 10 parameters, so the schema documents each field's type, enum, and meaning. The description adds no per-action parameter mapping (e.g., which of tree/tree_json/name/steps are required for register vs. synthesize), leaving the schema to do all the work. Baseline 3 is appropriate when the schema carries this burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Manage immutable JSON behavior tree definitions with SHA-256 hash verification') and enumerates the four supported actions, so the agent understands this is a multi-action dispatcher rather than a single operation. It also explicitly contrasts itself with the sibling load_behavior, making it distinguishable without opening either schema.

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?

Names the alternative tool (load_behavior) and the exact condition that selects this one: 'when defining, versioning, or synthesizing behavior tree structures rather than executing them.' That is an explicit when-to-use vs. alternative statement, which is the top of the scale.

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?

Annotations already declare destructiveHint=true and non-idempotent/non-read-only, so the safety profile is covered structurally. The description still adds non-obvious behavior beyond that: TTL-based slice staleness ('expires and is marked stale') and lease acquisition semantics with returned status/expiry metadata. It stops short of saying what a delete irreversibly removes or how leases behave on contention.

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 verb/resource and action set, with the usage routing second. Slightly wasteful in that the inline action enumeration duplicates the enum already in the schema, but there is 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?

With 11 parameters, nested payload objects, and no output schema, the description usefully enumerates the return shapes ('blackboard value, lease acquisition status, key listings, or slice ingestion summary with expiry metadata'). It does not map parameters to specific actions (e.g., lease needing agent_id/duration_seconds), but the fully documented schema covers that.

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% across all 11 parameters, so the schema already carries parameter meaning; the description adds essentially nothing beyond restating the action list. This is the correct baseline when 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 names a specific resource (shared behavior tree blackboard state) and enumerates the concrete operations (get, set, delete, lease, list, ingest_slice), which map exactly to the action enum. It also names the sibling set_parameters it displaces, so an agent can distinguish it without opening either schema.

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?

It gives explicit when-to-use criteria and names the alternative: 'Use manage_blackboard instead of set_parameters when coordinating state across behavior nodes, projecting perception/spatial slices with staleness protection, or acquiring agent mutex leases.' The selection condition is stated rather than inferred.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered externally. The description adds the return categories (diagnostics, audit trees, snapshot metadata, diff reports), which is useful since there is no output schema, but it never says which of the six actions is the destructive one or that restore overwrites the current database — the most important behavioral fact is left implicit.

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, capabilities front-loaded and the routing hint second; nothing is padding. The middle clause enumerating six action names is somewhat redundant with the schema enum, keeping it from a 5.

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 six-mode tool with no output schema, the description gives only a one-line summary of possible returns and no per-action behavioral detail. An agent knows the tool's domain and the get_metrics alternative but not how the actions differ in effect or which parameters each consumes, so it is minimally adequate rather than complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the action enum is fully documented in the schema, so the baseline of 3 applies. The description repeats the action names but adds no mapping of which parameters are required for which action (e.g., that 'name' matters only for snapshot/restore/diff), which is the genuinely missing 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 names a concrete resource (runtime database) and enumerates the six operations it bundles (stats, audit, doctor, snapshot, diff, restore). It also distinguishes itself from the sibling get_metrics, so an agent can route between the two without opening schemas. It stops short of a 5 only because the six actions are listed rather than individually characterized.

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?

It gives an explicit selection rule against a named alternative: use this instead of get_metrics when auditing SQLite integrity/Merkle proofs or restoring snapshots. That is clear context plus an alternative, but it offers no when-not guidance (e.g., that read-only diagnostic needs should prefer a lighter tool) and no prerequisites such as required permissions for restore.

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?

Annotations declare the write/non-idempotent/non-destructive profile, so the description's extra value is the domain behavior it adds: preemption-by-priority and cooldown guarding between fires. It does not describe persistence, permission requirements, or what a failed registration does, which keeps it short of a 5.

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 purpose and the sibling-routing rule before the trailing return-value note. The final sentence is partly redundant with the follow-on description text but is short enough to justify itself.

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?

Covers the two actions, the key configuration concepts, the return shape (configuration, ID, or list), and the sibling routing for a 9-parameter tool with no output schema. Nested condition_params is left to the schema, which is acceptable.

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%, so every parameter already carries its own description (priority, cooldown_ms, condition_type, etc.). The description repeats the register/list action split but adds no format or constraint detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Configure or list reactive interrupt triggers') and names the distinctive behavioral features (priority preemption, cooldown guards). It clearly differentiates itself from the sibling abort_behavior, so an agent can pick between them without opening a schema.

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?

Explicitly states when to prefer this tool over abort_behavior: 'defining automatic condition-based interrupts rather than manually pausing or stopping a tree.' That is a named alternative plus the condition that selects it.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the safety profile is covered. The description adds that the tool returns recording metadata, frame sequences, or a list of recordings, which is valuable given there is no output schema, though it does not say whether a capture overwrites an existing recording or which of project/execution_id are needed for capture.

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 short sentences, front-loaded with purpose and the sibling contrast, and the return-value note last. The action enumeration is arguably redundant with the schema enum, but nothing else is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the sentence describing return values (metadata, frame sequences, list of recordings) is a genuine completion of the picture, and the alternative-routing sentence covers selection. Minor gap: capture side effects and required IDs per action are left unstated for a non-idempotent 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 100%, so all six parameters (name, action, frames, project, execution_id, recording_id) are already documented in the schema. The description only names the action values and the notion of 'adaptive timing', adding little beyond what the structured fields provide.

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 verb pair and resource ('Capture or list deterministic browser action sequences') and explicitly enumerates the two supported actions, so an agent knows exactly what the tool does despite the name 'replay_recording' implying a replay action that doesn't exist. It also names the sibling it differs from, load_behavior.

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?

It gives an explicit routing rule: use this instead of load_behavior 'when recording or inspecting fixed action sequences rather than running a dynamic behavior tree.' The alternative and the selecting condition are both stated, leaving nothing 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?

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false; the description adds the reset capability and the return payload (updated parameter map + execution ID), which is useful behavioral context. It does not flag that reset is non-idempotent/potentially lossy, keeping it short of a 5, but it exceeds the annotation baseline.

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 core verb+resource and the action list, followed by the sibling routing and return note. Density is high and little is wasted, though the parenthetical action list slightly duplicates the enum.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully states the return value (parameter map + execution ID), and it covers the actions and the sibling distinction. Enough for an agent to invoke correctly, missing only finer detail on reset semantics and project/execution_id targeting.

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 action, project, parameters and execution_id, making the baseline 3. The description restates the three action values and implies the parameters map but adds no syntax or format detail 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?

States specific verbs (set, inspect, reset) and a precise resource (execution parameters for the active behavior runtime), and it explicitly distinguishes itself from the sibling manage_blackboard by domain (tree-level execution variables vs cross-node data keys). An agent can differentiate this from its siblings without opening a schema.

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?

It names the alternative (manage_blackboard) and the condition that selects this tool over it: tuning execution variables/thresholds rather than sharing cross-node keys. It lacks guidance on when to choose set vs get vs reset beyond the enum, so it's clear context but not a full when/when-not treatment.

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