Validates a named rewrite-rule subset and proves termination via strictly decreasing lexicographic box/wire counts; does not infer global confluence or critical-pair completeness.
Validate a named rule subset and establish termination when every successful application strictly decreases lexicographic box/wire counts. No global confluence or critical-pair completeness is inferred.
| Name | Required | Description | Default |
|---|---|---|---|
| rules | Yes |
Changes observed during successful MCP inspections.
v0.5.1Does 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.