Checks a model for nonblocking, acceptable outputs across required operating situations under an explicit scope, confirming design adequacy.
Check nonblocking and acceptable outputs over required operating situations under an explicit scope. Equality of two partial relations does not establish adequacy.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| scope | No | whole | |
| acceptable | Yes | ||
| max_states | No | ||
| required_inputs | No |
Changes observed during successful MCP inspections.
v0.5.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden of behavioral disclosure. It adds one cryptic caveat about partial relations, but does not state whether the tool is read-only, what it returns, whether it requires a complete model, or how it reports failures.
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 description is short and front-loaded, with no filler sentences. Its brevity, however, comes at the cost of clarity: the second sentence is cryptic and the first relies on undefined jargon.
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 five-parameter, nested-model analysis tool with no annotations and no output schema, yet the description gives only a high-level and ambiguous notion of what is checked. It is not complete enough for an agent to invoke the tool correctly without opening the schema and guessing at intent.
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 reported as 0%, and the description does little to compensate. It vaguely gestures at 'explicit scope', 'acceptable outputs', and 'required operating situations', but does not explain the roles of model, acceptable, scope, max_states, or required_inputs.
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 states a checking activity over outputs and operating situations, which is more specific than the name alone. However, 'nonblocking' is undefined and the description does not distinguish this check from siblings like triz_behavior or triz_feasibility, leaving the agent to infer what 'adequacy' really covers.
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, no mention of prerequisites, and no comparison with the many sibling analysis tools. The phrase 'under an explicit scope' hints at a condition but does not tell the agent when this tool should be chosen over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.