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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond that—no statement of what is evaluated, whether it blocks other operations, or what a failing check implies.

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?

It is short, but the brevity reflects under-specification rather than conciseness—there is no front-loaded statement of purpose, scope, or behavior. A title-length string cannot earn credit for 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?

For a check tool with no parameters and no output schema, the description carries the entire burden of explaining what is checked and what the result means, and it does neither. An agent cannot tell what feedback this returns or how to act on it.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline is 4. No parameters are undocumented or misleading.

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 bare noun phrase, 'IRB Neural Welfare Check', which essentially restates the tool name and the annotation title. It hints at the domain (ethics/welfare review) but gives no specific verb-resource action, and does not distinguish this from the many other check/report siblings such as fcs_conformance or orch_criterion.

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 invoke this tool, what conditions trigger an ethics check, or what alternatives exist among the large sibling list. An agent has no basis for choosing this over fcs_lint, orch_criterion, or fcs_conformance.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered externally. The description adds nothing beyond that: no indication of scope, size, cost, or what 'full state' comprises versus a partial status read.

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?

While only three words, this is under-specification rather than conciseness. A single useful clause (e.g. 'returns the complete simulation state as a JSON blob') would have cost nothing and removed the ambiguity.

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?

No output schema exists, so the description carries the burden of explaining what is returned, yet it says nothing about contents or format. For a zero-parameter export tool in a crowded namespace, the definition is too thin to invoke confidently.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Per the baseline for parameterless tools, a 4 is appropriate; no parameter information is missing.

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?

