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

No annotations are provided, so the description carries the full behavioral burden. It discloses that enumeration is joint and constrained by one finite contract and a shared work budget, which is meaningful beyond the schema, but it does not state read-only status, determinism, behavior on budget exhaustion, or what the result 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?

Two sentences, front-loaded with the action and constraint, with no filler. The second sentence is dense but earns its place as a joint-sufficiency caveat.

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

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

For a six-parameter solver with nested objects and no output schema, the description is far too thin. It omits required inputs, budget and limit semantics, and expected results, leaving most completeness burden on the 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?

Top-level schema description coverage is 0%, and the description mentions only 'contract' and 'work budget' in passing. It does not explain the model, trim, implementation, max_work, or max_states parameters, so an agent must inspect nested schema details to understand required inputs.

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 action—enumerate compatible absorber endpoints and complete assignments—and adds a constraint about one finite contract and shared work budget. However, 'absorber endpoints' and 'complete assignments' are domain jargon, and the description never distinguishes itself from sibling tools such as triz_implementations or triz_feasibility.

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?

Provides no explicit when-to-use or when-not-to-use guidance and names no alternatives. The warning that separate per-function successes do not establish joint sufficiency is a correctness caveat, not routing guidance for an agent choosing among sibling tools.

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

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

With no annotations, the description carries the full burden and does most of it: it discloses the four checks by name, the verdict shape, that extra reports (hidden/forgotten/left out, harm loops, reach_map, feasibility, flows) accompany the verdict, that flows do not change the verdict, and that it fails closed on ill-typed models or nonexistent map ids. Missing only cost/determinism or error-payload details.

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?

Purpose is front-loaded, but the body is a single wall of multi-clause sentences with heavy parentheticals (the initial 'e.g. with declared behaviour' vs 'with costs and feasibility' framing is buried). Naming output keys inline (typed_map, cycle_map, reach_map, flows.images, flows.unbacked) is useful, but the density makes skimming hard; some phrasing, such as 'negative = harmful or excessive, or not', is needlessly convoluted.

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 tool with deeply nested models, no output schema, and no annotations, the description covers what an agent needs: the mapping defaults, the four checks, the verdict and failing checks, the auxiliary reports, the flows behavior, and the failure mode. Return-value detail is spelled out precisely because no output schema exists.

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?

At 67% schema coverage, the schema already documents the AbstractionMap sub-fields with the same defaults ('same id and side', 'a box left out is outside the abstraction') that the description restates. The description does add some semantics by tying map entries to consequences (unmapped ports become hidden, differing images plus an unmapped port become forgotten), but most map mechanics duplicate the schema text.

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?

Opens with a specific verb and relation: 'Check that a coarse function model ... is an abstraction of a detailed one of the same system under a typed map'. The typed-map framing plus the named verdicts ('abstraction or not-an-abstraction with the failing checks') make it distinguishable from verification-adjacent siblings such as triz_adequacy or triz_isomorphism without opening any schema.

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

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

Usage is implied rather than stated: one infers this is the tool for validating a coarse model against a detailed one, and the closing sentence scopes it ('Whether the coarse rows are true of their preimages is substantiated outside the kernel'). No sibling is named as an alternative and no precondition (e.g. models must type-check, provenance status) is given up front.

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

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

No annotations are supplied, so the description carries the full burden of behavioral disclosure. It adds one cryptic caveat about partial relations, but does not state whether the tool is read-only, what it returns, whether it requires a complete model, or how it reports failures.

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

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

The description is short and front-loaded, with no filler sentences. Its brevity, however, comes at the cost of clarity: the second sentence is cryptic and the first relies on undefined jargon.

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 five-parameter, nested-model analysis tool with no annotations and no output schema, yet the description gives only a high-level and ambiguous notion of what is checked. It is not complete enough for an agent to invoke the tool correctly without opening the schema and guessing at intent.

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 as 0%, and the description does little to compensate. It vaguely gestures at 'explicit scope', 'acceptable outputs', and 'required operating situations', but does not explain the roles of model, acceptable, scope, max_states, or required_inputs.

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 checking activity over outputs and operating situations, which is more specific than the name alone. However, 'nonblocking' is undefined and the description does not distinguish this check from siblings like triz_behavior or triz_feasibility, leaving the agent to infer what 'adequacy' really covers.

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 guidance, no mention of prerequisites, and no comparison with the many sibling analysis tools. The phrase 'under an explicit scope' hints at a condition but does not tell the agent when this tool should be chosen over alternatives.

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

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

With no annotations, the description carries the full behavioral burden and does so extensively: it discloses steady-state semantics, the default upstream scope assumption, search caps, fail-closed conditions, and undecided reasons such as missing-behavior, no-steady-state, and concept-cap. It also explains what verdicts mean and how modes change behavior, which is well beyond what structured fields provide.

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 enormous paragraph of densely compressed jargon with no headings, bullets, or clear progression between modes. Although the first sentence is front-loaded with purpose, the remaining text is difficult to scan and repeats mode conditions in a way that undermines readability.

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 complex 13-parameter tool with no output schema, the description is thorough: it covers default behavior, mode-specific verdicts, failure reasons, caps, and producible-row handling. Some specialized terms such as relational trace and factorisations are left opaque, but the overall informational coverage is high.

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 high at 92%, so the baseline is 3. The description adds real meaning beyond the schema by explaining parameter interactions and provenance, e.g. that box_map should be a triz_transform segment or take_out boxMap, that row_costs are unsupported in joint_boxes mode, and that trim is shorthand for the triz_transform trim procedure.

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 opening sentence states a specific verb and resource: compose declared box behaviour into the model's external relation, defined as boundary inputs to deliverables. It distinguishes the tool from triz_transform and triz_trim only through mode-specific references, not through an overall statement of when this tool is preferred over its siblings such as triz_behavior_refinement.

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

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

The description gives explicit mode conditions, e.g. 'With compare_to', 'trim is shorthand', and 'With joint_boxes and weakest_spec'. However, it never names an alternative tool to use instead or states when this tool should not be used, leaving tool selection largely implicit.

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

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

No annotations are provided, so the description carries the full burden. It does disclose meaningful semantics: complete relations are checked and no physical transfer is inferred, which usefully constrains interpretation of the result. It does not say whether the operation is pure/read-only, what happens on a failed check, what the response format is, or how max_states affects behavior.

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

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

The description is two tight sentences with the core comparison operation front-loaded, and every clause carries some semantic weight. The unexplained capitalized 'WHOLE' and dense jargon reduce immediate readability but do not constitute wasted text.

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

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

For a complex five-parameter tool with enormous nested model schemas, no annotations, and no output schema, two sentences are far too thin. The description omits how detailed and coarse models are supplied, how inputs/outputs map to boundary endpoints, what max_states guards against, and what the tool returns on success or failure. It gives conceptual framing but not enough for an agent to invoke the tool correctly.

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

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

Top-level schema description coverage is 0%, despite the nested definitions being richly documented. The description only vaguely gestures at the parameters with 'two WHOLE models' and 'boundary and deliverable value maps', leaving it unclear which arguments are the models, what the inputs/outputs arrays contain, and what max_states controls. It does not compensate for the top-level schema 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 operation: compose two whole models and check exact equality or directional inclusion under boundary and deliverable value maps. This lets an agent identify it as a model-comparison/refinement tool rather than a model builder. However, it never contrasts itself with siblings like triz_behavior, triz_feasibility, or triz_build_model, and the phrase 'WHOLE models' is left 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 guidance, no prerequisites, and no alternatives named. The description does not say when an agent should choose this over triz_behavior or triz_feasibility, nor does it explain that models must be reviewed before analysis. The single clarifying remark about complete relations is behavioral, not usage-oriented.

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

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

No annotations exist, so the description carries the full burden. It does disclose meaningful traits: the analysis runs by 'bounded propagation and search' (explaining the max_steps bound) and explicitly excludes numeric simulation. It does not say whether the model is read-only or mutated, whether results are deterministic, or what happens when no ordering can be established.

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 verb and scope front-loaded, and zero filler. It is compressed to the point of opacity in places ('derivative causality'), but no sentence is wasted.

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

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

For a tool taking a very large nested model with no output schema and no annotations, the description is only modestly complete. It covers what is computed and the simulation boundary, but not the shape of the returned report, error conditions on malformed energy declarations, or how the analysis depends on the declared bond elements.

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 0% for the two top-level parameters, and the description does not explain max_steps at all. However, 'on declared energy subsystems' adds a real constraint beyond the schema (the Carrier.energy block is optional in the schema), telling the agent what the model must contain for this check to be meaningful.

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 operation ('Assign effort/flow causality on declared energy subsystems') plus its outputs ('report derivative causality and direct algebraic dependency cycles, and export constitutive equation structure'). It distinguishes itself from function-rating siblings by scoping to energy subsystems and causality, though the jargon ('derivative causality', 'constitutive equation') assumes domain fluency.

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 tool applies to models whose carriers are explicitly energy subsystems with effort/flow pairs. The clause 'No numeric simulation' gives a useful when-not boundary, but no prerequisites (e.g. energy carriers must be declared) and no routing to or from siblings like triz_graph, triz_behavior, or triz_feasibility are stated.

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

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

With no annotations supplied, the description carries the full behavioral burden and does substantial work: it discloses the deterministic id/port generation scheme, percent-escaping to guarantee id uniqueness, that the result is validated and linted, that the completeness report is 'bounded', and that 'ratings and behavior are never inferred'. What is missing is whether anything is persisted, whether the call is idempotent, and what happens on validation/lint failure.

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 front-loaded correctly with the build action and the model shape, but the middle is a single very long sentence packed with id-scheme and fan-in/fan-out encoding detail that reads more like internal spec than selection guidance. Every clause is technically informative, yet the density and length work against quick scanning for tool selection.

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

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

