triz_isomorphism

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations and no output schema, the description does real work by disclosing non-obvious runtime semantics: the search continues past incompatible automorphisms instead of failing fast, and it can return 'undecided' when the global budget is exhausted. It still omits the shape of a successful result (the found mapping) and any statement of side effects or cost beyond the budget.

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?

A single dense sentence with no padding, and the disambiguating detail (search continues past incompatible automorphisms, undecided on budget) is placed after the core purpose rather than buried. The telegraphic phrasing is efficient, though slightly compressed for a schema this large.

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?

For a five-parameter tool with deeply nested objects, no annotations, and no output schema, the description leaves too much uncovered: the meaning of `profile`, the structure of `mapping`, and the possible result statuses are all missing. Only the budget/undecided behavior is adequately explained.

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?

Schema description coverage is 0% at the top level: `source`, `target`, `mapping`, `profile`, and `max_steps` carry no descriptions, and `mapping`'s six required sub-fields (boxes, ports, wires, carriers, dims, values) are undocumented. The description touches 'wiring' and 'global budget' (max_steps) but never explains `profile`'s enum (behavior/dynamics/feasibility/flows/all) or what each mapping section must contain.

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?

Names a specific operation and resource: 'verify or search a bijection preserving wiring and declared semantic annotations', which tells an agent this is a structure-preserving mapping check between two models. It does not name or contrast any sibling (e.g. triz_transform, triz_rewrite_pair, triz_abstraction), so routing between them still requires inference.

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?

The opening 'verify or search' hints at two modes but never states the trigger — that supplying `mapping` verifies and omitting it searches. There is no when-to-use guidance, no prerequisites, and no named alternative among the many triz_* siblings.

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