Replay two named structural rewrites in both orders to check whether their occurrences commute and detect interference; interference alone does not prove nonconfluence.
Replay two named structural rewrites in both orders and check whether those occurrences commute. Interference does not prove nonconfluence.
| Name | Required | Description | Default |
|---|---|---|---|
| first | Yes | ||
| model | Yes | ||
| second | Yes |
Changes observed during successful MCP inspections.
v0.5.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the core behavior—replaying both orders and checking commutation—and adds a useful logical caveat, but it does not say whether the model is mutated, what happens when a rewrite cannot apply, or what the result contains.
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?
The definition is two sentences, front-loaded with the operation and followed by a meaningful caveat. There is no redundant or filler wording.
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 complex tool with three required parameters, nested rewrite objects, no annotations, and no output schema. The description does not explain the model parameter, the add/delete rewrite shape, prerequisites, failure behavior, or return values, so it is not complete enough for correct invocation.
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?
The description identifies first and second as the rewrites being replayed, but leaves the model parameter unmentioned and does not explain the add/delete structure inside each rewrite. The word 'named' is also misleading because the schema has no name field for rewrites; with 0% top-level schema description coverage, this is a significant gap.
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?
The description gives a specific verb and resource: replay two named structural rewrites in both orders and check whether those occurrences commute. That distinguishes the operation from generic analysis tools, though it does not name which sibling rewrite or transform tools it replaces or differs from.
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?
There is no explicit when-to-use guidance or comparison to alternatives such as triz_rule_apply, triz_trim_rewrite, or triz_transform. The sentence about interference not proving nonconfluence is an interpretation caveat, not a usage rule for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.