"Full State Snapshot" is a noun phrase that merely restates the title/name and contains no verb or scoped resource. It does not distinguish export_snapshot from siblings like get_snn_state, tcai_workspace_state, or wm_status, which all appear to read state. An agent cannot tell what state is exported or in what form.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool, when not to, or which sibling to prefer for a narrower read. Given the dense cluster of state-reading siblings (get_system_status, get_snn_state, get_acm_score, ovo_status, etc.), this omission leaves selection entirely to guesswork.

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 cover the safety profile (readOnlyHint=true, idempotentHint=true, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful behavioral context: the operation returns a rationale for the ordering and explicitly treats incomparability as a legitimate outcome rather than an error, which is valuable for a tool with no output schema.

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 and the primary object, and the second sentence earns its place by pre-empting a misinterpretation of the result. No filler or restated title.

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 two-parameter, read-only comparison tool with no output schema, the description covers the key things an agent needs: what is compared and the two possible result shapes (ordered with a reason, or incomparable). Only minor gaps remain, such as what happens with invalid or unmatched pair ids.

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

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

Schema description coverage is 100%, so both parameters ('a' and 'b' as pair ids) are already documented by the schema. The description adds only the notion that the two arguments are 'species–function pairs' subject to a partial order, which is marginal additional meaning; 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 ('Compare two species–function pairs') and even describes the nature of the output (a justification for ordering). However, it does not distinguish itself from the many other fcs_* siblings (fcs_report, fcs_taxonomy, fcs_stratify, fcs_levels), so an agent must infer the boundary from the name alone.

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 conveys how to interpret the result ('incomparability is a result of the partial order, not a gap in it') but never says when to call this tool versus its siblings, nor any prerequisites such as needing valid pair ids from fcs_taxonomy or fcs_stratify. No alternatives or exclusions are 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 readOnly+idempotent+non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: that it returns a profile and never a score, that live biomarkers bind to specific classes, and that class 1 reads only caller-supplied extracellular Ca²⁺ while ASTRA's intramolecular Ca²⁺ binds to nothing.

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?

Four dense sentences front-loaded with the core purpose, then the binding details. Jargon-heavy but each sentence carries load (especially the class 1 vs eth.ca distinction, which prevents a wrong call). Not padded, though very tightly packed.

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-required-param audit tool with no output schema, it is adequate: it states the output is a profile (not a score) and enumerates the four result categories. Given the domain complexity it could say more about the profile's structure, but the caller has enough to invoke and interpret 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 coverage is 71%, and the prose compensates by giving binding semantics the schema omits: atpAdpRatio→class 7, firingRateHz→class 3 generator, viabilityPct→class 2b proxy, extracellularCalciumMm→class 1 only, and calciumNm→no pair. This is meaning beyond the schema descriptions for several of the seven parameters.

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?

Specific verb+resource: 'Audit one substrate — or all three — against the seventeen species–function pairs,' with an explicit output shape (which pairs realised/simulated/absent/undetermined). It is clearly distinct from generic status siblings, and it invokes 'the taxonomy' which hints at fcs_taxonomy, but it never names the sibling family (fcs_report, fcs_compare, fcs_stratify) to route the 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?

The audit framing implies when to reach for it (conformance checking), but there is no explicit when-to-use/when-not or named alternative among the many fcs_ siblings. With fcs_report, fcs_compare, and fcs_taxonomy all present, the absence of routing guidance is a real gap.

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, and destructiveHint=false, so the safety profile is covered. The description adds useful content-level context by naming the six categories of information returned per level, including the notable 'gap ASTRA cannot close', but says nothing about output format, size, or whether the per-level text is static.

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 dense sentence with the core resource front-loaded and the enumerated payload following the em-dash. The list is long, but every item conveys a distinct content category rather than restating the name, so it earns its length.

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 only one optional enum parameter, the description carries the return-value burden and does so by naming the per-level fields an agent will receive (formalism, epistemic status, complement reading, ASTRA modules, gap). Only the response shape/format remains unspecified, which is minor for a read-only lookup.

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 the single level enum already documents 'One level; omit for all four.' The description's 'each level's ...' phrasing faintly implies the per-level granularity but adds no syntax or behavioral detail beyond the schema, so baseline 3 applies.

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

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

The description is a noun phrase that enumerates the resource's contents (four levels, each with formalism, epistemic status, ASTRA modules, and gaps) but never states an action verb, so it reads as a topic list rather than 'retrieve X'. It is specific about subject matter but does not distinguish this from close siblings like fcs_taxonomy, fcs_stratify, or fcs_report, which plausibly cover overlapping framework concepts.

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 the many fcs_* siblings, nor any stated preconditions or exclusions. The agent is left to infer usage from the topic 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds that the check is a lint/screen against five named prohibitions, which is real context, but says nothing about what a failure looks like, whether violations are returned or errors raised, or how strictly the check is applied.

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, zero padding, with the core action front-loaded and the usage trigger trailing. Nothing is redundant with the title or annotations.

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, so the description carries the burden of explaining what the screen returns — pass/fail, a violation list, a severity — and it does not. The 'or' wording partially resolves the ambiguity of three all-optional parameters, but for a validation tool whose entire value is its verdict, the return contract is a real 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 the schema already documents all three parameters and their semantics (prohibition 4 for aggregate, prohibition 5 for constitutiveInference). The description's 'or' phrasing usefully signals that these are alternative single-purpose inputs rather than a combined filter set, but adds no syntax beyond the schema. 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 ('Screen') and three concrete resources (a string, an aggregation, a constitutive inference) checked against 'the five prohibitions of the series' negative heuristic'. The verb+resource pair is clear, but it never names or distinguishes itself from look-alike siblings such as fcs_conformance or fcs_withdrawal, so an agent must infer the boundary.

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 trigger: 'Use before emitting any user-facing claim that touches the FCS layer.' That is a clear when-to-use. There is no when-not guidance and no alternative sibling is named for cases where the caller wants a conformance or withdrawal check instead, so it stops short of full routing 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint false, and destructiveHint false. The description adds useful behavioral context beyond the annotations: it specifies the report's components and explicitly states that no aggregate score is returned because of prohibition 4. It does not describe auth, rate limits, or response format, but with annotations covering safety, this is a meaningful addition.

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 two sentences: a front-loaded consolidated status with an enumerated component list, followed by a short prohibition note. It is dense with domain jargon but contains no filler or redundant repetition; every item appears to map to report 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?

Because no output schema exists, the description carries the burden of explaining return content, and it does so by listing the report's components and excluding an aggregate score. The parameter and safety profile are handled by schema and annotations, leaving usage selection as the main 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 coverage is 100% for the single parameter useLiveBiomarkers, whose description explains binding the conformance audit to live IRB welfare channels and that it defaults to true. The tool description adds no additional parameter semantics. Baseline 3 applies because the schema fully documents the parameter.

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 it returns consolidated substrate-constrained functionalism status and enumerates the specific components: the four-level framework, core/belt partition, species-function pairs in Pareto strata, conformance audit, prohibitions, and revision order. It clearly identifies the resource, though it lacks an action verb and does not explicitly distinguish itself from fcs_taxonomy, fcs_conformance, or orch_report.

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 on when to call this tool versus alternatives. The sibling set includes fcs_taxonomy, fcs_stratify, fcs_conformance, fcs_lint, and orch_report, but the description never states conditions for choosing this consolidated report. It only notes an output exclusion.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond that: it enumerates the returned artifacts, states that τ is a parameter with a documented default provenance (document IV v1.3 §2), and warns that reproducing strata does not validate the cuts.

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?

It is front-loaded with the verb and scope, which is good, but the opening sentence sprawls into a long return-value list and is heavy with unexplained domain jargon (document IV §3, eight strata). Considerably denser than needed for a one-parameter 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?

There is no output schema, so the description rightly carries the burden of explaining return values, and it does enumerate them. The main gap is that the enumerated outputs are not structured or ordered clearly, and domain references are left unexplained, but nothing essential for calling the tool is missing.

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?

With one parameter at 100% schema coverage the baseline is 3, but the description goes further by explaining what the τ ordinalisation parameter means in practice — that the default cuts the range's lower bound at 10⁻¹ s then 10⁰ s — adding interpretive meaning beyond the schema's terse 'Ascending decimal-exponent cuts' note.

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: 'Recompute the partial order by Pareto dominance over the three ordinal sub-criteria,' and enumerates the derived artifacts it returns (dominance relation, Hasse diagram, strata). An agent can grasp what it computes, but the description never differentiates it from adjacent fcs_* siblings such as fcs_compare, fcs_levels, or fcs_taxonomy.

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 offers a caveat on interpretation ('Reproducing the strata checks the transcription; it does not validate the cuts'), which implies a verification use case, but it gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. Usage must be inferred from the dense domain phrasing.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds domain context (that ordering is of functions, not substances, and a species may appear twice), which helps interpret results, but it says nothing about whether filters combine, defaults, or the shape of the return.

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 with no obvious padding, and the field list is front-loaded. However, the first sentence is a dense wall of unglossed jargon (distance to carrier d, time-constant range τ, ablation degree) that costs more reading effort than it earns.

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

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

This is a read-only, no-output-schema lookup whose safety profile is fully carried by annotations, so the description needn't explain return values. It supplies the key conceptual caveat about function-ordering, which is genuinely useful, though it omits how the three filters behave together.

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 fully documents role, pairId, and stratum. The description echoes two of these (causal role, Pareto stratum) but adds no syntax or semantics beyond the schema, leaving the baseline 3 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 conveys that this exposes an FCS species–function taxonomy (thirteen classes as seventeen pairs, with fields like causal role and Pareto stratum), but it uses no clear action verb and never says whether the tool lists the whole taxonomy, queries it, or returns one pair. It also does not differentiate itself from closely-named siblings such as fcs_levels, fcs_stratify, or fcs_report.

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 when-to-use guidance, no mention of the filtering options, and no alternative or exclusion named. An agent has to infer that this is the taxonomy lookup versus fcs_levels or fcs_stratify purely from the 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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description goes meaningfully beyond that by disclosing evaluation semantics that are not in the schema: unset outcomes never collapse to a negative, and a favourable human-grain outcome does not corroborate M2 because the methodological bias favours the field. That asymmetry is genuine behavioral context an agent could not derive from structured fields.

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 dense sentences that front-load the core action and then add the decisive null-handling rule. Little waste, though the second half leans on undefined jargon (M2, human grain) that compresses at the cost of comprehension.

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, no annotations on parameter meaning, and 0% schema coverage on 8 flags, the description should explain what the inputs represent and roughly what comes back. It supplies the undetermined-collapse rule but leaves every parameter and the entire result shape unexplained, which is a serious gap for a tool whose whole surface is these eight flags.

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% across 8 parameters, so the description must carry the burden, and it largely does not. It explains the null/unset convention in general terms but never maps any of the concrete flags (bridgeCovariation, experimentRankedByM1, ephapticPropagationUnderBlockade, etc.) to the theses they govern. An agent still cannot tell what a given boolean actually asserts.

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 (evaluate) and resource (the protective belt / withdrawal conditions), and states what the evaluation yields: which theses are withdrawn, stand, undetermined, and what survives each withdrawal. That is more than a restatement of the name. It stops short of distinguishing itself from the many other fcs_* siblings (fcs_report, fcs_conformance, fcs_stratify), so an agent cannot route between them on the strength of this text alone.

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 explicit when-to-use directive, no prerequisites, and no mention of any alternative tool. The agent must infer that this is called after experimental outcomes are known, but nothing states the trigger condition or which sibling to prefer instead. Usage is only implicit for a domain-jargon task.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuine context by disclaiming that no consciousness class or level is derived and citing FCS prohibitions, but it does not describe the returned structure, scale, or value ranges of the index.

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

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

Two tight sentences, front-loaded with the definition before the disclaimer. The only friction is the opaque 'FCS prohibitions 1 and 4' reference, which assumes prior context but costs little space.

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 explaining the return value, and it only says the result is three proxies plus a weighted sum without naming the fields or their range. For a zero-parameter read-only tool this is adequate but leaves the shape of the response unspecified.

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

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

The tool takes zero parameters, so the baseline is 4. There is no parameter surface for the description to clarify or 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 names the specific resource — an engineering index of the simulation composed of three IIT/GWT/PAD-inspired proxies and their weighted sum — and explicitly scopes it as not a consciousness measurement. It is clear what the tool returns, though it does not differentiate itself from metric-adjacent siblings like get_metrics or tcai_metrics by name.

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 explicit when-to-use statement or named alternative. The clause 'no class or level is derived' weakly implies that classification tasks belong to a different tool (e.g. fcs_stratify/fcs_levels), but this is left entirely to inference rather than stated as routing 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description adds nothing beyond the title – no scope, no freshness/caching semantics for 'real-time', no cost. No contradiction with annotations, but zero added context.

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 words with no waste, but this is under-specification rather than conciseness – the same failure mode as a description that is simply the tool name. There is no front-loaded substance to speak of.

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 parameters, the description carried the full burden of telling the agent what this returns and when it is the right choice among ~70 siblings. 'Real-time Metrics' leaves the agent unable to know what data it gets back or how it differs from tcai_metrics or get_system_status.

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

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

The tool takes zero parameters, which is the baseline-4 case per the rubric. Schema coverage is 100% and there is nothing for the description to clarify about call syntax.

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 the title restated verbatim: a bare noun phrase with no verb and no indication of what 'metrics' means or what is measured. It does not distinguish the tool from metric-adjacent siblings such as tcai_metrics, get_system_status, or get_acm_score. This is a tautology of the name/title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to call this tool, what precedes or follows it, or how it differs from the many other status/metrics siblings. The description gives the agent nothing to reason about for 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is carried entirely by structured data. The description adds nothing beyond that — no scope, no freshness, no coverage of which platforms are reported — but it does not contradict the 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?

It is a single fragment with no waste, but that is under-specification rather than conciseness: there is no front-loaded statement of purpose for a reader to latch onto.

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

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

With no parameters, no output schema and no description of the returned status, an agent cannot tell what this tool returns or how it differs from the many other status/metrics siblings. For a no-argument query tool the description is the only place this could be conveyed, and it is absent.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to clarify beyond what the empty schema already states.

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 only 'Bio-Computing Platforms', a noun phrase identical to the annotation title, so it tautologically restates the title rather than naming an action. It never says what 'platform status' means or what is reported, and it is indistinguishable from siblings such as get_system_status, np_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 when-to-use guidance, no prerequisites, and no mention of any alternative. With over fifty siblings including several other status tools (get_system_status, sensor_status, wm_status, np_status), the agent gets no basis for choosing this one.

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered externally. The description adds nothing beyond that — no scope of the state snapshot, no freshness/live-vs-cached semantics, no cost. With the bar lowered by annotations, a 2 reflects zero added context.

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 words are certainly concise and front-loaded, but the phrase is under-specification rather than disciplined brevity — it conveys no information. There is no waste to trim, yet no substance either.

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

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

With no parameters, no output schema, and a large sibling set of similarly named state/metrics readers, the description carries the burden of explaining what this state read covers and how it differs from the alternatives. It does none of that, leaving the agent unable to select it confidently.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param tool is 4. The empty schema is self-explanatory.

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 just the tool title restated as a noun phrase ('SNN Engine State'), which is a near-tautology of the name get_snn_state. It never states what the tool actually returns or what 'state' comprises, so an agent cannot distinguish it from get_system_status, get_metrics, np_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 indication of when this tool should be used, when it should not, or which of the many sibling status/metrics tools is the alternative. The agent is left to guess entirely from the 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing beyond the title — no indication of what the status covers, whether it is cached, or how it relates to other status tools.

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 single fragment is short but this is under-specification, not conciseness. There is no front-loaded statement of purpose or scope to anchor the agent.

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 parameters, so the description carries the entire burden of explaining what status data is returned and at what granularity. It says nothing, leaving an agent unable to predict the return content in a crowded namespace of 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 takes zero parameters, so there is no parameter semantics burden and the baseline is 4 per the rubric. There is nothing for the description to document here.

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' merely restates the tool name/title without a verb or any indication of what status means here. With siblings like get_metrics, get_platform_status, ovo_status, wm_status, np_status, and sensor_status, there is no way to distinguish this tool's scope from theirs.

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 contains no guidance whatsoever on when to use this tool versus the many sibling status/metrics tools. Nothing indicates prerequisites, context, 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?

Annotations already disclose the key traits: not read-only, not idempotent, not destructive, closed-world. The description adds no behavioral context such as what the strength units mean, how injected spikes persist, or whether the call mutates network 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?

It is short, but that brevity reflects under-specification rather than efficient structuring. There is no front-loaded statement of purpose beyond a two-word fragment.

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 mutation tool with no output schema and completely undocumented parameters, the definition is inadequate. An agent has nothing to reason about regarding effects, scope, or return values.

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 says nothing about the two parameters. The meaning of 'strength' (bounded -100..100, default 15) and the expected neuronIds form are entirely undocumented.

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 'Spike Injection', which merely restates the tool name/title. It does not clarify what a spike is, what gets injected, or how this differs from the many simulation/neuron siblings such as np_send_trigger 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?

No when-to-use guidance, no prerequisites, and no mention of any alternative tool. An agent cannot tell from this text when injection is appropriate versus stepping the network or sending a trigger.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered elsewhere. The description's only real addition is 'Last', which weakly implies retrieval of an existing capture rather than a new acquisition, and 'descriptor + viability' which hints at return contents. That is thin added context for a tool whose output has no schema.

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?

It is short, but it reads like a banner label rather than a front-loaded sentence: a platform name, an em dash, and a parenthetical, with no leading verb. Brevity here comes from under-specification rather than tight writing.

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 is the only place to explain what 'descriptor' and 'viability' mean and whether a frame is acquired or recalled; neither is explained. The zero-required-parameter design also isn't surfaced, so the agent cannot tell whether omitting 'mea' is valid or what the default 5 means behaviorally.

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 single 'mea' parameter is documented with a range and default in the schema, so the baseline of 3 applies. The description adds no additional meaning about the MEA selector or what values map to.

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 resource and an action ('MEA camera capture') and hints at the payload ('descriptor + viability'), so the general purpose is inferable. However, it is fragment-like and never states a clear verb such as 'retrieve the most recent frame', and it does nothing to distinguish itself from sensor_visual or other capture-like 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling tools. An agent has to guess whether this triggers a new capture or fetches a cached one, and when to prefer it over sensor_visual.

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 destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the agent knows this mutates state, but the description frames the operation as 'read organoid → couple' and never discloses what is destroyed or that effects are non-reversible. It adds coupling detail (ROS/ethics, optional SNN drive) but leaves the destructive consequence that the annotations flag unexplained.

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?

It is a single arrow-chained line that is front-loaded and free of padding. However, the telegraphic phrasing is compact at the cost of readability, which limits how much structure it actually provides.

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 multi-step coupling pipeline with four parameters, a destructive mutation hint, and no output schema, the one-line description is too thin. It never explains return values, what 'couple to ethics' writes, or the effect of window_ms, so an agent cannot fully predict the call's outcome.

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 75%, so most parameters are already documented in-schema. The description only clarifies the conditional gating of drive_snn and adds no detail about window_ms or drive_strength semantics. Baseline 3 is warranted when the schema does most of the work.

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

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

The description names a specific compound operation: reading an organoid, coupling it to ASTRA fusion/ROS/ethics, and optionally driving the SNN. The verb chain is clear enough to distinguish it from read-only status siblings like get_snn_state or check_ethics, but it leans on platform jargon (ASTRA, ROS, IRB ethics gateway) and never explicitly contrasts it with the closer 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?

There is no when-to-use guidance, no prerequisites, and no named alternative. The word 'optionally' and the link to the drive_snn parameter hint at behavior but do not tell an agent when this closed-loop tool should be chosen over snn_step, inject_spikes, or check_ethics. Usage is only obliquely 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?

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety profile is partly covered. The description adds useful context that this is an upload of a validated, charge-balanced biphasic StimParam, but it never explains what the destructive hint destroys, whether it overwrites an existing config, or what validation failure 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?

A single front-loaded phrase with no padding or repetition, naming the platform, the action, and the artifact. It is tight, though extremely terse given the complexity of the 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?

With 11 parameters, no required fields, and no output schema, an agent has enough from schema (82% coverage) and annotations for the safety profile, but the description omits what a successful upload returns, how validation/charge-balance rejection surfaces, and how this differs from set_parameter. Adequate but with clear gaps for a 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 82% (above the 80% baseline), so the schema already documents parameters such as electrode index, phase durations/amplitudes, and enforce_charge_balance. The description contributes only the domain framing of 'charge-balanced biphasic stimulation' and adds no syntax, unit, or interdependency 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?

The description gives a specific verb chain (Define, validate & upload) plus the resource (a StimParam / charge-balanced biphasic stimulation), so an agent knows this configures stimulation parameters. It does not, however, explicitly distinguish itself from siblings like set_parameter or np_send_trigger, which also write stimulation-related 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?

There is no when-to-use, when-not-to-use, or alternative-tool guidance. With 60+ siblings including set_parameter, np_send_trigger, and np_closed_loop, the agent gets no signal on which path to choose or what prerequisites (e.g., platform connected, stimulation armed) apply.

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 reveal readOnlyHint=false and idempotentHint=false, and the annotation title discloses '(advances MEA clock)'. The description itself, however, never states this side effect — the most important behavioral trait — nor does it say what state changes or whether results are repeatable. 'Closed-loop' hints at it but adds little beyond the 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?

It is a single short sentence, which is appropriate, but the 'NeuroPlatform v2 —' prefix and the underscore internal name are low-value noise, and the useful part (what is counted, over what window) comes only after the 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 stateful, non-idempotent closed-loop operation with a near-duplicate sibling, the description omits the essential context: that it advances the MEA clock, how it differs from np_query_spike_count, and what default behavior (0 required params) means. It is too thin for a mutating tool with no output schema.

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% — top_k and window_ms are each documented in the schema. The description's 'over an N-ms window' simply restates window_ms and adds no syntax, format, or interaction detail, so the baseline 3 for schema-covered params 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 clause 'spikes per electrode over an N-ms window' states a specific verb (count) and resource (spikes per electrode), so an agent can tell what it computes. However, it never differentiates itself from closely named siblings like np_query_spike_count or np_query_spike_events, and the internal name '_count_spike' adds jargon rather than clarity.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. Given the near-identical sibling np_query_spike_count, the description should say why an agent would pick this closed-loop counter over that query tool, but it offers nothing.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds the computational semantics (per-electrode rate, time-windowed), which is useful, but says nothing about return shape, sim-clock behavior, or cost/rate limits. With annotations doing the heavy lifting, a 3 is appropriate.

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 compact, front-loaded line with no filler; the metric and scope appear immediately. Its brevity is a virtue structurally, though the space saved is spent on nothing that would aid invocation.

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 query tool with three parameters, one undocumented option, and no output schema, the description is too thin: it omits output format expectations, sibling routing, and the meaning of nonzero_only. Annotations cover safety but the description leaves key invocation details unaddressed.

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 only 67%: fsname and window_sec are documented, but nonzero_only has no description anywhere. The description adds no parameter meaning of its own (no explanation of fsname values, window semantics, or the nonzero_only filter), so it fails to compensate for the gap.

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 and metric (spikes/minute per electrode over a time window) and identifies the platform (NeuroPlatform v2 DB). However, it does not distinguish this from closely-named siblings like np_count_spikes, np_query_spike_events, or np_query_triggers, so an agent cannot tell which to pick without opening schemas.

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 when-to-use guidance, no prerequisites, and no mention of the obvious alternatives (np_count_spikes, np_query_spike_events). The agent is left to infer selection from names 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, fully covering the safety profile. The description adds only one behavioral hint beyond that — that results are per-spike (individual timings), implying potentially large result sets — but says nothing about pagination, the limit cap of 2000, or result shape. Adequate but thin given the annotations carry the safety burden.

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 short line with no filler and the resource named up front, so it is not padded. But its brevity reflects under-specification rather than disciplined conciseness — there is almost no content to front-load.

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 3-parameter query tool with no output schema and only 33% schema coverage, the description leaves major gaps: it never explains what fsname refers to, the meaning of the window unit, or what a caller should expect back. An agent could invoke it but not with confidence about the identifier or result scope.

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, 'Look back this many seconds', is documented), and the description supplies no parameter meaning at all. The cryptic fsname (default 'fs264') and limit are undocumented in both description and schema, so the description fails to compensate for the coverage gap.

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 resource (spike events) and clarifies the return granularity ('individual spike timings over a window'), which implicitly distinguishes it from the count-oriented siblings np_count_spikes and np_query_spike_count. However, it is framed as a database tagline ('SpikeEventQuery') and never names an alternative or explicitly contrasts with the count tools, leaving differentiation to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus alternatives such as np_query_spike_count or np_query_triggers, nor any prerequisite or exclusion. 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only that this is a DB query over a window; it does not describe return format, pagination, or any rate/auth constraints. With annotations carrying the safety load, a 3 is appropriate.

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

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