For a 7-parameter, deeply nested tool with no annotations and no output schema, the description covers the build pipeline (construct → validate → lint → bounded completeness report) and the id scheme well, but says nothing about domain, hierarchy, system, or draft, and does not sketch the shape of the returned report. Adequate but with clear gaps for a tool of this complexity.

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 as 0%, so the description must compensate, and it does: it explains the semantic content of components (stable ids, names, roles), interactions (subject/action/object plus carrier descriptors and polarities), and flows ('Optional flows reference component and carrier ids from the table'). Domain, system, hierarchy and draft are not covered, but the core modeling payload — the parts an agent must get right — is explained in prose.

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

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

The description opens with a specific verb+resource: 'Build a typed function model from an interaction table', and enumerates the constituents (components with ids/names/roles, subject/action/object interactions with carrier descriptors and polarities). It is clearly a model-construction tool rather than an analysis/query tool, though it never names a sibling (e.g. triz_function_model, triz_flow, triz_graph) to make the boundary explicit.

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 choose this tool over the many adjacent siblings (triz_function_model, triz_flow, triz_graph, triz_expand_hierarchy) and no prerequisites or exclusions. Usage is only implied by the phrase 'from an interaction table', leaving the agent to infer the routing decision from the catalog alone.

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

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

With no annotations, the description must carry the behavioral burden. It usefully states that no behavior is inferred from names and that conditions remain visible hypotheses, but it does not describe the return shape, read-only nature, failure modes, or any permission or rate-limit constraints.

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 first sentence front-loads the core purpose, but the remaining sentences are dense and run together with undefined domain jargon such as 'directed refinement observations' and 'global aliases'. The content is relevant, but the structure makes it harder to parse than necessary.

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 complex tool with ten parameters, nested objects, no output schema, and no annotations. The description covers the catalogue-source distinction and several selection parameters, but it does not fully explain the remaining parameters or the returned catalogue's structure, leaving meaningful gaps for an agent.

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

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

Schema coverage is 50%, and the description explains several important parameters: source, effects, mappings, bindings, and declarations. However, it leaves query, models, parent, and state_parameters largely or entirely unexplained, so it only partially compensates for the schema gaps.

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

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

The description opens with a specific verb and resource: 'Return the general identity/fanout catalogue (default), or source:knowledge...' It distinguishes the default general catalogue from the knowledge-source catalogue, though the jargon 'identity/fanout' is not explained and sibling differentiation is limited to mentioning triz_component_search.catalogues.

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 states when to use the default versus source:knowledge, explains that effects and mappings select named realizations and directed observations, and instructs the caller to pass the returned catalogue to triz_component_search.catalogues for bounded discovery. It does not explain when not to use the tool or what to do if no catalogue is needed.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses bounded-search semantics — completeness applies only to the declared bounded catalogue, and capped search is undecided — plus the optional contract checks, but says nothing about whether the operation is read-only, how candidates are returned, or what errors to expect.

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 sentences and front-loads the main search/synthesis purpose before adding bounds and contract details. The wording is dense and jargon-heavy but not padded; every sentence carries relevant 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?

This is a complex tool with 15 parameters, nested objects, and no output schema. The description conveys the core intent and some search semantics, but it does not explain the required model/resources/targets input shape or what the search actually returns, leaving substantial gaps for an agent to close.

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 low at 27% across 15 parameters, so the description must compensate. It adds meaning for catalogues/bindings, instance/component/work bounds, and contract checks, but does not explain required parameters such as model, resources, targets, or the roles of flows, remove, replace_wires, implementation, and require_all_resources.

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 activity — constructing and searching component choices, chains, and multi-input networks from typed catalogues — and names the inputs (catalogues, bounds, contracts). It does not explicitly contrast itself with sibling tools such as triz_component_catalogue or triz_synthesize, so sibling 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?

The description explains what the tool searches and that contracts are optional, but gives no explicit when-to-use guidance, no prerequisites, and no alternatives. An agent must infer from the purpose alone whether to call this versus catalogue management or model synthesis tools.

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

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

With no annotations at all, the description carries the full burden, and it only discloses the aggregation semantics ('consumptive branches sum; shared intensive requirements use max') plus a label caveat. It never says whether a violation raises an error or returns a diagnostic, whether any state is written, or what the caller receives — critical unknowns for a checking 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?

Three short sentences, no filler, and the core constraint-checking purpose is front-loaded before the aggregation rules. It is efficient, though the density of unexplained terms like 'consumptive' and 'shared intensive' borders on cryptic.

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

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

For a 7-parameter tool with no annotations, no output schema, and 29% schema coverage, the description is far from sufficient. An agent still cannot determine the meaning of the operation enum, what allow_loss permits, or how a failure manifests, which are exactly the gaps the description should close.

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 29% across 7 parameters, so the description must compensate and largely does not. It hints at unit/quantity_kind semantics through 'explicit units' and 'consumptive versus shared', but leaves operation (splitter/merge), max_work, allow_loss, and the port semantics of inputs/outputs entirely undefined 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?

The description gives a specific verb ('Check') and a specific resource ('declared consumptive versus shared-level supply constraints'), scoped to 'explicit units'. An agent can tell this is a supply/demand feasibility check rather than a modelling or synthesis tool, though it never names a sibling to differentiate from and leans on domain jargon.

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 versus siblings like triz_feasibility or triz_adequacy, and no preconditions or exclusions. The closing sentence 'No physical law is inferred from labels' is a caveat about interpretation, not guidance about invocation.

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

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

With no annotations, the description carries the whole burden and does so extensively: it discloses breadth-first exhaustive exploration, the default horizon (inputs length minus one, else 20), the state cap, that it fails closed on ill-typed rows, unknown targets, and past the cap, that every trace is re-checked against declared rows, and that continuous dynamics, convergence rates, and control are not modelled. It also explains the `unbounded` post-horizon continuation of each verdict and what 'undecided' means. The return shape is only described in prose fragments (no output schema exists), which keeps it short of a 5.

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

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

The description is a single wall of run-on clauses with no headings, lists, or paragraph breaks, making the four distinct analyses (reachability, invariance, separation, loop classification) hard to locate. The lead sentence is the least useful content yet is front-loaded, and heavy jargon ('rational potential bounds', 'rechecked witnesses on closed components') is never grounded. Length is justified by tool complexity, but the lack of structure is not.

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

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

For a 9-parameter, deeply nested model-checking tool with no output schema, the description covers the semantics of the main verdicts and the failure/limit behavior well. It is weaker on the return contract: fields like `completeAfter`, `unbounded`, `allUnsafe`, and meanCost appear only in passing, and the opening sentence about costed transition rows is never explained, so an agent cannot fully anticipate the response. Adequate but with clear gaps for a tool of this complexity.

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 89%, so the schema already documents most parameters and the baseline is 3. The description does add real meaning in places — that `inputs` defaults to every value at every time, that `max_cost_work` caps exact cycle-cost work and leaves meanCost undecided, that `separation` takes two to four demands with non-overlapping windows, and that a blocked state meets a target by state conditions but a port condition there yields undecided. These additions are genuine but scattered through dense prose rather than tied clearly to each 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: it explores the bounded dynamics of a function model whose boxes declare `state`, `initial`, and `transition` rows, doing breadth-first search from the initial states up to `horizon` and returning reachable states, fixed points, and blocking runs. It separates itself from `triz_behavior` ('a loop through stateless boxes resolves within a step as in triz_behavior'; 'Behavior rows are never read as transitions'), so an agent can tell the two apart. The opening sentence about 'costed transition rows' and 'rational potential bounds' is opaque and sits before the actual purpose, slightly hurting first-read 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?

Usage is implied through what each parameter decides — `unsafe` for escalation, `safe` for invariance, `separation` for a trajectory meeting timed demands, `loops` for closed-component classification — which gives a reader a fair idea of when to reach for the tool. However there is no explicit 'use this when / do not use this when' statement and no direct routing to `triz_behavior`, `triz_feasibility`, or `triz_lifecycle` for the adjacent questions they answer. The prohibition on reading behavior rows as transitions is the only explicit boundary.

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

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

With no annotations, the description carries the full burden and discloses several important behaviors: every wiring diagram passes checkModel, named configurations require expansion, ranking criteria, that capped search is undecided, and that physical sufficiency is not claimed. It does not explicitly state read-only status or return format, but the caveats are substantial.

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

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

The description is a single dense paragraph that front-loads the core action and then adds validation, expansion, ranking, and limitation notes. Every sentence conveys useful information, though the jargon-heavy style could be more scannable.

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 complex tool with 9 parameters, nested objects, no annotations, no output schema, and very low schema description coverage, the description leaves key gaps. It covers purpose and behavioral caveats but does not explain how to use the bounded-search parameters or what the result structure looks like.

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

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

Schema description coverage is only 11% across 9 parameters, so the description must compensate. It adds meaning to several parameters indirectly (bounded search, resources/output quantities, conditions, length, field changes, declaration order, and requiresExpansion), but it does not explain specific parameters such as k, limit, max_steps, or the structure of 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?

The description states a specific verb and resource: 'Search bounded typed effect chains from declared resources to a required quantity.' It also distinguishes itself from triz_effect_setup (expansion) and implies a contrast with physical sufficiency analysis, though it does not explicitly name other search 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?

