close_uvision

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

Rich disclosure well beyond the annotations: warns that windows under manual viewing will be closed, details the graceful-close-then-force-terminate fallback flow for force=False, explains the polling wait to avoid false residue reports, flags sandbox permission/cross-session limitations, and labels the operation irreversible in the risk section. No contradiction with destructiveHint=true.

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 core purpose is front-loaded and the flow from purpose to parameter behavior to return values is logical. The main paragraph is dense, and the risk section slightly repeats the window-closing warning already stated earlier. The call example is empty ({}), a minor missed opportunity given the parameter modes, but overall structure is organized and nearly all sentences earn their place.

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?

Complete for a high-risk, mult-mode tool: covers all three optional parameters, return values (closed/kept/total_before/remaining, backed by an output schema), side effects on user-visible windows, edge cases (false residue after force kill), irreversible risk, and environment constraints. Nothing an agent needs to call it correctly is missing.

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?

With 0% schema description coverage, the description carries the full burden and compensates thoroughly: it explains the three keep values and their intent, force's default false→graceful→force escalation, and project's instance filtering. It also documents parameter aliases (force←hard/kill, project←path/proj/..., keep←keep_one/...) that help agents map variant names correctly.

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 ('Close Keil uVision instances') and explicitly pairs with launch_uvision to form a Keil on-off closed loop, which distinguishes it from its primary sibling. The keep semantics (all/latest/oldest) and project filtering make the exact scope unmistakable.

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?

Explains when each keep mode should be used (converging accumulated same-project windows into one debug window) and when project-filtering applies. Names launch_uvision as the counterpart. It does not explicitly enumerate exclusions versus other siblings (e.g., restart_keil), but the pair relationship with launch_uvision gives sufficient routing context.

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