Skip to main content
Glama

triz_rule_apply

Apply double-pushout rewriting rules to TRIZ function models: list valid matches or apply a chosen match to delete and create boxes, ports, and wires, returning a type-checked model.

Instructions

Double-pushout rewriting with rules as data. A rule is a span L ← K → R of patterns over the function-model schema (boxes with ports typed by carrier variables, and wires); pass it as rule, or name a built-in evolution-line rule with rule_id: 'mono-bi' (transition to supersystem, mono → bi; apply again for poly), 'feedback' (increasing controllability, self-adjusting with feedback; bind its carrier variable 's' with carriers), or 'working-field' (changing the working field: the matched function re-made on another carrier; bind 'd' with carriers to a carrier other than the matched one; the result's fieldChanges records both carriers' layer and dimension). Each built-in rule cites the evolution-trends.md line it encodes. rule_id 'uneven-development' is a detector, not a rewrite, and takes only the model: the lagging subsystem, a box of the largest harm-loop region that is also on a binding feasibility dimension or limits a deliverable (feasibility finds it unprovidable, or it performs an insufficient function on a product); verdict lagging, none, or undecided (no harm loop, or feasibility undecided). Without match: lists every injective match of L (seed it with at), each verified as a typed homomorphism and marked applicable when the no-identification and no-dangling conditions hold (a deleted box may not lie on a declared flow) and the rule's distinct carrier variables bind different carriers; decided:false if the step budget runs out, complete:false past limit. A rule's forbid holds negative application conditions (Habel–Pennemann): each pattern extends left by id, and a match that extends to an occurrence of one — including any elements the pattern adds — is not applicable; a condition its own step budget cannot decide also refuses the application. With match (a listed match, or your own mapping): checks the match, these conditions, and that a kept box keeps the ports its declared rows name (every port for behavior and transition; the named ports for feasibility), then deletes the image of L \ K, glues R \ K under fresh ids, and returns the new model, which type-checks or the call fails closed; deliverableKeysChanged says a deliverable moved to another port or carrier. A rule application is a structural move, not evidence that it helps: compare the result with triz_function_model compare_to.

Input Schema

NameRequiredDescriptionDefault
atNoPartial match that seeds the search, e.g. { wires: { f: 'w-drive' } }
idsNoIds for created elements; default: fresh ids based on the rule's or the copied element's
ruleNoAn inline rule; give this or rule_id
limitNoMost matches to list (default 50)
matchNoThe match to apply at; omit to list matches
modelYes
rule_idNoA built-in evolution-line rule, or the 'uneven-development' detector
carriersNoCarrier variable used only on the right side → model carrier id
max_stepsNoSearch step budget (default 100000)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A4.2/5.0
Behavior5/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.