It gives one clear alternative routing: use triz_effect_setup to expand named configurations. However, it does not explicitly state when to use this tool versus triz_effects, triz_route, or other search/analysis tools, leaving usage context mostly implied by the purpose.

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

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

With no annotations, the description carries the full burden; it usefully discloses the return contents (checked model, added carriers, replayable rewrite, citations/conditions) and the key caveat that behavior and resource rows are merely caller declarations with no inferred physical sufficiency. It does not describe validation failures, permission/auth needs, or what exactly the replacement destroys beyond the supplier wire.

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 tight sentences that front-load the core action and then state the return and the non-inference caveat. No filler, though the caveat sentence is somewhat dense and could be split for scanability.

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 11-parameter mutation tool with no output schema and no annotations, the definition covers purpose and the critical 'declarations only, no sufficiency inference' nuance. It leaves large gaps on how intermediate carriers/layers and declarations interact with the chain, which an agent would need for correct 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 low at 45%, so the description needs to compensate. It clarifies the from/to endpoints as existing ports and replace_wire as an explicit supplier replacement, but says nothing about declarations, flows, intermediate_layers, intermediate_carriers, polarity, or conditions, leaving several of the 11 parameters undocumented 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 uses a specific verb and resource — 'Insert a selected typed effect chain between existing output/input ports' — and adds a distinguishing detail ('explicit replacement of an existing supplier'). It implies a contrast with the chain-selection siblings (triz_effect_chains, triz_effect_setup) but never names them, 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?

Usage is only implied by the phrase 'selected typed effect chain', suggesting this runs after a chain has been chosen elsewhere. There is no explicit when-to-use/when-not statement and no routing to triz_effect_setup or triz_implementations, leaving the choice among effect tools unstated.

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

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

With no annotations supplied, the description carries the full burden and does disclose non-obvious behavior: unregistered facets are advisory and 'never become generators or executable recipes', assessments characterize the whole named function while the selected typing may cover only one facet, and domain filtering implicitly includes universal effects. It also states what results retain (named cases, sources, limitations, review status), which is the kind of return-shape context annotations would otherwise provide.

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 purpose and primary search axes are front-loaded, which is good, but the middle sentences are compressed to the point of opacity ('Unregistered facets are advisory and never become generators or executable recipes') and mix filter semantics with modeling theory. Most sentences carry real information, yet several require re-reading to extract actionable 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?

For an 11-parameter, all-optional search tool with no output schema, the description covers discovery axes, filter exactness, result contents and the relationship to expand/chain siblings, which is close to complete. The remaining gap is the unexplained typed input/output string format, which the schema also leaves bare.

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 64% with 11 parameters, and the description compensates for the undocumented ones: it explains 'text or exact typed input/output quantity', SI dimension matching, and that pack and category filters are exact while domain is inclusive of universal effects. The 'input' and 'output' parameters are only covered obliquely through the phrase 'exact typed input/output quantity', which leaves the typed-string format itself unexplained.

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 opening sentence gives a specific verb and resource ('Search effects from all installed knowledge packs') plus the search axes (text, typed input/output quantity, field, SI dimension), which is far beyond a restatement of the name. It is dense domain jargon, but an agent can tell this apart from triz_effect_setup or triz_effect_chains because those are named as downstream/adjacent operations.

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

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

Usage context is implied through the filter catalogue (kind for modeling role, form for storage, assessment for retain/split decisions) and through routing hints ('expand through triz_effect_setup', 'chain search uses their constituents'). There is no explicit when-to-use/when-not-to-use statement or a direct statement of which sibling to pick for a given intent, so the agent must infer the routing.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that recipes expand, that validation happens ('Return a checked rewrite and provenance'), and that missing conditions remain hypotheses. But it leaves unclear whether the tool persists anything in the registry, what validation failures look like, and what permissions or side effects exist.

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

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

The purpose is front-loaded in the first sentence, but the remaining text is dense, jargon-heavy, and sometimes cryptic (e.g., 'Ordinary declarations correspond to expanded effect steps'). Several clauses repeat schema semantics rather than adding new guidance, reducing clarity.

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

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

This is a highly complex tool with nine parameters, nested objects, and no output schema. The description covers the core build operation and return value, but it omits enough parameter semantics and behavioral detail that an agent would need to rely heavily on the schema. For this complexity level, the description is not sufficiently complete.

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

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

Schema description coverage is 61%, so the schema already documents many parameters. The description adds some meaning by clarifying that node_declarations and context_values correspond to expanded steps and that boundary/behavior/state rows remain caller declarations. It does not explain other parameters such as system, conditions, or domain, so it only partially compensates 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 verb and resource: 'Build a composable function model from registered effect or recipe ids.' It explains recipe and configuration expansion, which clarifies scope. However, it never names or contrasts sibling tools such as triz_build_model or triz_function_model, and the jargon (SI, carrier-layer, expanded-step) obscures the purpose for an unfamiliar 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 description gives internal parameter guidance ('Use node_declarations[expanded-step/node]...'), but it never says when to choose this tool over alternatives or when not to use it. There is no explicit context, prerequisite, or exclusion that would guide tool selection.

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

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

No annotations are supplied, so the description carries the full burden. 'Return' implies a side-effect-free read, but it does not say whether results are static fixtures or computed, how large the payload is, whether there is pagination or filtering, or how failures/regressions are represented. For a tool with zero annotation coverage 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?

One sentence, front-loaded with the verb, with no filler or redundancy. It is lean but also thin; nothing is wasted, though little is conveyed.

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

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

There is no output schema and no annotations, so the description is the only place the agent could learn what comes back. It gestures at 'regressions' and 'reasoning cases' without describing their structure, count, or format, which leaves the return contract undefined for a tool whose entire purpose is returning data.

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 and the baseline of 4 applies. The single sentence adds no parameter-level meaning, but none is needed.

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

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

The verb 'Return' plus the resource 'TRIZ lookup regressions and cross-domain reasoning cases' identifies the tool as a retriever of evaluation fixtures, but 'regressions' is jargon that could mean test cases, known-failure records, or regression results. It is distinguishable from siblings like triz_matrix or triz_principle (which expose TRIZ content proper), but the reader must guess what an 'eval' actually is here.

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 an agent should call this versus the other 50 TRIZ tools, no mention of whether it is for validation, self-testing, or calibration, and no prerequisites or 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?

With no annotations, the description carries the full burden and does so: it states what is preserved (inner costs, feasibility, states, transitions, standalone inner flows), what the caller must supply (explicit routes for parent flow occurrences, checked boundary connections, media mappings), what is opt-in (budget/weights/contradictions policies), and the fail-closed behavior on product-identity changes.

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 front-loaded with the core operation, then layers preservation, requirements, policies and ordering. Every sentence carries distinct information, though several are densely packed with domain jargon that an unfamiliar agent may need to unpack.

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 complex five-parameter mutation tool with no annotations and no output schema, the description covers return value ('a typed model and fresh box, wire and flow id maps'), invariants, required inputs and failure mode. Only the precise shape of routes and the full set of validation failures remain undocumented.

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% (essentially just `box`), so the description must compensate, and it does explain the roles of `routes` (parent flow occurrences), `media` (explicit mappings) and `policies` (global-intersection, global-merge, append-renamed). It stops short of explaining route structure such as path, occurrence, entry and exit, so the compensation is substantial but incomplete.

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 opening sentence gives a precise verb and resource: substitute one box's declared inner model into its parent through its checked input/output interface. It distinguishes itself from triz_nine_windows, which is explicitly described as a reader of the same inner model, and from flat analysis tools it says to call afterward.

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

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

The description gives sequencing guidance ('expand nested boxes one at a time before requesting flat behavior, dynamics or resource verdicts') and names triz_nine_windows as the read-only alternative. It does not state explicit preconditions for when this tool should not be used, such as a box lacking an inner model, but the ordering and alternative are clear.

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

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

With no annotations supplied, the description carries the burden well: it discloses the type-check gate, the failure return (ok:false with the errors), the svg-only optional dependency on elkjs, and the hosted-server behavior (ok:false with format-unavailable). It does not say the operation is non-mutating/read-only or whether large models are truncated, which keeps it short of a 5.

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

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

The core statement is front-loaded, but the body is one run-on sentence built from stacked parentheticals and semicolons, making the per-format guidance hard to scan. It is information-dense rather than padded, but a bulleted or per-format breakdown would read far better.

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 the description explains only the failure envelope (ok:false with errors / format-unavailable), never what a successful call returns — a string of DOT text, an SVG document, a JSON wrapper? For a tool whose whole job is producing an artifact, that is a material gap.

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

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

Top-level schema coverage is 0%, so the description has to carry the format enum — and it does, explaining what each of dot/mermaid/svg/hypergraph yields and its constraints. The 'model' parameter is left entirely to the (rich) $ref schema, so half the parameter surface is unaddressed in prose.

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 ('Export a function model') and enumerates the four output artifacts by name, so an agent knows exactly what it produces and how it differs from siblings like triz_function_model or triz_graph.

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?

Selection guidance is given per format: mermaid for clients that render without tools, svg 'for when Graphviz is not at hand', hypergraph for an open interchange structure, dot for the canonical picture. It also names the precondition (the model must type-check) that gates any 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?