A single front-loaded sentence with no wasted words. The internal 'NeuroPlatform v2 DB — TriggersQuery:' prefix is slightly redundant with the annotation title but does not obscure the meaning.

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

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

Simple read-only query with two fully described parameters and strong safety annotations, so an agent can invoke it. However, no output schema exists and the description never hints at the return shape (e.g., list of triggers, timestamps), leaving some inference to the 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 description coverage is 100%, so both parameters (dedup, window_sec) are fully documented in the schema. The description merely echoes the window concept without adding syntax or behavioral nuance beyond the schema. 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 (query) and resource (triggers sent to the organoid) with scope (over a window). This implicitly distinguishes it from np_send_trigger, but no sibling tool is named for explicit differentiation.

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 when-to-use, when-not, or alternative guidance is provided. The agent can infer it retrieves historical trigger data from the purpose, but there is no explicit routing 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?

Annotations already declare the safety profile (destructiveHint=true, idempotentHint=false, openWorldHint=false), so the description is not the only source of behavioral information. It adds that the tool executes previously uploaded StimParams through a trigger array, but says nothing about authorization/hardware preconditions, whether the call blocks, or what effect repeats has on the physical system.

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 action verb, with no filler or repetition. The 'NeuroPlatform v2 —' branding prefix is decorative rather than informative, which keeps it just short of 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?

