Skip to main content
Glama

triz_feasibility

Decide whether a TRIZ function model meets its resource budget: compute minimal resource vectors, return feasible, infeasible, or undecided verdicts, and suggest budget or capability raises.

Instructions

Monotone co-design feasibility (Censi 2015) from declared box feasibility rows: each row provides a level per output port against the levels it requires per input port and an operating cost, read monotonically (providing less never needs more; more resources never hurt). The product boxes' rows are the demand. An output port feeding several functions meets the largest of their demands on an intensive carrier (the default: one shared level) and their sum on a carrier declared quantity: extensive. Composes the rows along non-harmful functions, including feedback loops, by Kleene's ascent from nothing demanded to the least fixpoint, and returns the minimal resource vectors (fixed costs of every box plus the chosen rows' operating costs), each with its rows and demanded levels. Verdict against the model's budget: feasible; infeasible (reason over-budget, with the binding dimensions every minimal vector exceeds, or unprovidable, naming the port no row can serve); or undecided (missing-feasibility, no-budget, unbudgeted, circular-resource-support). A bounded source-support closure from zero provision must ground a selected affordable witness; steadyState reports the separate balance verdict. With trim and absorb (as triz_behavior takes them), apply the trim and decide the trimmed model; the baseline is solved only to report each absorber's added resources. When carriers declare levels (thresholds reading amounts as declared values), levels reports each feasibility row, of a box that also declares behaviour, whose named amounts read as values no matching behaviour row gives (value-mismatch) or at inputs the behaviour rules out (no-behavior-row). Fails closed on ill-typed or dominated rows, a requirement no non-harmful function supplies, an extensive input fed by several functions (extensive-fan-in: model a merge box), and past the caps. No polynomial bound is claimed. The verdict holds for the rows as declared; the absorber's new harms are not modelled. An infeasible verdict also carries relaxation: over-budget results list the nondominated minimal budget raises that would make the model affordable, each with its row-selection witness (budget_feasible_iff), and the cheapest raise of any single dimension that suffices alone; unprovidable results list the smallest per-port capability raises. Raises advise; the budget stays the caller's declaration.

Input Schema

NameRequiredDescriptionDefault
trimNoBoxes to trim; with it, decide whether the remaining boxes provide what the trim leaves them within budget
modelYes
absorbNoWith trim: function wire id → absorber output port; default: the first absorber triz_trim lists
max_antichainNoCap on antichain elements per step (default and maximum 1000)
max_iterationsNoCap on Kleene steps (default and maximum 1000)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A3.9/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 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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.