Skip to main content
Glama

triz_transform

Applies one typed TRIZ transformation to a function model and returns the resulting type-checked model, failing closed if the transformation is invalid.

Instructions

Apply one typed model transformation and return the new model. Principle constructions: segment (1: divide a box into parts whose ports partition its ports), take_out (2: separate the ports touching a harmful or excessive function, or isolate the part carrying all useful functions), merge (5: collapse adjacent or identical boxes into one; boxes consecutive on a declared flow are adjacent), standby (11: add an unwired typed absorber for a box's functions), reverse (13: swap a function's performer and object), rerate (16: rate a useful function insufficient or excessive; 23: change the level of a function on a cycle), retarget (22: a harmful function's source feeds a useful function), feedback (23: add a function that closes a loop), interpose (24: route a function through a new mediator box), cheap_copy (26, 27: replace a box by a cheaper copy with the same ports). Also trim (perform a typed-feasible trim, re-attaching each kept function to an absorber; rule B is Principle 25, one absorber for everything is Principle 6) and rewrite (delete and add boxes and wires; no remaining wire may touch a deleted box). Every result type-checks or the call fails closed with ok:false. When the segmented box declares behaviour, segment (and take_out) reports behaviourallyIndependent: whether the box's relation is the product of its projections onto the parts; if so each part gets its projection, else no part gets behaviour and each coupled part is named with a witness: two rows whose mix is not a row. It also suggests the finest partition of the box's ports over which its relation is a product (behavior.finest: parts; cut, the suggested blocks the given parts cut, empty iff the split holds; splitsFurther, when nothing is cut, the parts that hold several blocks; decided:false past the cap). interpose's mediator may declare behavior (rows, or 'identity'). 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 segment, take_out, or cheap_copy returns as box_map. merge renames the merged ports to '.', so no box_map recovers a merged product box's deliverables: they read as lost and regained. reverse returns undo, a rewrite that restores the original model, added ports included.

Input Schema

NameRequiredDescriptionDefault
modelYes
transformationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.