With no output schema and a destructive, non-idempotent hardware-facing action, the description should do more: it never states that StimParams must be uploaded beforehand, what the trigger values map to physically, or what a response indicates. The safety signal is carried by annotations, so the gap is not severe, but the description is thin for the operation's impact.

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

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

Schema description coverage is 100%, so both parameters (triggers, repeats) are already documented in the schema, making 3 the baseline. The description's '16-bit trigger array' adds little and is arguably imprecise, since the schema constrains each element to 0-15; it does not clarify the 'sends trigger 2' example or the repeats semantics beyond what the schema states.

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 pairs a specific verb ('Fire trigger(s): execute uploaded StimParams') with a concrete resource and mechanism (a trigger array), so an agent knows this sends stimulation triggers rather than querying them. It does not distinguish itself from near neighbors such as np_query_triggers, np_configure_stim, or np_closed_loop, leaving the boundary 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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative. The phrase 'uploaded StimParams' hints at a prerequisite (stimulation params must already be configured/uploaded, presumably via np_configure_stim), but this is inferred rather than stated, and nothing says when to prefer this over np_closed_loop or np_configure_stim.

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=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds nothing behavioral beyond the headline — no mention of what the status snapshot reports (health, controller state, uptime) or whether it is cheap/cached.

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?

It is a single front-loaded line with zero padding, which is structurally fine, but it is under-specified rather than concise — the terseness comes from omitting information rather than from tight editing.

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?

No output schema exists and the annotations only cover safety, so the description is the only place to say what a 'status' payload contains. It never does, nor does it disambiguate from the many sibling status/metrics tools, leaving an agent unable to predict the return value.

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

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

The tool takes zero parameters, so the schema carries no semantics to explain; per the rubric this is the baseline 4 by default. The description neither helps nor hurts here.

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 essentially the tool's title restated: 'Platform & Controller Status' adds a scope word ('Controller') but no verb and no distinguishing feature. With siblings named get_platform_status, get_system_status, get_snn_state, wm_status and sensor_status, an agent cannot tell which status endpoint this is or how it differs.

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 when-to-use, when-not-to-use, or alternative mention at all. Given at least four sibling status tools in the list, the absence of any routing guidance is a real gap, though it is not misleading.

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=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond them: the mass-displacement scale is exposed as a free parameter and the tool performs a sweep across four orders of magnitude, meaning the invocation is not a single scalar evaluation. It stops short of describing the actual return shape.

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 dense sentence with no filler, front-loaded on the criterion being computed and immediately followed by the two facts that distinguish the call (free parameter, sweep range). Every clause earns 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?

