Run one Nisi workflow locally

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

Very strong disclosure beyond the annotations: a private temporary directory that is removed afterwards, no reads or writes of project files, no execution of generated code, and the return contract (proposed contents plus Nisi's report). It also describes ticket lifecycle behavior — admitted before the run, refused on write-scope overlap, released afterwards — which the annotations cannot convey. All of this is consistent with readOnlyHint=true and openWorldHint=false.

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?

Three sentences, front-loaded with what the tool does, then safety constraints, then test semantics — no wasted clauses. The sentences are long and densely packed, which slightly strains readability, but every clause carries substantive information.

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?

With no output schema, the description does the necessary work of stating what comes back (proposed contents and Nisi's report) and what does not happen on disk, which is exactly what an agent needs before committing to a run. Gaps remain around failure modes beyond ticket refusal, timeout behavior, and repair_budget/acceptance_criteria semantics for an 8-parameter tool with nested objects.

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 50%, so the description must carry more weight. It does add meaning for 'files' (current contents the models may change), the ticket flow, and assertions ('contains/not_contains' alongside built-in checks), but it is silent on acceptance_criteria, timeout_seconds, repair_budget (only 'bounded repair' is hinted at, no default of 1 or cap of 3), and new_files. Adequate but incomplete given the coverage 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 — 'Run one Nisi v0.2.0 workflow' — and enumerates the pipeline stages (draft, syntax check, tests, independent review, bounded repair), plus the crucial input distinction that it operates on 'file CONTENTS you pass in' rather than a project path. That is clearly separable from sibling tools like agiw_status, agiw_readiness, and agiw_jev_*.

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 description establishes the usage context well: the caller supplies file contents, the run is sandboxed in a temp directory, and the caller is expected to 'review and apply yourself.' It also states the conditional ticket requirement is governed by config. However, it never names an alternative tool or states explicit when-not-to-use-this conditions relative to the agiw_* siblings, so it stops short of full routing guidance.

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