abba_fiji_stop

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is structured data. The description goes beyond that by specifying the concrete consequence (the ABBA window closes, unsaved work is lost) and the surprising interaction behavior when invoked during a start. It does not cover auth, latency, or post-stop state, so it is strong but not exhaustive.

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?

Roughly four tight sentences: what it does, the permission gate, the anti-pattern, and the alternative. The destructive consequence is front-loaded in the first sentence and nothing is redundant.

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 one-parameter destructive stop tool with no output schema, the description supplies everything needed to decide and to call correctly: the effect, the required user authorization, and what to use instead for non-destructive inspection.

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 coverage is 100% and the single parameter is fully documented in-schema as the user's quoted words. The description reinforces the gating intent ('the user explicitly asks') but adds no syntax, format, or validation detail beyond what the schema already provides, so the baseline of 3 applies.

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 resource ('Stops the Fiji this extension started') and immediately scopes the blast radius ('the ABBA window closes and unsaved work is lost'). An agent can distinguish this from read-only siblings like fiji_ui_windows_read or abba_window_picture without opening any schema.

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?

Gives an explicit trigger ('Only when the user explicitly asks to stop or restart Fiji'), an explicit exclusion ('Never to check, wait for or speed up a start'), and names the alternatives to use instead for inspection. It even warns that a slow start is normal and that stopping mid-start restarts the whole process.

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