For a read-only three-parameter computation with no output schema, the description should at least hint at the return shape, and the 'sensitivity sweep' clause is the only clue that output is multi-valued rather than a single τ. The compute semantics are covered but the result contract and any domain caveats (e.g. interpretation of the back-calibrated separation default) are not.

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 three parameters (massKg, separationM, tubulinCount) are already documented with defaults and bounds. The description's mention of a free mass-displacement scale maps loosely onto separationM but adds no format, units, or interaction detail beyond the schema — baseline score 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 names a specific scientific quantity (Penrose objective-reduction criterion τ = ℏ/E_G) and states its distinctive behavior — a free mass-displacement scale plus a sensitivity sweep. That content clearly separates it from siblings such as orch_decoherence or orch_gate_config, but no sibling is named explicitly, and the verb is only implied by the nominal phrasing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool, no prerequisites, and no mention of the adjacent orch_decoherence/orch_cycle tools an agent might confuse it with. The agent must infer usage purely from the physics formula.

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, idempotentHint=false, openWorldHint=true, destructiveHint=false, so the safety/mutation profile is partly covered. The description adds the useful detail that it reports integrated epoch counts, but it does not disclose what state the TCAI cycle or surrogate gate mutates, nor any rate or consumption constraints. Some added value, but thin for a stateful composite.

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 dense, front-loaded sentences with no filler; the action pipeline comes first and the reported result last. Jargon-heavy but structurally 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?

For a multi-stage stateful operation with no output schema and one undocumented parameter, the description leaves key gaps: what the cycle does to state, what a returned epoch count implies, and any preconditions. Annotations cover only the safety profile.

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% for the single 'controllability' parameter (0-1), and the description never mentions it or its effect on the gate/cycle. With the schema silent and the description silent, the caller has no basis for setting this value.

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 three-step operation (read OVOMIND affect frame, run TCAI cycle, pass workspace competition through the surrogate gate) and states the reported output (epoch count). It is specific but does not distinguish itself from closely named siblings such as tcai_cycle, ovo_cycle, or orch_substrate, so an agent cannot tell why it should pick this composite over those.

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 when-to-use guidance, no prerequisites, and no mention of when *not* to call it versus tcai_cycle or ovo_read, which appear to overlap. The agent is left to infer the orchestration role 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the useful behavioral fact that the output is a comparison between two models and a residual gap, but says nothing about return format or precision. A 3 reflects modest added value over the 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?

A single front-loaded sentence with no filler; the resource is named first and the models are cited economically. Jargon (Tegmark 2000, HHT 2002) is dense but appropriate to the domain.

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 conveying what is returned. It hints at a comparison plus a residual gap but does not describe the shape or meaning of those results, and the lone input parameter lacks unit/format detail. Adequate but with clear gaps for a physics-computation 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 single parameter requiredCoherenceS is undocumented structurally. The description partially compensates by naming it as a 'target coherence window', but it never states units, format, or bounds — a gap only partially filled by the parameter name's 'S' suffix.

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 computational resource — the decoherence time budget for a coherence window, computed as Tegmark (2000) vs the Hagan/Hameroff/Tuszyński (2002) correction plus the residual gap. That is a concrete verb+resource combination. However, it does not differentiate itself from nearby siblings such as orch_criterion or orch_substrate, leaving the agent to infer the boundary.

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 indication of when to call this tool versus alternatives like orch_criterion or orch_substrate, nor any prerequisite or context for the coherence window value. The description only says what is computed, not when it is the right 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?

Annotations already declare readOnly=false, destructive=true, idempotent=true, and openWorld=false. The description adds useful conceptual context about the surrogate gate and its limitation, but does not disclose what is destroyed or what operational side effects occur for this destructive mutation.

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 then the scope limitation. There is no filler, and the structure is appropriate for the information provided.

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 4-parameter configuration mutation with no output schema and no schema parameter descriptions, the definition is incomplete. It lacks parameter semantics, defaults, and behavioral effects of enabling or configuring the gate.

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 4 parameters with 0% description coverage. The description mentions 'epoch-quantised ignition' and 'stochastic tie-break', which loosely hint at epochMs, ignitionFloor, and tieBandFraction, but it never names parameters, explains ranges, defaults, or effects.

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 ('Enable or configure') and resource ('classical surrogate gate'), with mechanism details and a scope disclaimer. It distinguishes this gate config from objective-reduction Orch OR tools, though it does not explicitly name sibling 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 explicit when-to-use guidance or alternative sibling is named. The second sentence provides a scope exclusion ('does not instantiate objective reduction'), which implies usage boundaries but does not route the agent to 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world scope, so the safety profile is fully covered. The description adds the content scope (which sections the report contains), which is useful, but says nothing about cost, latency, or return format.

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

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

A single front-loaded sentence that enumerates the report's contents without padding. Every clause carries informational weight 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?

With no parameters, no output schema, and annotations covering the safety profile, the remaining burden is telling the agent what comes back — and the description enumerates the four content areas. It is nearly complete, though the sibling-overlap ambiguity (report vs. the individual orch_* tools) is unaddressed.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema is empty and correctly so for a no-arg report call.

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

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

States a clear verb+resource (a consolidated Orch OR status report) and enumerates the specific content it covers: epistemic standing, Penrose criterion at 2×10¹⁰ tubulins, decoherence budget, and per-substrate verdicts. However, it does not distinguish itself from siblings like orch_criterion, orch_decoherence, and orch_substrate, whose subject matter it overlaps.

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 word 'Consolidated' implies this is the aggregate/overview call an agent should reach for instead of the granular siblings, but that is left to inference. There is no explicit when-to-use, when-not-to-use, or named alternative.

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 readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds useful output content (the verdict comprises a tubulin budget, per-observation epochs, and reasoning) but no output schema exists, and it does not explain what inputs drive the verdict or whether it is a pure 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?

A single front-loaded sentence that names the subject before enumerating outputs, with no filler. It is efficient, though the enumeration style leaves the reader with terminology (ASTRA, tubulin budget) that is never grounded.

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 what the verdict contains, which is its strongest contribution. However, it leaves all three parameters unexplained and gives no guidance on sibling selection, so a 3-parameter mutation-free tool still has clear informational 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 0%, so the description carries the full burden, yet it never mentions substrate, neuronCount, or channelLatencyMs. Only 'for one substrate' and 'through ASTRA's channel' hint obliquely at the substrate enum and latency input, leaving two of three parameters undocumented anywhere.

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 domain object (an Orch OR verdict for one substrate) and enumerates its components: tubulin budget, epochs elapsed per observation through ASTRA's channel, and reasoning. An agent can tell this is a verdict-producing tool rather than one of the sibling orch_* compute/config tools, though it never states whether the verdict is computed or retrieved.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as orch_decoherence, orch_criterion, or orch_report. The agent must infer usage entirely from the name and the 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?

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds genuinely new behavioral context: arming puts a human subject inside the control loop (a consequential side effect) and requires a protocol reference or the call is refused. That refusal condition is not visible in the annotations or schema.

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 core operation front-loaded and the precondition following. No filler or redundant restatement of the tool name.

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

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

For a single-boolean mutation tool with no output schema, the description covers the operation, its consequence, and its gating condition. The one loose end is that the stated 'protocol reference' requirement has no corresponding parameter in the schema, leaving the agent unsure how that precondition is satisfied.

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?