With no annotations, the description carries the full burden and does so thoroughly: it enumerates the three verdict shapes with their reason codes (over-budget, unprovidable, missing-feasibility, no-budget, unbudgeted, circular-resource-support), lists the conditions under which it fails closed (ill-typed or dominated rows, extensive-fan-in, caps), and states scope caveats (no polynomial bound claimed, absorber harms not modelled, budget stays the caller's declaration). It also describes the `relaxation` payload for infeasible verdicts and the separate steadyState balance verdict.

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?

Every clause is substantive, but the whole description is one dense paragraph of nested parentheticals and specialized vocabulary, with no structure separating purpose, inputs, verdicts, and caveats. It is front-loaded with the core purpose, yet the readability cost is real for an agent parsing it in one pass.

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 highly complex tool with no output schema and no annotations, the description covers the return payload (minimal vectors with rows and demanded levels, verdicts, relaxation, levels, steadyState) and the failure modes in detail. It is nearly complete, though a clearer enumeration of the returned fields would close the remaining gap left by the absent 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 coverage is 80%, so the baseline is 3, but the description adds real meaning: it explains that `trim`/`absorb` behave as in triz_behavior and that the baseline is solved only to report each absorber's added resources, and it ties `max_antichain`/`max_iterations` to the 'past the caps' failure. It does not restate the numeric bounds, which the schema already covers.

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 first sentence names a specific computation and its source data: monotone co-design feasibility over declared box `feasibility` rows, producing minimal resource vectors and a budget verdict. It distinguishes itself from siblings by referencing triz_trim and triz_behavior for the sub-operations it borrows. The density of jargon (Kleene ascent, intensive/extensive carriers) keeps it from a clean 5, but an agent can tell what it computes.

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 implied through conditional clauses: use `trim`/`absorb` to decide a trimmed model, and `levels` reporting activates only when carriers declare `levels`. There is no explicit statement of when to call this instead of adjacent analysis tools such as triz_pareto or triz_conservation, and no when-not guidance beyond the fails-closed error conditions.

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

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

With no annotations, the description carries the full behavioral burden and does add real context: the fail-closed type-check, and the caveat that outputs are candidates rather than findings. It also discloses the internal definitions used for bottlenecks, accumulation, leaks, and loops. What it omits is the practical behavior an agent needs: whether this is read-only, whether it mutates the model, and the concrete shape of the returned 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?

The purpose is front-loaded, but the body is a single sprawling sentence per clause with deep parenthetical nesting ('the performer of an insufficient, excessive, or harmful function that carries the flow's carrier and touches the path: a resistance-like output on the flow, at its position'), which is hard to parse for an agent. Definitions of accumulation, leak, and loop candidates are buried in a run-on list rather than structured. Substantial rewriting into short labeled lines would earn a much higher score.

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

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

No output schema exists, so the description must describe returns, and it does enumerate the result categories (steps, declaredOnly, bottleneck, accumulation, leak, loop, harm loops). It also covers the failure mode (fail-closed type-check). The gap is that it never gives the concrete response structure or how these candidates are keyed per flow, leaving the agent to infer the shape.

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% on a single `model` parameter, so the schema already documents the input; baseline 3 applies. The description does add interpretive meaning about what a flow path is and how series order differs from function interaction, plus the constraint that boxes consecutive on a flow become adjacent for merge. That is useful but is about model semantics rather than the parameter itself.

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: 'Flow analysis ... over the model's declared `flows`', and immediately distinguishes it from function wiring ('each an ordered path of the boxes a carrier passes through, in series, which functions do not record'). It even names the sibling interaction with triz_transform merge, so an agent can tell what is unique here. It does not, however, contrast itself against the many other triz_* checks beyond that single adjacency note.

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?

Implicit usage is clear (call it on a model that declares flows), and 'Every item is a structural candidate to substantiate, not a finding' tells the agent how to treat results. But there is no explicit when-to-use versus when-not, no statement of prerequisites such as the model needing to pass the type-check before other analysis, and no routing to sibling tools such as triz_weakness or triz_transform beyond the adjacency aside.

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

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses failure behavior ('fails closed with ok:false' for dangling, mis-directed, or mistyped wires), bounded-search behavior ('decided:false if the bounded search runs out'), nested-model limitations ('incompleteHierarchy lists them... their inner loops and contradictions are not analysed'), and that 'no weight is ever filled in.' It also states that each verdict cites its theorem basis.

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

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

The description is a single dense paragraph with no wasted sentences; each clause describes a distinct analysis or constraint. It is front-loaded with the core purpose, but the wall-of-text format reduces readability for a complex tool. Structure could be improved with bullets or sentence breaks, though the content 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?

Given the tool's complexity, lack of output schema, and lack of annotations, the description is remarkably complete. It covers the analyses performed, failure modes, nested-model caveats, comparison behavior, isomorphism semantics, mpv_weights handling, and the 'basis' citation for each verdict. An agent has enough information to invoke it correctly and interpret key outcomes.

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 baseline is 3. The description adds meaningful semantics beyond the schema: it explains that box_map is 'applied before comparing deliverables' and should come from triz_transform outputs, that compare_to triggers a 'componentwise baseline-vs-concept comparison plus an isomorphism check,' and that mpv_weights limits comparison to named cost dimensions or 'harmful' with explicit weighted sums and no auto-filled weights.

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: 'Check a TRIZ function model written as a typed wiring diagram ... and analyse it.' It enumerates the analyses performed, including harm loops, ideality profile, separation checks, baseline-vs-concept comparison, and isomorphism check, making the tool's scope clear. It explicitly distinguishes from triz_expand_hierarchy for nested models, but does not route away from overlapping siblings like triz_isomorphism or triz_separate.

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

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

The description gives one explicit alternative: 'when boxes declare an `inner` model ... run triz_expand_hierarchy on each first.' It also frames harm loops as 'hypotheses about mechanism to substantiate, not findings,' clarifying interpretive use. However, it offers no when-not guidance or explicit comparison to siblings that perform standalone isomorphism or separation checks.

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

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

With no annotations, the description carries the full burden, and it does disclose that the result is exact, finite, and either a witness or a complete empty join, plus that no cohomology is computed. It omits behavioral details such as how max_work affects the computation, what happens when work limits are exceeded, and the precise return structure.

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 dense sentences with no filler, and the core operation is front-loaded. The second sentence usefully rules out a naive pairwise approach and clarifies that cohomology is not involved, though the density of jargon may reduce immediate clarity.

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

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

This is a complex constraint-satisfaction-style tool with no annotations, no output schema, and zero parameter description coverage. The description explains the high-level decision and result type but leaves out parameter meanings, work-limit behavior, and sufficient return-format detail for an agent to invoke 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?

Schema description coverage is 0% for three parameters. The phrase 'allowed tuples on overlapping variable contexts' loosely maps to regions and allowed tuples, but the description never explains the variables parameter or the max_work parameter, so it does not compensate for the missing schema documentation.

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

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

The description states a specific operation: deciding exact finite global compatibility of allowed tuples over overlapping variable contexts, returning either a witness or a complete empty join. This is more than a restatement of the name, though it relies on specialized jargon and does not explicitly distinguish itself from the sibling triz_separate tool.

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

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

The description implies when the tool is needed by warning that pairwise projection compatibility alone is insufficient, which gives a condition for use. However, it does not state when to choose this tool over siblings such as triz_separate, nor does it describe prerequisites or exclusions beyond the pairwise warning.

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

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

With no annotations, the description carries the full behavioral burden and does disclose meaningful traits: the separationCheck outcomes, that invalid results fail closed for that node, and that tie-breaking favours irreducible nodes while flagging a top node that already separates. It stops short of describing the return payload or any cost/pagination behavior for an analysis call.

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 purpose, which is good, but the text is heavy noun-stacking ('verifier-backed purpose gates', 'core-conflict ranking breaks ties on dissolves') that slows parsing. The final sentence, on TRIZ_GRAPH and the neutral core, is worth keeping; some of the check-outcome detail could be tightened.

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 analysis tool with no output schema, the description explains internal verdicts but not what the analysis returns or how results are shaped, which is the main gap. The prerequisite and fail-closed behavior are covered, so it is adequate but not complete.

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

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

The tool takes zero parameters, so the baseline is 4. The only parameter-adjacent information is environmental ('Requires a project graph via TRIZ_GRAPH'), which is a useful invocation precondition but is not schema-level semantics.

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: 'analyse an OTSM Network of Problems (contradiction graph)'. The subject matter is unambiguous, though it does not contrast itself with adjacent siblings like triz_separate, triz_purpose, or triz_global_separation, 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 a real precondition ('Requires a project graph via TRIZ_GRAPH') and an explicit opt-in framing ('Optional project extension... not part of the neutral skill core'). However, it never says when to choose this over the many sibling analysis tools, leaving alternative selection implied.

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

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

With no annotations, the description carries the full behavioral burden. It does add real value beyond the schema: it discloses that cross-mode splicing of behavior and cost is checked for, and that provenance stays user-declared rather than verified. It says nothing about whether the call mutates anything, what the verdict format is, or cost/limits of evaluation, leaving notable gaps for an annotation-free tool.

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

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

Two tightly packed sentences with no filler, and the verb-plus-resource statement is front-loaded before the constraint. The phrasing is dense with domain jargon, but every clause carries 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?

For a tool whose schema is this deep (nested models, contracts, evidence, provenance) with no annotations and no output schema, two sentences are thin: the return shape is never described, the meaning of 'modes' and 'provenance remains declared' is left implicit, and the effort-bounding parameters are ignored. The rich nested schema covers much structural semantics, but the description does not fill the remaining 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?

Top-level schema description coverage is 0%, so the description must compensate, and it partly does: 'one whole-model behavior... and resource contract' maps onto the contract object's target/acceptable/allowed_harms/budget fields, and 'named complete implementations' maps onto alternatives[].id. The max_work and max_states parameters, which bound evaluation effort, are not mentioned anywhere in the description.

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 ('Evaluate') and a specific resource ('named complete implementations'), and lists the four contract dimensions being checked (whole-model behavior, adequacy, declared-harm, resource). It could be sharper about how this differs from siblings such as triz_adequacy or triz_subsystem_contract, which also sound like contract checks, so sibling differentiation is not explicit.

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 reach for this tool versus triz_adequacy, triz_evals, or triz_subsystem_contract, and no preconditions (e.g. that models must be reviewed rather than draft) are given in the description. The only guidance is a prohibition ('never splice behavior and cost from different modes'), which constrains how to call it rather than when to call it.

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

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

With no annotations supplied, the description carries the full burden and does so well: it discloses no network fetching, no execution, no checkpoint loading, and that output is a draft with unconfirmed provenance requiring review. It stops short of stating whether the import persists state or is idempotent, which matters for a tool that produces a 'model'.

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?

Five tight sentences, each doing distinct work: purpose, format preference, exclusions, return shape, and a caveat on fidelity. Purpose is front-loaded and no sentence is filler despite the dense technical vocabulary.

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 description does explain the return ('draft interaction table and model with embedded unconfirmed provenance'). For a tool with a nested source object and eight format variants, the remaining gap is the meaning of the source identifier and whether prior imports are affected.

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

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

Schema description coverage is 0%, so the description must compensate. It maps format families (BOM, OpenAPI, Quint, Lean, Julia) onto the enum and hints that modelingtoolkit-json/agents-json are the preferred values, but the nested 'source.id' field is undocumented in both schema and description, and 'text' semantics come only from the schema's byte-limit 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?

Opens with a specific verb and scope: 'Local-only import of supplied BOM, OpenAPI, Quint, Lean or Julia inputs.' The formats and the 'local-only' qualifier let an agent distinguish it from siblings like triz_export and triz_review_import 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?

Gives explicit format preference ('Prefer modelingtoolkit-json and agents-json exports from instantiated Julia models; raw julia is a partial static fallback') and clear exclusions ('Does not fetch references, execute source or load checkpoints'). It does not name a sibling alternative for the excluded cases, so routing to a different tool is left implicit.

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

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

With no annotations and no output schema, the description does real work by disclosing non-obvious runtime semantics: the search continues past incompatible automorphisms instead of failing fast, and it can return 'undecided' when the global budget is exhausted. It still omits the shape of a successful result (the found mapping) and any statement of side effects or cost beyond the budget.

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 padding, and the disambiguating detail (search continues past incompatible automorphisms, undecided on budget) is placed after the core purpose rather than buried. The telegraphic phrasing is efficient, though slightly compressed for a schema this large.

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 five-parameter tool with deeply nested objects, no annotations, and no output schema, the description leaves too much uncovered: the meaning of `profile`, the structure of `mapping`, and the possible result statuses are all missing. Only the budget/undecided behavior is adequately explained.

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% at the top level: `source`, `target`, `mapping`, `profile`, and `max_steps` carry no descriptions, and `mapping`'s six required sub-fields (boxes, ports, wires, carriers, dims, values) are undocumented. The description touches 'wiring' and 'global budget' (max_steps) but never explains `profile`'s enum (behavior/dynamics/feasibility/flows/all) or what each mapping section must contain.

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

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

Names a specific operation and resource: 'verify or search a bijection preserving wiring and declared semantic annotations', which tells an agent this is a structure-preserving mapping check between two models. It does not name or contrast any sibling (e.g. triz_transform, triz_rewrite_pair, triz_abstraction), so routing between them still requires 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?

The opening 'verify or search' hints at two modes but never states the trigger — that supplying `mapping` verifies and omitting it searches. There is no when-to-use guidance, no prerequisites, and no named alternative among the many triz_* siblings.

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

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

With no annotations, the description carries the full behavioral burden. It discloses useful traits such as the default all-packs behavior, domain-filter inclusion of universal definitions, that taxonomy assessments are advisory, and that the tool does not automatically invoke the matrix. It does not clearly describe read-only safety or response behavior, and its statement that fields supply no response contract is confusing rather than clarifying.

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 dense, jargon-heavy run-on that mixes purpose, return content, taxonomy caveats, default behavior, and matrix separation into a few long sentences. It is not well structured or front-loaded for an agent trying to quickly determine what the tool does.

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 listing tool with no output schema and no annotations, the description should clearly explain what the agent will receive and how to interpret it. It instead offers a sprawling list of possible concepts and an odd disclaimer that fields supply no response contract, leaving the output shape and practical usage insufficiently clear.

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 that query searches definitions and domain is optional and includes universal definitions. The description reinforces the default all-packs behavior and the universal inclusion rule, but adds little beyond what the 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 opens with 'List installed universal and domain knowledge packs' plus provenance, review status, models, observations, and counts, so the broad purpose is inferable. However, the long list of heterogeneous outputs and taxonomy caveats makes it hard to tell exactly what the tool returns, and it does not clearly distinguish itself from sibling tools such as triz_tool_catalog or triz_matrix beyond a separate note about canonical matrix parameters.

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 states defaults and filter behavior, including that all packs are used by default and a domain filter includes universal definitions. It also clarifies that these parameters are separate from the canonical 39 matrix parameters and that domain mappings do not invoke the matrix automatically, but it provides no explicit when-to-use guidance or alternatives among the many sibling tools.

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

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

With no annotations at all, the description carries the full burden and does much of it: exact rational arithmetic, holding cost charged once per decision step, the full return payload, box-local availability reading the request's acceptable list rather than global states, T3 ranges for undeclared probabilities, and undecided multichain/cap cases. It never states that this is a pure computation with no side effects, which is the main remaining gap for a no-annotation tool.

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

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

Four sentences, none wasted, with the purpose front-loaded and the return values following. The prose is jargon-dense ('exact rational average-cost equations', 'T3 ranges') and would benefit from one plain-language gloss, but the density is information, not 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 solver over a deeply nested model schema with no output schema, the description does supply the return values and key numerical guarantees, which is the bulk of what an agent needs. It still leaves unexplained which model fields are mandatory (lifecycle.states versus box.state/actions), how the box parameter selects a subproblem, and what max_steps and derive_prior do.

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

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

Schema description coverage is only 17%, so the description must compensate. It does clarify two parameters well — weights as per-dimension versus weighted objectives, and acceptable as the box-local availability list overriding the global list — and it implicitly explains box scoping. But max_steps and derive_prior are never mentioned in either the schema or the description, leaving those inputs opaque.

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 and resource: it solves finite declared maintenance actions as an average-cost problem and returns a stationary policy with gain, bias, occupancy, and availability. That is far more concrete than a restatement of the name. It does not name any sibling (e.g. triz_queue, triz_feasibility) that an agent should choose instead, 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?

Usage is only implied: the tool applies when maintenance actions and per-state holding costs have been declared on the model or on a box. There is no explicit 'use this when X, use triz_queue/triz_feasibility when Y' routing, and no stated prerequisites such as model must be reviewed. The closing note about multichain cases and caps is a limitation, not selection guidance.

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

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

With no annotations supplied, the description carries the full burden and does disclose a real behavioral trait: blank and diagonal cells fail closed rather than returning a fabricated recommendation. That tells an agent how to interpret empty results and discourages hallucinated principles. It does not describe the successful return payload (presumably principle IDs) or how to map those IDs to principles.

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 short sentences, front-loaded with the purpose and followed by the failure-mode caveat; nothing is padded or redundant.

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 lookup with full schema coverage and no output schema, the description covers purpose, failure semantics, and an anti-guessing rule. The remaining gaps—what the successful result contains and a pointer to triz_parameter for obtaining valid parameter IDs—are minor but real.

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 both parameters are documented with their 1-39 range in the schema, so the baseline is 3. The description confirms the semantic roles ('improving' vs 'worsening' engineering parameter) but adds no guidance on where valid parameter numbers come from, which would be the only meaningful addition 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 gives a specific verb+resource ('Look up the canonical contradiction matrix') and names the two inputs (improving/worsening engineering parameter), which is enough to separate it from sibling lookups like triz_principle or triz_parameter. It stops short of naming triz_matrix_multi as the multi-pair alternative, so differentiation is implied rather than stated.

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 implied by the input signature: use this when you have one improving parameter and one worsening parameter. The 'never guess a recommendation' warning is useful behavioral guidance but is not a when-to-use/when-not-to-use rule, and no alternative tool (e.g., triz_matrix_multi) is named for multi-pair 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?

With no annotations, the description carries the full burden and does reasonably well: it discloses the aggregation rule (count of recommending cells), the tie-break (mean position), that per-cell detail is returned, and the fail-closed behavior on all-blank or diagonal-only results. What is missing is any indication of permissions or cost, though for a read-only matrix lookup that is minor.

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

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

Three sentences, front-loaded with the operation and its aggregation rule, with no filler. The middle 'nothing is hidden' clause is slightly promotional but does convey per-cell transparency.

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

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

There is no output schema and no annotations, so the description must explain the result, and it does describe aggregation, tie-breaking, and per-cell return. The main gap is the shape of the returned data and what 'mean position' refers to, but the conceptual model is present.

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 both parameters are documented as integer arrays of 1-39 with examples, so the baseline is 3. The description reinforces the cross-product semantics of improving x worsening but adds no format or edge-case 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 opens with a specific verb-plus-resource: a multi-parameter contradiction lookup over the (improving x worsening) matrix, with principles aggregated. That distinguishes it from the singular triz_matrix sibling by the 'multi-parameter' qualifier, though it never states the distinction outright.

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

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

It gives an explicit selection rule: 'Use when a conflict involves several parameters on either side.' The alternative for a single-pair lookup is only implied through the name and the 'like triz_matrix' aside, not spelled out as a routing instruction.

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

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

With no annotations, the description carries the behavioral burden and does so well: it discloses that present is required, that transitions fail closed, that transition results are reported as net rewrite steps, that verdicts are carried when behaviour or feasibility is declared, and that missing windows are reported as prompts. It does not explicitly state whether the tool is read-only or whether it mutates the model, which is a notable omission for an analysis tool.

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

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

The description is a single dense block with long semicolon-heavy sentences and no clear front-loaded summary. All content is relevant to a complex tool, but the structure makes it hard to scan and the most important invocation guidance is buried. It could be substantially tightened and organized without losing 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?

For a complex seven-parameter tool with no output schema and no annotations, the description is fairly complete: it covers required inputs, transition failure semantics, view outputs, verdict carry-over, flow handling, and missing-window prompts. It does not provide a full example or state read/write safety, but the core complexity is addressed.

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 57%, so the description needs to add meaning, and it does: it explains past and future as snapshots or transitions, subsystem as a restriction to named boxes, system as the collapsed tool/mediator boxes, and acceptable as triz_weakness-style ranking. The transitions and verdict behaviour are described in prose beyond the schema. Some parameter details remain implicit, but the key semantics are covered.

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 operation: a system operator over function models covering past, present, future, and subsystem/system/supersystem views. It references related tools such as triz_transform, triz_behavior, and triz_flow, but does not give a concise, front-loaded statement of what the tool returns overall. The purpose is clear enough for an agent to identify it, though the density makes it less immediately distinguishable from siblings.

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

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

The description focuses on mechanics and input semantics rather than when to use this tool versus alternatives. It says present is required and describes optional snapshots and transitions, but does not explicitly say 'use this when' or 'prefer triz_transform instead when...'. There is only implied usage from the system-operator framing.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose useful content-level behavior ('alternate labels, interpretation guidance and nearby categories') and clarifies that these are historical matrix categories rather than typed quantities, which is real added context. However, it omits any statement about whether the lookup is read-only/cached, and 'where recorded' is vague about what the entry actually contains in edge cases.

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 short sentences, front-loaded with the core action and range, then the list mode, then entry contents. The phrase 'nearby categories to distinguish where recorded' is awkward and slightly hard to parse, which is the only real drag on an otherwise tight 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?

This is a simple single-parameter lookup with no output schema, so the description's summary of what entries contain (labels, interpretation guidance, categories) does the work a return-value spec would otherwise do. It also flags the conceptual distinction from typed quantities. Minor gap: no statement on whether all 39 entries are returned in full or summarized when id is omitted.

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 id parameter is already documented as 'Parameter number 1-39; omit to list all'. The description's 'Omit id to list all 39' restates the schema rather than adding syntax or semantics beyond it, so the baseline of 3 applies.

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

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

The description gives a specific verb and resource ('Get a canonical TRIZ engineering parameter (1-39)') and states the list-all mode, so the agent knows exactly what is retrieved. It also draws a boundary against 'typed domain quantities', which helps separate it from other knowledge lookups, though it never names the closest sibling (triz_principle) or triz_matrix explicitly.

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 does give one concrete usage rule: omit id to list all 39. That is guidance on invocation mode rather than on tool selection. Nothing says when to reach for this versus triz_principle, triz_matrix, or triz_knowledge, so an agent must infer routing from the description alone.

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

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

With no annotations, the description carries the full burden and discloses key behavior: it reports frontier, dominated, and trade-off relationships; never resolves incomparable candidates; and weights only order the listing without changing verdicts or being filled in. It also clarifies that values are declared inputs rather than measurements, though it does not state whether the operation is read-only or how invalid inputs are handled.

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 dense sentences are front-loaded with the core operation and contain no filler. The first sentence is long and packs several definitions, and some wording repeats the schema, but the complexity is largely warranted.

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 computation tool with no output schema and no annotations, the description explains the conceptual output categories (frontier, dominated-by, trade-offs) and the advisory role of weights, which is substantial. It still leaves the exact return structure and input-validation behavior unstated.

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 already 100%, and the schema itself defines candidates, metrics, directions with enum/default, and weights as advisory. The description reinforces the Pareto meaning but adds little parameter-level information beyond the existing schema descriptions, so the baseline score of 3 is appropriate.

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

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

States a specific operation ('Rank finite candidate designs jointly over declared metric vectors') and defines the frontier, dominance, and trade-off outputs. That is enough to distinguish it from sibling TRIZ tools that generate, model, or retrieve data.

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 concrete usage context by naming outputs from triz_feasibility, triz_lifecycle, triz_synthesize, and triz_component_search as candidate sources, and permits any finite comparable numbers. It does not state when not to use it or name an alternative ranking method.

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

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

No annotations are supplied, so the description carries the disclosure burden. "Get" implies a read-only lookup, and the omit-to-list behavior is stated, but the description never says what a principle record actually contains (title only? full text, examples, contradictions?), which is the main behavioral unknown for a knowledge tool.

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

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

Three short sentences, zero filler, with the core capability and the range front-loaded and the two call modes and the rationale trailing in order of importance.

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 reference tool with no output schema, the definition covers what an agent needs to invoke it correctly. The only omission is the shape of the returned principle data, which matters somewhat given there is no output schema to fall back on.

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 schema description already reads "Principle number 1-40; omit to list all", so the description's omit-to-list sentence adds nothing beyond structured fields. No syntax, default, or edge-case meaning is introduced.

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 ("Get a canonical TRIZ inventive principle") and bounds it with the 1-40 range, so an agent immediately understands this is a reference lookup table. It doesn't name a sibling to distinguish itself from, but the resource name is distinct enough from triz_parameter, triz_matrix, and triz_effects that confusion is unlikely.

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 explicit operating guidance: omit id to enumerate all 40, and use this tool rather than recalling principle numbers from memory. That covers both call modes. It stops short of saying when to prefer a sibling (e.g., triz_matrix for contradiction lookup), so it falls just shy of a 5.

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

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

No annotations are supplied, so the description carries the full burden. "Inspect" reasonably signals a read-only operation and "Optional project extension" warns that the required extension may be absent, which is useful precondition context, but nothing is said about failure modes, whether the node must actually be a contradiction node, or what the check results look 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 sentence with the optionality caveat first and zero filler. It is slightly dense with domain jargon ("purpose gate") that is never unpacked, but nothing is wasted.

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

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

For a one-parameter read tool with no output schema and no annotations, the description covers what is inspected (invariant, purpose gate, separation check) but leaves unclear whether the output is values, verdicts, or diagnostics, and how a non-contradiction node is handled.

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 id parameter already documents itself with a concrete example ("e.g. S1"). The description adds no meaning about the identifier beyond the schema, so the baseline 3 applies.

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

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

The description uses a specific verb ("inspect") plus a concrete resource set — invariant, purpose gate, and separation check of one contradiction node — scoped to "one contradiction node of the project graph." That is far more specific than the name alone, though it does not name or contrast any of the many separation-related siblings such as triz_separate or triz_global_separation.

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?

"Optional project extension" hints at a context (the project graph extension must exist) but gives no when-to-use guidance, no exclusions, and no routing among the many sibling TRIZ tools. An agent cannot infer from the description why it would choose this over triz_separate or triz_global_separation.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the important combinatorial trait that 'all declared arrival combinations within the schedule are considered,' which warns of state-space explosion. However, it says nothing about what is produced (no output schema exists), whether anything is mutated, how max_work bounds the search, or what happens on overflow detection.

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 the core action front-loaded and the combinatorial caveat placed as a follow-up. There is no filler, though the phrasing ('Compile a finite discrete queue with explicit arrivals...') is dense and could be marginally tighter.

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 eight-parameter, seven-required tool with no annotations and no output schema, the description should say what the caller gets back and how the overflow check is reported. It covers the inputs and the combinatorial semantics, but leaves the return behavior and the role of max_work unexplained. Adequate but with clear 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 63%, so the schema already documents arrivals, schedule, time_unit, quantity_unit, service_capacity and storage_capacity. The description only echoes those fields by name and adds no unit conventions, formatting rules, or meaning for undocumented parameters such as initial_backlog and max_work. It neither compensates for the coverage gap nor degrades below baseline.

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 concrete verb and resource: 'Compile a finite discrete queue' with arrivals, service capacity, storage capacity, schedule and units, then 'check overflow through existing dynamics.' That is far more specific than a restatement of the name. The only gap is that it does not name which sibling (e.g. triz_dynamics or triz_flow) it depends on, so the boundary against those tools is only implied.

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 statement of when to use this tool versus the many sibling modeling tools such as triz_flow, triz_dynamics, or triz_build_model. The phrase 'through existing dynamics' hints that a dynamics model must already exist, but this prerequisite is never stated as a condition. An agent must infer both the prerequisite and the usage scope.

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

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

With no annotations, the description carries the full burden. It does add one genuine behavioral fact — 'Fails closed on blank cells', meaning empty matrix intersections raise an error rather than returning nothing — which is valuable. It says nothing about read-only nature, output volume, or what 'expand' produces structurally.

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

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

Two sentences, front-loaded with the core action, and the failure-mode note is short and earns its place. No filler, no restatement of the tool name.

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

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

For a two-parameter, annotation-free, output-schema-free tool, the definition covers the core action and one edge case. It leaves the agent guessing about return shape (how principles and parameters are presented) and about sibling selection, which matters in a 50-tool family.

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 both parameters already carry range descriptions, so the baseline is 3. The phrase 'both engineering parameters' confirms the two inputs map to the matrix axes, but adds no new semantics such as directionality or example values.

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: 'Look up a contradiction-matrix cell' and 'expand its recommended principles and both engineering parameters'. That is clearly distinguishable from generic list/lookup tools, though it never names triz_matrix or triz_matrix_multi, which occupy adjacent territory 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?

There is no explicit when-to-use or when-not-to-use guidance. Given that triz_matrix, triz_matrix_multi, and triz_principle all exist, the description does nothing to route the agent between them or state prerequisites such as needing parameter numbers in the 1-39 range first.

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

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

With no annotations the description carries the full burden, and it does disclose two useful traits: the operation is local-only, and review is an assertion over supplied ratings and assumptions rather than a verification of source correctness. It omits the observable state change (draft to reviewed) and the consequence that draft models cannot drive analysis, which is what an agent most needs to reason about 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?

Three tight sentences, front-loading the local-only confirmation scope, then the procedure, then the epistemic caveat. Dense but every clause carries information; no filler or restatement of 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 a mutation tool over a very large nested model schema with no annotations and no output schema, the definition covers the decision payload well but leaves gaps: it does not say the argument model must include its provenance.pending list, nor what is returned (presumably the model now marked reviewed). Those omissions matter for a two-required-parameter write operation.

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 reported at 0% for the two top-level parameters, so the description must compensate. It does add real meaning for the decisions array — the id must be a currently pending id, each exactly once, decision is fixed to 'confirm', and note is optional — but says nothing about the 'model' parameter beyond 'edit the draft first', leaving the required full model payload unexplained.

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 and resource: explicit analyst confirmation of an imported model, closing out its pending review items. It is distinguishable from the import-side sibling by the 'confirm every pending id with decision confirm' clause, though it never names triz_import_source or any other sibling directly.

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?

'Edit the draft first, then confirm every pending id exactly once' gives a clear precondition and ordering, so the agent knows this is the terminal step after editing, not a first move. It stops short of naming the specific tools to use for editing or where pending ids come from.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the core behavior—replaying both orders and checking commutation—and adds a useful logical caveat, but it does not say whether the model is mutated, what happens when a rewrite cannot apply, or what the result contains.

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 definition is two sentences, front-loaded with the operation and followed by a meaningful caveat. There is no redundant or filler wording.

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 complex tool with three required parameters, nested rewrite objects, no annotations, and no output schema. The description does not explain the model parameter, the add/delete rewrite shape, prerequisites, failure behavior, or return values, so it is not complete enough for correct invocation.

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

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

The description identifies first and second as the rewrites being replayed, but leaves the model parameter unmentioned and does not explain the add/delete structure inside each rewrite. The word 'named' is also misleading because the schema has no name field for rewrites; with 0% top-level schema description coverage, this is a significant 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 gives a specific verb and resource: replay two named structural rewrites in both orders and check whether those occurrences commute. That distinguishes the operation from generic analysis tools, though it does not name which sibling rewrite or transform tools it replaces or differs from.

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 guidance or comparison to alternatives such as triz_rule_apply, triz_trim_rewrite, or triz_transform. The sentence about interference not proving nonconfluence is an interpretation caveat, not a usage rule for selecting this tool.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does add real value by declaring routing is deterministic and that only tools registered for the stage are returned, which tells the agent results are stable and pre-filtered. It says nothing about the return shape (bare names vs. objects with metadata), what happens with unrecognized signals, or error behavior on an invalid stage.

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 action and inputs, then a behavioral guarantee. No filler, no repetition of the title, and nothing that could be cut without losing 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?

The tool is simple (2 params, one enum, no nesting), but there is no output schema, so the description is the only source for what comes back. 'Returns only tools registered for that stage' hints at the payload but doesn't specify whether items are identifiers, names, or descriptors, nor how many candidates to expect. Mostly complete, with a meaningful return-value 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 both parameters are already documented, including the stage enum and the signals array. The description adds only the notion that signals are 'observable' and optional, which the schema already conveys via the required list. Baseline 3 applies since the schema does the heavy lifting.

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

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

States a specific verb (route) plus both inputs (problem stage, optional observable signals) and the output class (candidate TRIZ tools). An agent can distinguish it from concrete siblings like triz_principle or triz_matrix, which perform the work rather than dispatching to it. It stops short of naming a specific sibling as the alternative, keeping it at 4.

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 phrasing 'route a problem stage... to candidate TRIZ tools' suggests calling this when the workflow stage is known and the agent wants candidate tool names. There is no explicit statement of when to call this versus calling a sibling directly, and no exclusions. Adequate but leaves routing precedence to inference.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses typed-homomorphism verification, no-identification and no-dangling conditions, distinct carrier constraints, negative application conditions, step-budget outcomes such as decided:false and complete:false, fail-closed type checking, and deliverableKeysChanged.

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 content is relevant and front-loaded, but it is delivered as an extremely dense paragraph with long nested parentheticals that make it hard to scan. It would benefit from separating rule selection, match listing, application behavior, and return signals.

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 complex nine-parameter rewrite tool with no annotations and no output schema, the description covers modes, applicability conditions, failure behavior, and key return signals sufficiently for an agent to invoke it correctly. Remaining omissions are minor.

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 high at 89%, so the baseline is already strong, but the description adds critical meaning for rule_id built-ins, carrier variable binding, at as a seed, match application, limit, and max_steps. It adds less detail for ids beyond default generation.

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

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

The description opens with a precise characterization, 'Double-pushout rewriting with rules as data,' and explains inline rules versus built-in rule_id rules, including that 'uneven-development' is a detector rather than a rewrite. It does not explicitly distinguish this tool from sibling rewrite tools such as triz_rule_set or triz_rewrite_pair.

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 clearly explains the operational modes: omitting match lists matches, providing match applies one, and the uneven-development detector takes only the model. It also warns that an application is not evidence of improvement and points to triz_function_model compare_to, but it gives no explicit routing against the other rewrite-related siblings.

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

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

With no annotations, the description carries the full burden and does disclose real behavior: it validates only, guarantees termination under a strict lexicographic decrease of box/wire counts, and explicitly refuses to infer confluence or critical-pair completeness. It does not say what a failure looks like, whether all violations are reported or the first one aborts, or what the caller receives.

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 filler, with the core action stated first and the scope limitation second. The phrasing is dense ('lexicographic box/wire counts') but each clause carries information rather than restating the name.

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

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

This is a high-complexity tool over a deeply nested rule schema with no annotations and no output schema, so the description should explain what comes back (a verdict? a violation list? a termination certificate?). It also leaves 'named rule subset' unexplained – the schema has no name field, only an id per rule. The termination claim is stated but its output form is 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?

Top-level description coverage is 0% – the single `rules` parameter is never described in the description text, though the nested schema documents Rule, Pattern, forbid, distinct, and interface in detail. The mention of 'rule subset' and 'box/wire counts' hints at the array's shape and the termination measure but adds no binding, ordering, or cardinality guidance beyond the schema's maxItems of 100.

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 object: 'Validate a named rule subset' plus the termination property it establishes over box/wire counts. The closing sentence scopes it against stronger notions (no global confluence or critical-pair completeness), which helps separate it from rewrite-application siblings like triz_rule_apply, though no sibling is named outright.

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: validation and termination checking precede applying a rule set, and the negative sentence tells the agent what conclusions it must NOT draw. There is no explicit 'use this when…' or 'use triz_rule_apply instead' routing, and no prerequisites such as whether a model must exist first.

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

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

With no annotations at all, the description carries the full burden and does so well: it enumerates the three return statuses (compatible, separated, irreducible), explains the conflict-cell output, and describes the extra data returned under `along` including the 'checkable part of Principle 15' nuance. It stops short of stating that the tool is side-effect-free/computational, but the analysis framing implies it.

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 first sentence is well front-loaded and the important part (what it decides and returns) leads. However, the remainder is a dense run-on block with long parenthetical enumerations of principles and sibling tools, making it hard to scan; several clusters could be broken into short discrete statements without losing content.

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

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

For a tool with a nested contradiction object, a five-value axis enum, and no output schema, the description supplies an unusually complete picture of inputs and outputs, including the suggestions payload and its per-axis hints. It is nearly self-sufficient, with the only omission being the absence of any safety/mutation note, which matters little for an analysis routine.

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 50%, so the description must compensate and largely does: it explains that `along` returns the parameter as a function of that axis and demonstrates the 'time' case, and it clarifies the Demand semantics ('omitted axis = whole axis', values as admissible set). The nested contradiction structure is left to the schema, but the key behavioral meaning of `along` is well covered.

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 opening sentence gives a specific verb (Decide) and precise resource (whether a physical contradiction's demands can be met piecewise over a finite space x time x condition x direction x level base), naming the MATRIZ separation types. It clearly distinguishes the operation from generic resolution siblings by scoping it to piecewise separability, though it never names triz_global_separation or triz_resolve as the contrasting alternatives an agent would weigh.

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 implied rather than prescribed: the agent can infer this is the tool for testing separability of an existing physical contradiction with demands. There is no explicit when-to-use/when-not statement and no routing to alternatives such as triz_global_separation or triz_resolve, which is the main gap given how many sibling resolution tools exist.

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

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

With no annotations, the description carries the full burden and does real work: it discloses that verification is exact over explicit assumptions, bounded and nonblocking, that circular-resource-support and source-support-cap results are reported as undecided rather than failed, that max_support_work caps support checking independently of the state cap, and that caller-supplied checked status is never trusted. That last clause is a genuinely valuable trust-boundary disclosure. It stops short of describing side effects, permission needs, or result shape, and several phrases are too opaque to act on.

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 opening clause is appropriately front-loaded with the declared-versus-verified distinction, and most sentences carry information. But the prose is a chain of dense noun phrases ('bounded closure as flat feasibility', 'declared empirical assertion') with no structural separation between what is checked, what is undecided, and what is capped, which slows comprehension more than the length warrants.

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 complex six-parameter tool with deep nested objects, no annotations, and no output schema, the description covers verification semantics, undecided handling, and one cap but never sketches what a result looks like beyond the word 'undecided', nor how model/box/contract relate. It is more informative than most siblings but leaves the agent guessing about the response and the framing parameters.

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 17%, so the description must compensate and it partly does: it explains the declared-vs-verify meaning of 'mode', names the contract content it evaluates (behavior, assumptions, levels, demands, budgets, operating envelope), and explains max_support_work's role and independence from the state cap. But 'box', 'model', and especially 'max_states' receive no treatment at all in the description, leaving three of six parameters 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 first sentence names a specific operation, distinguishing a merely declared subsystem summary from one verified against the inner steady-state relation and a declared resource mode, and the 'mode' enum (declared/verify) anchors that. However, the contrast target is described only obliquely ('a declared subsystem summary') rather than naming the sibling tool triz_subsystem_summary, and the surrounding noun stacks ('bounded closure as flat feasibility', 'source support') make the core purpose hard to extract on a first read.

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 implies verification happens under 'verify' mode and that missing data or unsupported modes yield 'undecided', but never states when an agent should call this instead of triz_subsystem_summary, triz_feasibility, or triz_behavior. No prerequisites, no exclusions, no routing rule; the reader must infer the choice from jargon.

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

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

With no annotations, the description carries the full burden and does disclose some real behaviour: two computation paths (symbolic compiler for complete serial maps, exact projection otherwise) and the policy that empty relations are explicit while missing behaviour stays unknown. It omits error conditions, the effect of max_states truncation, and what the returned boundary relation/port map actually contain.

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

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

Three sentences, no filler words, and the core claim is front-loaded. However, the density of undefined terms ('exact finite boundary relation', 'checked symbolic compiler', 'exact finite projection') means the text is compact but not communicative, so brevity does not translate into clarity.

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

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

This is a complex tool operating on a large nested model schema with no output schema, so the description must explain results; it only names three output artefacts without describing structure or meaning. With siblings like triz_subsystem_contract unaddressed and parameters undocumented, the definition is not sufficient for confident 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?

Top-level schema description coverage is 0%: id, boxes, model, and max_states have no descriptions. The tool text mentions 'port map', 'fixed cost', and 'hidden-harm list', none of which map to the four parameters, and it never explains that boxes selects which subsystem components are summarised or what max_states bounds. The description does not 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 names a verb and resource ('Compose a stateless subsystem') and gestures at the output ('exact finite boundary relation with explicit port map, fixed cost, hidden-harm list'), but 'exact finite boundary relation' is unexplained domain jargon. It also fails to distinguish this tool from the adjacent sibling triz_subsystem_contract, leaving the agent to guess which one to select.

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 instead of triz_subsystem_contract, triz_behavior, or triz_feasibility. The sentence about 'checked symbolic compiler' versus 'exact finite projection' describes internal routing behaviour, not a use-case condition the agent can act 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?

With no annotations, the description carries real behavioral weight: it discloses that capped search yields an undecided (not negative) result, that impossibility claims are scoped to the declared library, and that bounded fallback occurs during optimized/symbolic search. These are non-obvious, high-value traits an agent could not infer from schema alone. It stops short of describing cost, runtime expectations, or output 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?

Five sentences, technically dense but not padded; the operational caveats at the end earn their place. It is not front-loaded well though — the second sentence is a dense run of jargon ('typed joint finite maps across explicit wire permutations') that impedes comprehension more than it informs tool selection.

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 high-complexity tool (12 params, deep nested schema, no output schema, no annotations), and the description covers the search semantics well but says nothing about what the caller receives back (satisfying tuples? violation reports? certificates?). Without an output schema, the return-value gap is a meaningful omission for a tool this intricate.

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?

At 50% schema coverage the description must compensate, and it partially does by explaining what 'optimized' and 'symbolic' strategies actually do, grounding the strategy enum. However, seven of twelve parameters (max_work, max_states, optimizations, max_pruning_work, max_symbolic_work, max_symbolic_cells, include_symbolic_certificate) are not addressed at all, and the contract/holes/model/implementation semantics are left to 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 first sentence states a specific action on a specific resource: searching finite behavior/resource alternatives over fixed wiring. But 'synthesize' as an outcome (producing implementations that satisfy a contract) is only implied by 'Every surviving tuple meets one shared engineering contract', and nothing distinguishes it from siblings like triz_feasibility, triz_implementations, or triz_subsystem_synthesize-adjacent tools. The core purpose is recoverable but requires domain familiarity.

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 reach for this tool versus alternatives; the mention of 'optimized', 'symbolic', and 'exhaustive' compares internal strategies, not sibling tools, and that comparison is already in the strategy parameter's schema description. The closest to usage guidance is a caveat ('Capped search is undecided'), which is behavioral, not a when-to-use rule.

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

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

No annotations are provided, so the description carries the behavioral burden. 'List' implies a safe read-only operation, but it does not state side effects, authentication needs, pagination, or the shape of returned catalog entries.

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

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

The description is a single front-loaded sentence with no wasted wording. Every phrase, including the domain-neutral scope and stage restriction, 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 low-complexity tool with one optional enum parameter, the description adequately covers what is listed and how it can be filtered. It could say more about the returned catalog entries since no output schema exists, but it is largely complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by expanding the enum values into conceptual stages: problem analysis, task modeling, and solution synthesis.

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 ('List') and resource ('TRIZ tool catalog'), plus scope ('domain-neutral'). It does not explicitly distinguish this catalog from sibling catalogue/search tools such as triz_component_catalogue, so it falls 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?

Provides only an optional stage restriction, with no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The discovery use case is implied but not stated.

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

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

With no annotations supplied, the description carries the full disclosure burden and does well on failure semantics ('Every result type-checks or the call fails closed with ok:false') and return extras (behaviorallyIndependent, behavior.finest with cut/splitsFurther/decided, undo from reverse). It also warns about a non-obvious side effect: merge renames ports to '<box>.<port>' so no box_map recovers a merged product box's deliverables. It does not state the overall response envelope (where the new model and ok live, or what ok:false carries), leaving a gap a caller would want closed.

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?

Purpose and the op catalogue are front-loaded, and the closing sentences cover the validation workflow and the two gotchas (merge renaming, reverse's undo). Every clause corresponds to a distinct op, but the single dense paragraph packed with parenthetical principle numbers and nested `behavior.finest` fields is harder to scan than a list would be.

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 13-variant transformation dispatcher with no output schema, the description covers the operation semantics, the fail-closed contract, the extra report fields (behaviorallyIndependent, finest partition diagnostics, box_map, undo), and the follow-up comparison workflow. The remaining gap, the exact response envelope, is modest given that no output schema exists to carry 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?

Top-level schema description coverage is 0% (model and transformation are undocumented), so the description must compensate, and it largely does: it explains the discriminating semantics of each variant, e.g. take_out's two readings ('harmful or excessive' vs 'all useful functions'), merge's 'boxes consecutive on a declared flow are adjacent', and rerate's partial vs feedback readings. It does not cover cost_to on take_out or explain retarget's keep_harm and id defaults, which remain schema-only.

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 opening sentence gives a specific verb and resource: 'Apply one typed model transformation and return the new model.' It then enumerates every supported op with its TRIZ principle number, so an agent can tell exactly which transformations are available. It stops short of differentiating itself from siblings such as triz_trim, triz_rewrite_pair, or triz_rule_apply, which overlap in scope.

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

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

It gives clear downstream guidance: 'A transformation is a structural move, not evidence that it solves the problem: model the result and compare it with triz_function_model compare_to, or with triz_behavior compare_to when behaviour is declared, passing the boxMap...'. That is real workflow routing, including which comparison tool to pick based on whether behaviour is declared. It does not say when a caller should prefer a sibling transformation tool over this one, so no explicit exclusions.

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

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

With no annotations, the description carries the full burden and does well: it discloses the returned sections (per-function absorbers, orphaned functions blocking the trim, harms and costs removed, one problem per absorber) and warns that a carrier match is only a necessary condition. The main gap is that it never states explicitly that the tool is read-only analysis and does not mutate the model.

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 dense sentences, front-loaded with the purpose and then the rules and outputs; no filler. The rule-letter parentheticals are long but earn their place by making the screening criteria self-contained.

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

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

Given a huge embedded model schema and no output schema, the description supplies what an agent needs: what the screening does, what comes back, and how to interpret the result. Only the relationship to sibling trim/absorber 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 description's phrase 'trimming of one or more boxes' matches the `trim` array of box ids, which the schema already documents as 'Ids of the boxes to remove'. The `model` parameter is an unlabeled $ref whose semantics come entirely from the nested schema, so the description adds little beyond structured data at 50% coverage.

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

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

The description opens with a specific verb and resource ('Screen a trimming of one or more boxes') and enumerates the three TRIZ trim rules A/B/C, so an agent can tell what the tool computes. It does not name the closely related siblings (triz_trim_rewrite, triz_absorber_assignments), which keeps 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?

Usage is implied: this is the screening/verification step for a candidate trim, and the closing sentence tells the agent to treat every absorber as a hypothesis to substantiate. However, there is no explicit statement of when to prefer this over triz_trim_rewrite or triz_absorber_assignments, so routing among siblings is left to inference.

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