Skip to main content
Glama

triz_weakness

Rank candidate concepts by the operating situations they admit: compare set inclusion to find which admits every situation others admit, with optional priors for weighted ranking.

Instructions

Rank candidate concepts that declare behaviour by the operating situations they admit (references/weakness.md). A situation is a valuation of the concepts' boundary inputs (unwired input ports, matched by box and port id) over their carriers' declared values: the declared input space is weakness.md's list of operating situations. A concept admits a situation when it has a steady state there and every deliverable output there is acceptable (acceptable: per deliverable port, or per carrier for all its deliverables, the values that are, listed or derived from a threshold at_least/below that is a declared level of the carrier; required for every deliverable; derived sets are listed under acceptable in the result). Give each operating condition the same box and port id in every concept (e.g. an environment box with an unwired input); readByOne lists the inputs only one concept reads. Ranked by set inclusion: weakest (admits everything any other admits), maximal, and every pair as equal, first-weaker, second-weaker, or incomparable, with a situation only one admits each way. The admitted count is a secondary figure: it depends on how finely carrier values are declared. priors gives a real prior over the situations (weakness.md: a real prior beats the uniform assumption): per situation input (box and port), or per carrier, a nonnegative weight per declared value (unlisted inputs and values count 1; 0 rules a value out); each concept carries the total prior mass of what it admits (weightedAdmitted, ranked in byWeight), and no inclusion ever moves under weights. joint_prior is the alternative for correlated operating conditions: an explicit complete joint table, a weight for every situation (zero allowed), with no independence assumption; it reports jointAdmittedWeight and jointAdmittedProbability per concept, ranked in byJointPrior, separately from inclusion and counts. Give priors or joint_prior, not both. Fails closed when the concepts deliver different ports, an input several read ranges over different values, or acceptable misses a deliverable or names an undeclared value, or a prior is malformed; undecided on missing behaviour or past the state cap. Filter concepts for adequacy first; for safety, integrity, or authorisation decisions admitting more is the wrong direction.

Input Schema

NameRequiredDescriptionDefault
scopeNo
priorsNoA prior over the operating situations (weakness.md: a real prior beats the uniform assumption): per situation input (box and port), or per carrier, the weight of each declared value. weightedAdmitted is each concept's total admitted mass and byWeight ranks by it; the inclusion ranking and the pairs never change
conceptsYesCandidate concepts, each a model that declares behaviour for every box that can reach a deliverable
acceptableYesPer deliverable port (a product input port), or per carrier for every deliverable it carries, the acceptable values: listed, or derived from a threshold (at_least, below) through the carrier's levels. An output is acceptable when every deliverable's value is
max_statesNoCap on situations and search states per concept (default and maximum 100000)
joint_priorNoInstead of priors, for correlated conditions: explicit joint mass for EVERY complete situation, including zero mass; no independent-input assumption. jointAdmittedWeight and jointAdmittedProbability per concept, ranked in byJointPrior
lifecycle_priorsNoOpt-in concept-specific priors from each model lifecycle occupancy; each state needs a complete situation mapping

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A3.6/5.0
Behavior4/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 well: it enumerates fail-closed conditions (differing delivered ports, an input reading ranges over different values, acceptable missing a deliverable, malformed priors), the 'undecided' outcomes (missing behaviour, past the state cap), and the caveat that admitted counts depend on how finely carrier values are declared. It also names result fields (readByOne, weightedAdmitted, byWeight, jointAdmittedWeight, jointAdmittedProbability, byJointPrior) and states that inclusion never moves under weights. It stops short of describing the full response shape or performance characteristics beyond max_states.

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

Conciseness2/5

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

The content is front-loaded with the purpose, but everything after it is one unstructured paragraph of nested parentheticals, e.g. the single sentence defining what admitting a situation means, which buries 'per deliverable port, or per carrier ... listed or derived from a threshold at_least/below' inside a clause. Several sentences duplicate schema text (prior weight defaults, carrier precedence) rather than earning new space, and the dense run-on style makes the definition hard to parse even though the total length is defensible for a seven-parameter analysis tool.

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

Completeness3/5

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

For a complex ranking tool with no output schema, the description covers the core semantics, failure modes, and the main result fields adequately. But it leaves `scope` (the one enum parameter) and `lifecycle_priors` — a whole opt-in prior mechanism with per-concept weights and max_steps — entirely undocumented, and gives no sense of result ordering or size beyond the state cap. An agent could call it, but would be guessing on two parameters.

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

Parameters3/5

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

Schema coverage is high at 86%, so the baseline is 3, and the description mostly restates what the schema already says (unlisted weights count 1, 0 rules a value out, carrier entry as 'instead of box and port'). It does add genuinely new meaning the schema does not encode: priors and joint_prior are mutually exclusive, weighted ranking never alters the inclusion order, and inclusion is the primary ranking with counts secondary. However, the `scope` enum (upstream/whole) and the entire `lifecycle_priors` parameter are never mentioned in the description and carry no schema description for scope, so two of seven parameters are left unexplained.

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 clause gives a specific verb and resource: 'Rank candidate concepts that declare behaviour by the operating situations they admit', and it points to references/weakness.md for the underlying notion. It distinguishes itself implicitly from triz_adequacy ('Filter concepts for adequacy first') and from counting-based siblings by insisting ranking is by set inclusion. It does not name a sibling that does a similar ranking (e.g. triz_pareto), so an agent must infer the boundary, which keeps it below 5.

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 real ordering guidance ('Filter concepts for adequacy first'), an explicit either/or constraint ('Give priors or joint_prior, not both'), and a domain caution that 'for safety, integrity, or authorisation decisions admitting more is the wrong direction'. It never states a when-not-to-use case or names the competing sibling, so it falls short of the top band.

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