There is one parameter (arm, boolean) with 0% schema description coverage, so the description's 'Arm or disarm' gives only the obvious polarity. It does not clarify the default, the effect of omitting it, or how it interacts with the protocol-reference precondition.

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 pair (arm/disarm) and a specific resource (closed-loop affective actuation), which distinguishes it from the many sibling ovo_ tools like ovo_set_policy or ovo_cycle. An agent can identify the operation without opening the 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 a precondition (arming is refused without a protocol reference) but never states when to choose this tool over alternatives such as ovo_set_policy or the closed-loop siblings. Usage context is implied rather than spelled out.

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 disclose that this is not read-only, is open-world, non-idempotent, and non-destructive. The description adds meaningful behavioral context by specifying that the human channel enters as the body specialist and that human valence is not routed to rewardSignal, which is useful routing information beyond the 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 two tight sentences with no filler. The core action is front-loaded, and the routing exception follows immediately, so every sentence earns 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?

For a non-read-only cycle tool with no output schema, the description omits return behavior, side effects, prerequisites such as an armed controller for actuate, and usage context. Annotations cover the safety profile, but the description leaves too much unspecified 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 only 50%, and the description does not clarify the two parameters (actuate and controllability) or their effects. Since the schema already describes actuate but leaves controllability undocumented, the description fails to compensate for the coverage gap.

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 compound action: read one affect frame and run a TCAI cycle, with a routing caveat about the human channel. It is clear within the OVOMIND/TCAI domain, but it does not differentiate itself from the sibling tools tcai_cycle or ovo_read, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but gives no guidance on when to use it versus alternatives such as ovo_read, ovo_status, or tcai_cycle. There are no explicit when/when-not conditions or recommended contexts.

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 non-open-world, so the safety profile is covered. The description adds useful content framing (three substrates, the axes each constrains, the caveat blocking naive isomorphism) but says nothing about output form, cost, or determinism beyond what annotations imply.

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 dense sentence with the comparison subject front-loaded and no filler. It is appropriately sized, though the trailing 'caveat that blocks a naive isomorphism claim' phrase is slightly abstract and could be more concrete.

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-argument read tool with no output schema, the description should carry the burden of describing the returned structure, and it only gestures at it ('axes each can constrain', 'caveat'). It is enough to know what the tool is about, but not enough to anticipate the shape of 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 takes zero parameters, so per the rubric the baseline is 4. The description legitimately clarifies what the parameterless call compares rather than leaving the agent guessing, though it adds no argument semantics to disambiguate.

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 action (side-by-side comparison) and a concrete resource scope (the three substrates feeding the same PAD pipeline), so an agent knows exactly what it returns conceptually. It does not, however, explicitly contrast itself against the many sibling orchestration tools (orch_substrate, ovo_read, ovo_status), so differentiation is left to inference.

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 is only implied: an agent can guess this is the tool to call when evaluating an isomorphism claim across substrates, but there is no explicit 'use this when...' or 'do not use instead of ovo_read/ovo_status' guidance. With dozens of ovo_/orch_ siblings, an explicit routing sentence would materially help.

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=true, destructiveHint=false and idempotentHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond that: every axis is returned with epistemic tier, provenance and basis string, and dominance is never inferred from the human channel. It still does not explain what 'PAD' or an 'epistemic tier' is, nor the polling cadence for a non-idempotent read.

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 with the action front-loaded, no filler. The final sentence on dominance is terse and slightly cryptic, but each sentence contributes information.

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 does some of the load-bearing work by describing the returned fields, and annotations cover safety. However, key domain terms (PAD, epistemic tier, dominance vs human channel) are undefined and the lone input parameter is unexplained, so an agent can select the tool but cannot fully reason about its contract.

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 single parameter 'controllability' (a 0-1 number) is never referenced in the description. With a non-zero parameter count and no schema descriptions, the description carries the burden and adds nothing, leaving the parameter's meaning and units unknown.

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: 'Poll one OVOMIND affect frame and lift it into PAD', and adds what the result contains (each axis with epistemic tier, provenance and basis string). It is clear what the tool does, though it never names a sibling (ovo_status, ovo_cycle, ovo_isomorphism) to disambiguate it within the crowded OVO family.

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?

'Poll' implies retrieving a current frame, but there is no explicit when-to-use, no preconditions, and no mention of the sibling tools such as ovo_status or ovo_cycle that an agent would otherwise consider. The agent is left to infer selection entirely.

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, idempotentHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered. The description adds essentially nothing beyond that: it does not say what existing policy is overwritten, that setting protocolReference arms the loop, or what the destructive side effect is. Given the destructive flag, this is a meaningful 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?

A single tight sentence with no waste, and the resource being configured is front-loaded. It is appropriately sized; the problem is omission rather than padding.

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, destructive, non-read-only config tool with no output schema and 20% schema coverage, this description is far too thin. It omits the effect of each setting, what gets overwritten, and when to prefer it over the related control/parameter 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?

Schema description coverage is only 20% (just protocolReference), so the description must compensate and does not. It never explains the dominancePolicy enum values (prior, endogenous, withhold), the arousalSetpoint range, or maxStepPerCycle semantics, leaving four of five parameters undocumented in both places.

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 ("Configure") and two named resources (the Russell→PAD dominance policy and the closed-loop control policy), so an agent can identify it as a policy-write tool. It is distinguishable from read/status siblings (ovo_status, ovo_read), but it does not differentiate from overlapping config siblings such as ovo_arm_control or set_parameter, and the "Russell→PAD" jargon is unexplained.

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 when-to-use or when-not-to-use guidance and no mention of alternatives, despite clear overlap with ovo_arm_control (which also concerns the control loop) and set_parameter. The agent gets no signal about which tool to select for policy setup versus arming versus generic parameter writes.

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 the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds meaningful value by enumerating what the status actually surfaces, notably the synthetic-phenomenology ethics assessment, which is not derivable from any structured field.

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 dense sentence that front-loads the resource ('OVOMIND bridge status') and then lists its components. No filler, though the long enumerated payload makes it slightly list-heavy rather than crisp.

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 input parameters and no output schema, the description is the only source of return-value information, and it names the key components including the ethics assessment. It is nearly complete for a status tool, missing only how/when it should be invoked or refreshed.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description does not need to explain inputs and correctly focuses on outputs instead.

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: it reports the OVOMIND bridge status, and enumerates the concrete contents (adapter mode, substrate descriptor, frame counters, ethics assessment). This clearly separates it from read/write siblings such as ovo_cycle or ovo_set_policy, though it never explicitly contrasts itself with lookalikes like get_system_status or ovo_isomorphism.

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 when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling status/telemetry tools (get_system_status, get_metrics, np_status). The agent must infer timing and context entirely on its own.

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/destructiveHint=false, covering the safety profile. The description adds a genuinely useful behavioral fact — the MLP is untrained, so emitted latents are not semantically meaningful — but says nothing about cost, determinism, or the shape/range of the output.

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 compact parenthetical fragment with zero filler; the pipeline is front-loaded. It is efficient, though the terse telegraphic style asks the reader to decode 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?

For a tool with a nested six-property object and no output schema, the description covers the what and the 'untrained' caveat but omits when to use it, typical input scenarios, and the nature of the returned latent. Annotations carry the safety profile, but usage context is missing.

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 input fields (source, channels, simulate, frequency, durationMs, sampleRate) are already documented in the schema. The description adds no format or range detail beyond that, so 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 resource and operation: audio encoding, with the transformation pipeline spelled out (waveform → Mel → latent). The 'untrained MLP' qualifier adds meaningful scope, and 'audio' distinguishes it from sensor_visual/sensor_olfactory siblings, though it doesn't explicitly compare itself to them.

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 on when to call this versus sensor_process, sensor_fuse, or the visual/olfactory sensor tools. It describes what the tool is but never states the conditions or context that should trigger its use.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered without the description. The description adds nothing beyond that – no mention of what is fused, what the fused output represents, 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 text is short, but it is under-specified rather than concise – a bare label with no front-loaded verb or scope. Length is not the problem; absence of information is.

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 three-parameter fusion tool with an entirely undocumented schema, no output schema, and many plausible siblings, the description supplies none of the context needed 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 0% for three parameters (includeAudio, includeVisual, includeOlfactory). The description does not name or explain any of them, so an agent cannot tell what toggling each flag does or what the defaults imply.

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 the same noun phrase as the title, 'Cross-Modal Attention Fusion', with no verb and no statement of what operation is performed. It hints at the domain (fusing modalities, consistent with sibling tools sensor_visual/sensor_audio/sensor_olfactory) but is effectively a restatement of the title rather than a 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?

There is no guidance on when to call this tool versus sensor_process, sensor_status, or the individual sensor_* tools, nor any mention of prerequisites. The agent is left to infer entirely from the name that this performs fusion across modalities.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully clarifies that this is fully simulated with 'no hardware', which is context annotations cannot convey, but says nothing about determinism, latency, or output form.

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 compact sentence with the transformation front-loaded and the simulation caveat in parentheses. It earns its place, though the parenthetical trivia is arguably lower value than stating the return format.

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, no-output-schema tool, the description should indicate what the 'latent' output looks like (dimension, format). 'chemoreceptors → latent' gestures at it but is not enough for an agent to consume the result confidently.

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 reported at 100%, so the nested properties (compounds, concentrations, numReceptors, temporalPhase, neuronViability) are the schema's responsibility. The description adds no meaning about units, defaults, or how receptor count affects encoding, so 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 transformation (olfactory encoding) on a specific resource, with 'chemoreceptors → latent' indicating input and output direction. The 'Koniku Kore-inspired' jargon and lack of an explicit sibling reference (sensor_visual, sensor_audio) keep it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus sensor_visual, sensor_audio, sensor_fuse, or sensor_process. The description only characterizes the mechanism, not the conditions that should route an agent here.

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=true, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds essentially nothing beyond those annotations – no ordering of modality processing, no cost/rate behavior, and no indication of what 'fused z' represents as a result.

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?

It is short, but this is under-specification rather than conciseness: a single noun-phrase fragment that omits the verb and any operational detail. There is nothing to front-load because almost nothing is said.

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 pipeline tool with three optional parameters that evidently orchestrates multiple modalities, the description explains neither its behavior, the meaning of the 'fused z' output, nor how it relates to the per-modality and fusion siblings. Annotations cover safety only, so the behavioral gap remains.

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 compounds, visualSource, and audioFrequency are already documented in the schema; the baseline for full coverage with no added insight in the description is 3. The description adds no parameter-level meaning (e.g. how modalities combine).

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 fragment identifies the resource ('Full Multimodal Pipeline') and the effect ('All Modalities → Fused z'), which distinguishes it from the single-modality siblings sensor_visual/sensor_audio/sensor_olfactory. However, it uses no verb and gives no concrete statement of action, leaving it ambiguous versus 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?

There is no when-to-use guidance and no mention of alternatives, despite several close siblings (sensor_fuse, sensor_visual, sensor_audio, sensor_olfactory, sensor_status). The agent must infer from the name alone whether this replaces or subsumes the individual sensor 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description contributes nothing beyond that — no information about what the pipeline status comprises, whether it is cheap or expensive, or how fresh the reading is — so it adds no value over the 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 a single short phrase with no wasted words, so it is structurally lean. However, brevity here comes from under-specification rather than disciplined concision — it is a title, not a 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 no-parameter status tool in a large cluster of overlapping status/probe tools, an agent needs to know what this status covers and how it differs from get_system_status or np_status. No output schema exists to fill the gap, and the description provides no scope or return-value 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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-related gaps exist.

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 essentially a restatement of the name and title ('Multimodal Sensor Pipeline Status'), with no verb and no indication of what is actually returned or checked. It does not distinguish this tool from the many sibling status tools such as get_system_status, np_status, wm_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 call this versus the other status/probe tools in the cluster; the 'status' framing implies a read of pipeline health but nothing more. No prerequisites, no when-not-to-use, no alternative 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=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description usefully adds that the MLP is untrained, warning the agent that outputs may be meaningless. It still omits what the operation returns or any side effects beyond that.

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 compact parenthetical with zero filler; the explanatory caveat is linked directly to the tool name. It is terse to the point of being fragmentary but wastes nothing.

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 annotations and a fully covered schema, most structured context is present, and the untrained caveat is valuable. But with no output schema the description should say what the encoding actually yields, which it does not.

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 the nested input object is fully documented, so the schema carries parameter meaning. The description only tangentially maps to videoFrames via "image/video" and adds no syntax or format detail. Baseline 3 applies when the schema does the work.

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

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

"Visual encoding" names a resource and "image/video" hints at the modality, which loosely separates it from sensor_audio and sensor_olfactory siblings. However "V-JEPA 2-inspired" is unexplained jargon and it never states what the tool actually produces (embeddings, pixel data, scores), leaving the core purpose 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?

There is no guidance on when to call this vs alternatives such as sensor_fuse or sensor_process, no mention of prerequisites, and no exclusions. The agent must infer usage entirely from the 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no mention of what gets overwritten, whether the path must exist, permission needs, or effect scope. It does not contradict the annotations, but it contributes zero additional behavioral context.

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?

It is short, but the brevity reflects under-specification rather than conciseness. There is only one phrase and it does no work beyond echoing the title.

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 an idempotent, destructive mutation tool with no output schema and undocumented parameters, the description should at minimum explain what state is being modified and the path/value conventions. None of that is present, leaving the agent unable to invoke it safely or 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% for two required parameters (path, value). The description provides no information about the path format, the meaning of 'value' (units, allowed range), or whether path is hierarchical — the exact burden the description should carry when the schema is bare.

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 'Modify State Parameter' merely restates the tool name set_parameter and its title. It gives a verb (modify) and a generic resource (state parameter) but never says which state, which subsystem, or what kind of parameter, so it cannot be distinguished from siblings like simulation_control or ovo_set_policy.

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 when-to-use guidance, no preconditions, and no named alternative among the many sibling tools. An agent has no basis for choosing set_parameter over simulation_control or any other mutator.

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=false, idempotentHint=true, and destructiveHint=false, giving a basic safety profile with no contradiction. The description itself adds nothing — it does not explain what start/stop actually affect, whether stopping is disruptive, or what state persists.

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 words is technically short, but this is under-specification, not conciseness. There is no front-loaded intent 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?

A state-mutating control tool with no output schema and no annotations explaining effects needs the description to carry the burden. It carries none of it.

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% for the single required parameter, and the description contributes no information at all. The enum names are self-explanatory only incidentally; the description fails to compensate for the coverage gap.

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 the title restated verbatim with no verb, resource detail, or scope. It does not distinguish this tool from any of the ~70 siblings, many of which also control 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives despite the crowded sibling set. An agent has nothing to route on.

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, idempotentHint=true, and openWorldHint=false, so the safety profile and repeat-call semantics are covered structurally. The description itself adds nothing: it does not say what state is wiped, whether the reset is recoverable, or whether it must be followed by re-initialization. No contradiction with annotations, but no added value either.

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?

It is short and front-loaded, but this is under-specification rather than concision: a two-word phrase is not an appropriately sized description for a destructive engine reset. No sentence beyond the title exists to 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?

With no output schema and a destructive, idempotent annotation profile, the description should at minimum state what the reset affects and any prerequisites or follow-up steps. None of that is present, leaving the agent unable to predict the tool's effect.

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

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

The tool takes zero parameters, so the schema carries no semantics the description needs to compensate for. The baseline of 4 applies; nothing is misdocumented, though nothing is enriched.

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?

"Reset SNN Engine" merely restates the tool name and the annotation title verbatim, adding no information beyond them. An agent learns that some SNN engine gets reset, but nothing about scope, mode, or what distinguishes it from siblings like tcai_reset or simulation_control.

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 invoke this versus alternatives such as get_snn_state, snn_step, simulation_control, or the other reset-family tool tcai_reset. For a destructive reset with many adjacent lifecycle tools, the absence of any when/when-not routing is a serious gap.

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 disclose that this is non-read-only, non-idempotent, non-destructive, and closed-world. The description adds nothing beyond the title; it does not explain state mutation effects, step limits, or side effects of advancing the simulation.

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 three words, front-loaded, and free of filler. It is appropriately sized for a simple tool, though its extreme brevity leaves it indistinguishable from the title.

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 one parameter, no output schema, and annotations covering safety aspects, the description still lacks essential context: when to advance versus reset or control the simulation, and what the steps parameter means. It is minimally viable 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?

Schema description coverage is 0%, and the description does not mention the 'steps' parameter at all. While the schema provides type, default, minimum, and maximum, the description fails to compensate for the missing semantic meaning of the parameter.

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 and resource: advancing an SNN simulation. It distinguishes the tool from read-only siblings like get_snn_state and mutating siblings like snn_reset, though it does not explicitly differentiate from other simulation-control 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?

There is no explicit guidance on when to use this tool versus alternatives such as snn_reset, simulation_control, or inject_spikes. The verb 'Advance' implies progressing the simulation, but no conditions or exclusions 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the returned values are the 'REAL' principled quantities rather than heuristic proxies, which is useful trust context, but it discloses no rate limits, auth needs, or return-shape 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?

Two sentences, front-loaded with the tool identity and the list of returned quantities. The second sentence leans on citation scaffolding ('Da Costa et al. 2020; Legros 2026 §4.3') that does little operational work for an agent, but the text is not bloated.

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 input parameters and no output schema, the description's enumeration of returned quantities (F, G(p), task quality, entropy, Dirichlet action) effectively stands in for a return-value contract. It lacks any statement of response format or structure, but for a zero-argument read it is largely sufficient.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No meaning is lost by omission here.

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 — active-inference core telemetry — and enumerates exactly the quantities it surfaces (F, G(p) with pragmatic/epistemic decomposition, task quality, model entropy, Dirichlet-learned action). It distinguishes itself from the broader tcai_metrics sibling by being the active-inference-specific read, though it never states a clean verb and reads more like an abstract than a tool 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?

Usage is only implied: the note that this is 'the principled quantity the halting criterion thresholds on' suggests it is relevant when inspecting why the halting criterion fires, and 'not a heuristic correlate' gestures at heuristic alternatives. There is no explicit when-to-use, when-not-to-use, or named alternative such as tcai_metrics.

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 flag destructiveHint=true and non-idempotency; the description adds the concrete side effect (it runs warm-up cycles and overwrites epsFreeEnergy). It does not spell out that the change persists or is irreversible, but the mutation target and the cost of running warm-up cycles are disclosed, which meaningfully 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?

Four sentences, each carrying distinct information: motivation, mechanism, output, and rationale. The purpose is front-loaded and nothing is redundant 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 annotations covering the safety profile, full schema coverage, and the description itself explaining the return values despite no output schema, the definition is essentially complete. Minor gap: it does not state whether calibration persists across sessions or requires a subsequent step.

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 cycles, factor, and reward are already documented including defaults and bounds. The description restates factor's role as a multiple of the median |ΔF| but adds no syntax, format, or edge-case meaning beyond the schema, so 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 (Calibrate) and resource (halting threshold / epsFreeEnergy) plus the exact mechanism: warm-up cycles measuring median |ΔF|. An agent can distinguish this from set_parameter or tcai_reset purely from the description, since it names the target variable and the estimation procedure.

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 phrase 'instead of a guessed constant' and the reference to the v2.9 critique imply the motivating context (default 0.02 nats is uncalibrated), which hints at when to invoke it. However, it never states explicit when-not conditions or names the sibling (e.g., set_parameter) that would be the alternative for manually setting the threshold.

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 real domain context beyond that: the return is an EMA-derived action → expected-valence map from a DirectExperienceLearner port, telling the agent what kind of signal it gets back. It stops short of describing behavior for unknown/unseen actions.

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?

One compact sentence that front-loads the model name and mechanism before the two usage modes. The parenthetical '(DirectExperienceLearner port)' is dense jargon but does convey provenance in few characters; no wasted sentences.

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 single-optional-parameter read-only query with no output schema, the description covers mechanism, both invocation modes, and the nature of the returned map, which is enough for correct invocation. Minor gap: it does not say what is returned for an action with no learned entry, and the no-argument list behavior is only implied.

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 single 'action' parameter is documented inline as the action label to query. The description's 'action → expected-valence map' phrasing reinforces intent but adds no format, casing, or vocabulary details beyond the schema, so 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 mechanism and outcome: it exposes an agency capability model mapping actions to expected valence, and can either query one action or list the learned table. The dual mode is clear, though the definition never distinguishes itself from the many other tcai_* analysis tools in the sibling set.

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 two modes ('Query expected outcome of an action, or list the learned capability table') implicitly tell the agent when to pass an action versus call with no argument. However, there is no explicit when-to-use guidance and no named alternative among the tcai_* siblings for related queries.

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=true, and idempotentHint=true, so the safety profile is covered structurally. The description adds genuine behavioral context: the multi-condition AND gate (|ΔF| ≤ epsFreeEnergy and task quality ≥ minTaskQuality and low epistemic value, sustained over patience), plus the caveat that stationarity alone is insufficient.

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 inspect/configure split before the halting mechanics, and each sentence carries substantive content. The Legros citation is a minor flourish but supports the claim rather than padding.

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-param, all-optional tool with no output schema, the description explains both modes and the halting semantics thoroughly. It omits what the returned satisfaction state looks like and any permission/prerequisite context, but no output schema means return-value detail is not required.

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 the baseline is 3, but the description adds value by naming epsFreeEnergy, minTaskQuality, and patience inside the halt logic and showing how they combine as conjunctive conditions. It does not spell out relFreeEnergy's interaction, leaving one param to the schema alone.

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: 'Inspect or configure the recursive double-loop halting criterion (v2.9)', covering both read and write modes. It is clear what the tool governs, but it never distinguishes itself from nearby siblings like tcai_second_order, tcai_cycle, or orch_criterion, so an agent must infer the niche.

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 gives the branching rule: no arguments returns current state/thresholds, arguments update them. It also explains the halting condition, which tells the agent when the criterion is meaningful. It stops short of naming alternatives or when-not-to-use 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?

Annotations already flag readOnlyHint=false and idempotentHint=false, so the agent knows this mutates state; the annotation title adds '(trains predictor)'. The description reinforces the online-learning nature via 'online predictor' and clarifies the semantic meaning of the output, but neither description nor annotations explain what state is changed or the cost of repeated calls.

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 core mechanism in one dense sentence, followed by the interpretability note and the default behavior. Efficient overall, though the citation 'Legros 2026 §4.1' adds little operational value.

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 return-value burden and does so by explaining what the score means (high error = novelty). It leaves side effects of training undocumented, but for a single optional-parameter tool this is largely sufficient.

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 the single 'embedding' parameter is fully documented including its default. The description's 'Defaults to the current GNW broadcast' simply restates the schema, adding no format or constraint detail beyond it, 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 mechanism and resource: intrinsic reward / curiosity via RND, computing prediction error between a frozen target and online predictor. An agent understands what the tool returns. It doesn't explicitly differentiate itself from sibling TCAI tools, so it falls short of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the underlying theory (novelty = exploration drive, EFE epistemic proxy) but never says when to call this versus alternatives like tcai_active_inference or wm_surprise. No exclusions or prerequisites are given.

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