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

Annotations already indicate destructiveHint=true, but the description goes far beyond by detailing the exact destructive actions (Erase/Program/Verify), the fact that it can close/restart Keil, the return-code pitfall (always 0), the hang-prone commands, and the backup/restore behavior. This full disclosure significantly exceeds what annotations provide.

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?

Though long, the description is exceptionally well structured: core purpose upfront, then bullet-pointed pitfalls, then implementation details, then parameters and an example. Every sentence adds value – no fluff. The front-loading and use of headings/bullets make it easy to scan and grasp quickly.

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 high-risk, high-complexity tool with annotations and an output schema, the description is essentially complete. It covers purpose, usage, parameters, return values (artifacts, log_tail), risk warnings, and even handles edge cases like Unicode paths. An agent has everything needed to call it correctly and understand consequences.

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 coverage, the description carries the entire burden of parameter explanation. It explains commands (array or newline-separated), gives concrete command syntax examples, notes timeouts, mentions the optional project and visible parameters, and even describes the return artifacts. This fully compensates for the missing schema descriptions.

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 precisely identifies the tool as a UV4 command-line batch debug channel that runs a fixed init-file script. It clearly distinguishes this from the UVSOCK interactive channel by naming the alternative (enter_debug + keil_command) and stating when each is appropriate. This gives an agent a definitive understanding of what the tool does beyond its name.

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 explicitly states use cases (repeatable smoke/regression, fallback when UVSOCK unavailable) and explicitly tells agents to use UVSOCK for interactive troubleshooting. It also warns about hangs and slower execution, providing concrete operational guidance and criteria for choosing this tool.

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

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds meaningful behavioral caveats beyond that: the target must be paused, a running target cannot be evaluated, and a value read immediately after hitting a breakpoint may be stale or dirty (e.g., PC=1), with advice to retry. This is valuable extra context an agent needs to interpret results correctly.

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 front-loaded with the core behavior and examples, followed by necessary caveats and then the parameter contract. Every section earns its place, including the alias list, which prevents agents from passing legacy parameter names. There is no filler or tautology.

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 single-parameter, read-only tool with an output schema present, the description covers invocation syntax, example inputs, prerequisites, timing caveats, and the parameter contract. An agent has enough information to select and call this tool correctly without needing the output schema content.

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?

The input schema exposes only a bare required string 'expr' with no description, so the description carries the full burden. It clearly explains what expr can contain (variable name, register, pointer dereference), provides multiple concrete examples, lists accepted aliases, and warns that unlisted parameter names are rejected rather than silently ignored.

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 opens with '计算并读取调试器中的一个表达式' and gives concrete expression forms such as 'SData_UA', 'timer.sec', and '*(uint32_t*)0x20000000', making the resource and verb clear. It does not explicitly contrast itself with siblings like read_variable or read_mem, so some differentiation is left implicit.

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 provides clear operational context: debug must be active, the target must be paused, evaluation is impossible while running, and values may be dirty immediately after a run-to-breakpoint with retry guidance. It does not name alternatives or explicitly state when to choose this tool over read_variable or read_mem, so full routing guidance is missing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and the description is fully consistent with them (no contradiction). Beyond that, it adds rich behavioral context the annotations cannot express: the output payload can be large with an output-control mechanism, truncated/dropped/trimmed content is always reported in the output field (never silently discarded), env vars MDKDEBUG_COMPACT/MDKDEBUG_MAX_LINES affect defaults, and channel availability depends on Keil runtime and UVSOCK state.

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 in the first sentence ('冷启动第一步的能力自检'), and every subsequent block — four return sections, keil_health differentiation, output-control rules, parameter summary — earns its place. The output-control paragraph is long, but justified given this tool returns large payloads and obeys environment variables. Minor redundancy exists between the description body and the input-schema parameter texts.

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?

Given the tool's complexity — an output schema documenting return values, complete annotations covering safety/idempotence, and three optional parameters — the description is complete. An agent has everything needed to call it correctly: what it returns (4 sections), when to call it (cold-start first), how sizing controls behave and interplay with env vars, and the guarantee of no silent data truncation. The presence of an output schema relieves the description of explaining return-value shapes.

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%, so each of the three parameters (full, compact, max_lines) is already documented in the schema, giving a baseline of 3. The description adds real value beyond the schema by explaining how the params interact with each other and with the environment variables (defaults, precedence, 'default not passed = unchanged behavior'), and by clarifying that dropped content is reported rather than silently lost. It slightly exceeds the baseline but the schema still carries the core burden.

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 specific verb-plus-resource pair: '能力自检' (capability self-check) enumerated across four concrete return sections (channels, modules, env, tool_surface). It explicitly differentiates itself from the sibling keil_health ('keil_health 做诊断, capabilities 做枚举'), so an agent can distinguish it without opening either 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?

The description is explicit about when to invoke it: '冷启动第一步' (first step on cold-start) before trying features the agent might not have. It names the alternative keil_health and gives the exact selection criterion (diagnosis vs enumeration), and even advises which of the two debug channels to use per scenario (uvsock needs Keil running with UVSOCK open vs uv4_cmdline which does not depend on UVSOCK).

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

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

Annotations already mark destructiveHint=true and idempotentHint=true, but the description adds substantial beyond-annotation context: the exact mechanism (sending BK by address), the irreversible risk of rewriting Flash/memory or closing/restarting Keil, the FPB residue check with error_code=breakpoint-residue, and the requirement that Keil be closed for .uvoptx cleanup. No contradiction with annotations.

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 long but front-loaded: core behavior first, then conditions, risk, parameter details, and aliases. Each section earns its place, and the structured headers make the dense information navigable for an agent.

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 destructive tool with two optional booleans and a complex hardware/Keil interaction, the description covers prerequisites, failure modes, irreversible side effects, and parameter aliases. An output schema exists, so not detailing return values is acceptable; nothing critical 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?

Schema coverage is 0%, so the description carries the full burden, and it delivers: it documents include_uvoptx as clearing Keil-persisted .uvoptx breakpoints, hard as enabling FPB verification after BK *, lists aliases, and warns that unlisted parameter names are rejected. This fully compensates for the silent schema.

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 specific verb and resource: '清除软件断点：清空本服务内部记录并逐个按确切地址发 BK', and distinguishes this all-breakpoints operation from sibling clear_breakpoint by the word '全部'. It also adds the optional .uvoptx cleanup target, making the tool's scope unambiguous.

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 gives concrete conditions: include_uvoptx=True clears Keil-persisted breakpoints, clean .uvoptx requires Keil closed, and hard=True performs FPB verification after BK *. It also explains when reflashing is or is not needed. It does not explicitly name alternatives or when-not-to-use cases, so it falls just short of a 5.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses critical behavioral details: the clearing happens via the BK command, data watchpoints cannot be cleared by address due to a Keil error, the tool automatically converts address/symbol to a Keil number with a fallback, unknown bp_id values trigger automatic fallback, and clearing triggers async messages. This is substantial transparency with no contradiction to annotations.

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 long but densely packed with necessary edge-case knowledge. The first sentence front-loads the purpose, and the structure separates usage, risk, and aliases. The empty call example '{}' is a small waste, and the risk section partly echoes annotation information, but overall each segment earns its 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?

The description covers all critical context: required debug state, all parameter modes, the watchpoint-clearing bug, automatic fallbacks, asynchronous message behavior, and a risk rating. Given that an output schema exists, no return-value description is needed, and there are no obvious gaps that would prevent an agent from invoking the tool correctly.

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?

Since schema description coverage is 0%, the description carries the full burden, and it delivers: it defines each parameter (expr for symbol/address, bp_id for internal service id, keil_number for Keil's actual breakpoint number), explains the fallback semantics, and documents parameter aliases while noting that unspecified names are rejected. This completely compensates for the bare schema.

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 clearly states the tool's verb and resource: '清除断点' (clear breakpoint), and goes further by explaining the three ways to specify which breakpoint to clear. It distinguishes itself from the sibling clear_all_breakpoints by framing this as a targeted clear operation and explicitly advising against using clear_all_* for a single breakpoint.

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 gives explicit usage guidance: three selection modes (expr, bp_id, keil_number), the prerequisite that debug must be entered, and a warning about async messages before issuing run/step. It also names the alternative clear_all_breakpoints and explains when not to use it (for a single breakpoint), making the choice between tools unambiguous.

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

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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond that: it aggregates multiple read-only diagnostics, is subject to interrupt context limitations (locals/call stack may be empty), and never silently drops data (truncation is reported in output). It also discloses that unrecognized parameter names are rejected, not ignored. No contradiction with annotations.

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 lengthy but well-structured with clear sections (purpose, limitations, output control, parameters, aliases). It front-loads the core purpose and includes necessary operational details without redundancy. Every sentence adds value, though the length is justified by the tool's complexity.

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?

Given the tool's complexity (6 optional parameters, output schema exists), the description covers purpose, prerequisites, limitations, output control behavior, and parameter aliases. The only gap is the unstated meaning of disasm_count and source_context, which are minor and inferable from context. The output schema handles return structure, so the description is largely complete for an agent to call it correctly.

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 only 50% (descriptions exist for full, compact, max_lines but not for globals, disasm_count, source_context). The description compensates partially: it explains globals (array or comma/semicolon string) and the output-control trio (compact/max_lines/full) in detail, but does not explain the semantics of disasm_count or source_context beyond their names and defaults. This is a moderate compensation, but not complete for all parameters.

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 clearly states the tool aggregates all on-site diagnostic information (registers, disassembly, source context, call stack, locals, globals) into a structured report. It explicitly names the alternatives it replaces (get_current_location/read_registers/disassemble/read_locals) and distinguishes itself as a one-call diagnostic aggregator, making its purpose unambiguous.

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 explains when to use this tool: when an AI receives a bug report and needs a comprehensive snapshot in one call, avoiding multiple round trips. It also notes prerequisites (debug entered, .axf configured) and limitations (interrupt context may restrict locals/call stack). It doesn't explicitly say when NOT to use it, but the context and alternatives are clear enough for an agent to make a decision.

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

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

Even with annotations covering idempotency and non-destructiveness, the description adds meaningful behavioral detail: it extracts dialog text, auto-selects buttons by semantic order, falls back to WM_CLOSE, and returns button_not_found rather than silently clicking a different button. It also warns that dismissing the dialog does not fix the underlying problem, which is important context.

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 dense but efficiently structured: the core behavior is front-loaded, parameters are explained inline, the return shape is included, and the warnings are compact. No sentence is redundant with the schema or annotations.

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 tool with three optional parameters and an output schema, the description covers the triggering condition, parameter semantics, return fields, fallback behavior, and operational caveats. An agent has everything needed to invoke it correctly in the blocking-dialog scenario.

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 0%, but the description fully compensates: button supports partial matching and auto-selection, title filters when multiple dialogs exist, and index selects which dialog to target. Every parameter is explained with behavior beyond its bare name and default value.

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 specific action: enumerate UV4 modal dialogs, read their Static text and Button labels, and click a button to dismiss the blocking dialog. It clearly differentiates the tool from siblings like keil_command or restart_keil by targeting the modal-blocking scenario specifically.

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 is explicit about when to use it: when a command does not return and keil_health reports modal_blocked_suspected=true. It also prescribes a workflow—read dialog.message first, choose a button, dismiss, then retry the original command—and explains the fallback behavior when no button matches.

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

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

Beyond annotations (readOnlyHint=false, idempotentHint=true), the description discloses extensive behavioral details: async entry timing (~0.6-0.7s), automatic polling and ready status, watchdog freezing with fallback warning, and optional flash download side effects. It also warns about potential pitfalls like old symbol loading and suggests the flash_debug closed loop. This far exceeds what annotations provide.

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 well-structured with sections and bold warnings, but it has notable redundancy: the sentence '受工程 Load/Flash Download/Run-to-main 设置影响，属于有副作用的操作' (or similar) appears twice, and the side-effect statement is repeated. While the detail is valuable, not every sentence earns its place, and the text could be tightened by ~15-20% without losing 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?

Given the tool's complexity (side effects, async behavior, watchdog interactions, failure modes), the description is remarkably complete. It covers return fields (ok, already_in_debug, ready, ready_waited_ms, watchdog_freeze), error conditions (status=6, timeout warnings), and recovery steps. Nothing essential is missing for correct invocation and interpretation.

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 schema coverage at 0% and only one parameter (freeze_watchdogs), the description fully compensates by explaining its purpose (freeze watchdog bits to prevent resets), the default behavior (auto-enable), and the failure handling (warning + manual call suggestion). This adds significant value beyond the bare Boolean type.

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 clearly states the action: automatically enters Keil debug mode (UV_DBG_ENTER). It distinguishes itself from siblings like exit_debug and flash_debug by explaining the entry mechanism and the alternative closed-loop workflow. The purpose is unambiguous and specific.

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 provides explicit usage guidance: when to use (e.g., after compilation with UpdateFlashBeforeDebugging=1), when to avoid (if old firmware might be present, recommending flash_debug instead), and prerequisites (UVSOCK enabled). It also notes idempotent behavior when already in debug, saving an exit/enter cycle.

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

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

It discloses important behavioral traits beyond the annotations: it reports 'unknown' when IDCODE cannot be read (not faking results), explains the guard field (active=false means no chip model verification), and warns that 'no error' does not guarantee correctness. It also clarifies that the tool is lazy-connected and won't alter debug state, complementing the readOnlyHint and idempotentHint annotations.

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 long but well-structured, front-loading the core purpose, then detailing outputs, caveats, and finally parameters. It uses paragraphs and bullet points effectively, though it could be more concise while retaining the critical edge-case 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?

For a complex tool with detailed output fields and edge-case behaviors, the description is largely complete: it explains the output structure, safety, and failure modes. However, the lack of parameter explanations creates a gap for advanced usage, though the default call (empty object) is sufficient for the primary use case.

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?

The description lists the optional parameters (project, link, content_check) but does not explain their purpose or effects. With schema description coverage at 0%, the agent receives no guidance on what these parameters control, making it hard to use them effectively beyond the default empty call.

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 explicitly states the tool checks consistency between the expected target (from project/tools) and the actual target on the board, listing specific problem types (e.g., symbol/firmware mismatch, wrong SVD chip selection) and detailed output fields. It clearly distinguishes itself from sibling diagnostic tools like get_version or keil_command by serving a unique consistency-checking role.

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 provides clear usage context (cross-repo/cross-board debugging, run first before debugging) and notes the lazy connection that safely avoids entering debug/stop/download. However, it does not explicitly mention when not to use it or compare it directly to alternative tools, leaving some inference to the agent.

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

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

Beyond the annotations, the description discloses important behavioral details: rejection while the target is running, automatic release of the host COM port, retained logs, serial_read remaining readable, and the WinError=5 failure mode. It also labels the risk level, which is genuinely useful context.

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 longer than minimal but every sentence carries operational value: precondition, error behavior, side effect, recovery, and risk. The section markers also make it scannable, though it could be tightened slightly.

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 no-argument state-changing tool with an output schema, this description is complete: it covers when to call it, what to do first, what side effects occur, how to recover, and the risk profile. Nothing material needed for correct invocation 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?

The tool has zero parameters and the schema documents this completely. The description reinforces it with '无（直接调用）' and an empty call example, which is sufficient for the no-parameter baseline.

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 names a specific action and resource: 'automatically exit Keil debug mode (UV_DBG_EXIT)'. It also clearly distinguishes this from sibling operations like enter_debug, run, and stop by describing the exit transition and its side effects.

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 gives clear usage context: stop the target first if it is running, otherwise exit is rejected with status=11. It also instructs the agent that serial_monitor_start() can be restarted if continued collection is needed, but it does not explicitly name alternative tools or state when not to use exit_debug.

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

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

The description adds substantial behavioral context beyond the readOnly/idempotent annotations: the UVSOCK r_status is always 0 and the real state is in the data low byte, symbol staleness semantics including status 13 errors, and serialization/concurrency telemetry about competing mdkdebug processes. These are non-obvious behaviors that an agent needs to interpret results correctly.

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 longer than minimal but well-structured and front-loaded with the core purpose before diving into field-level detail. Every sentence adds useful information, including the UVSOCK quirk and memory-safety caveat, so the length is justified.

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 zero-parameter tool with an output schema and strong annotations, the description covers all essential aspects: what is returned, what the returned fields mean, the notable UVSOCK parsing quirk, and when it is safe to act on the result. Nothing critical 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?

The tool has zero parameters and the schema coverage is 100%. The description explicitly confirms there are no parameters and provides a direct call example, which is sufficient; baseline 4 applies because there are no parameter semantics to elaborate.

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 clearly identifies the verb '查询' and the resource: current debug status, including session state, target running state, and UVSOCK status. It also specifies what the tool is useful for ('判断可否安全读写内存'), but it does not explicitly distinguish itself from siblings like session_state or target_info, so it stops short of full differentiation.

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 gives clear usage context: it can be used to determine whether it is safe to read/write memory, and it warns that when the target is running, querying status is allowed but safe memory reads are not. It does not explicitly name alternative tools or state when not to use this one, so it earns a 4 rather than a 5.

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

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

Annotations already declare readOnly and idempotent behavior. The description adds meaningful behavioral context beyond that: the prerequisite of Keil/UVSOCK being active, and the failure mode where the tool returns enabling instructions instead of a version string.

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 compact and front-loaded: purpose and return type first, followed by a necessary prerequisite note, then a structured parameter section. No redundant wording.

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 zero-parameter read-only tool with an output schema, the description provides everything needed: what it returns, when it can succeed, and what happens on failure. The empty call example reinforces the no-argument contract.

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?

There are no parameters, and the schema covers 100% by being empty. The description explicitly states '无参数（直接调用）', which adds clarity beyond the empty schema and matches the baseline for a zero-parameter tool.

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 specific verb ('查询') and resource ('Keil UVSOCK 插件的版本信息'), and adds the return format ('十六进制版本串'). This clearly differentiates it from sibling status/capability/session tools without requiring schema inspection.

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 gives explicit operating context: Keil must be running and UVSOCK enabled, otherwise the call fails and returns setup guidance. It does not enumerate alternatives, but the usage context is clear and sufficient for this simple no-parameter tool.

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

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

Annotations already say readOnlyHint=false and destructiveHint=false, and the description goes well beyond them: it discloses that UVSOCK status is unreliable, that errors must be read from ok/errors fields, that newlines/repeated commands are rejected, and that commands like BK *, RESET, and G change target state. There is no direct contradiction with annotations, though idempotentHint=true is optimistic for arbitrary commands like G.

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?

Long but information-dense: core behavior is front-loaded, followed by a compact command cheat-sheet, three real-device pitfalls, return shape, risk note, and parameters. Each section earns its place and the formatting makes scanning easy.

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?

Given a low parameter count, no enums, and an existing output schema, the description covers invocation, return values, error semantics, risk, and alternatives. Nothing an agent needs to decide whether to call it and how to interpret the result 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 needed to compensate. It richly documents the command parameter with examples and valid syntax, but settle_ms and explain_errors are only listed as optional, with semantics left to inference from their names and defaults. This is acceptable for optional tuning parameters but not fully explicit.

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?

Description states exact mechanism: send one raw command verbatim to Keil command window via UVSOCK EXEC_CMD and return output/errors. It also frames itself as a catch-all fallback when dedicated tools do not cover the operation, which clearly distinguishes it from specialized siblings.

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?

Explicitly says to use this tool when dedicated tools do not cover the operation, warns that only one command at a time is accepted, and routes multi-step workflows to batch or batch_debug_script. It also lists high-risk commands, advising caution.

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

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

Annotations already mark it read-only/idempotent/non-destructive, and the description adds meaningful operational facts: it is a pure ctypes+socket probe, safe even when Keil is absent, and it surfaces concurrency hazards from multiple mdkdebug instances that silently eat writes. It also details modal dialog output content, going well beyond annotation hints.

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 long but front-loaded with the main check purpose and then layers return fields, failure modes, and usage guidance. Each section adds non-redundant operational value, with an explicit parameter note and example at the end.

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 no-parameter health probe with annotations and an output schema, the description covers the diagnostic fields (including mdkdebug_instances contention data and modal_dialogs), the precise failure modes, and when to invoke it. There is no missing information an agent would need to select and call it correctly.

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?

The tool has zero parameters and the schema is empty; the description explicitly states 【参数】无（直接调用） and shows an empty call example. This removes any doubt that invocation requires no arguments, so the description is fully sufficient.

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 opens with a specific verb and resource ('检查 Keil 调试通道的健康状态') and enumerates exactly what is probed: UV4 process, UVSOCK port, and modal dialog blocking. It distinguishes itself from generic siblings by defining its scope as health/diagnosis of the debug channel rather than command execution or environment setup.

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?

It gives explicit trigger conditions: call first when a command times out or appears unresponsive, and use as a cheap pre/post-operation self-check. It also clarifies that it remains useful even when Keil is not running, but it does not name exclusions or alternative sibling tools, so a 4 rather than 5.

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

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

Goes well beyond annotations: discloses that UV4.exe is not single-instance, repeated calls accumulate windows (observed up to 6), explains default reuse behavior, single-mode rejection logic with error_code and return fields (reuse_forced, instances), and the medium risk of changing target state or occupying shared resources. Annotations only provide flags; this gives concrete side effects and safeguards.

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?

Though long, every sentence adds critical detail: purpose is front-loaded, then parameter semantics, return values, alternatives, risk, and aliases. Bold and structured formatting aid scannability. The empty call example is harmless and not 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 tool with 5 optional parameters, no required params, no schema descriptions, and non-trivial multi-instance behavior, the description covers all parameter semantics, defaults, return values (reused/pid/instances), error behavior, risk, and prerequisite caveats (uvsock port alignment). It is self-sufficient for an agent to select and invoke correctly.

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 0%, so description fully compensates: each parameter (project, reuse, single, uvsock_port, no_layout) is explained with its default, purpose, and concrete effect (uvsock_port adds `-s <port>`, no_layout adds `-sg`). Also documents parameter aliases and that unlisted parameter names are rejected.

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?

Description states a specific action ('launch Keil uVision and open project visibly for manual UI viewing/debug preparation'), names the resource (.uvprojx project), and distinguishes itself from siblings like list_uvision_instances and close_uvision which are for inspecting and closing windows, not launching.

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?

Provides explicit when-to-use guidance: 'AI can launch via this tool', and routes to alternatives: 'to see how many windows are open use list_uvision_instances, to clean up excess use close_uvision(keep="latest")'. Also details precise conditions for reuse=false, single=false, uvsock_port, and no_layout.

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

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

Annotations already mark the operation read-only, idempotent, and non-destructive, and the description adds substantial behavioral context beyond that: it warns that CNT is not a hit counter, that unavailable FPB reads must not be treated as clean, that orphaned hardware breakpoints can persist after BK *, and that truncated output is always reported rather than silently dropped.

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 content is well organized into numbered sections and front-loaded with the main return structure, but it is quite long and includes tangential notes (e.g., how clear_breakpoint must use Keil numbers) and an internal inconsistency ('返回两部分' followed by three parts). Every sentence is informative, yet the description would benefit from tightening.

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 complex read-only inspection tool, the description covers the internal, Keil, hardware, and persistence views, explains output-control behavior and truncation honesty, and supplies caveats needed to interpret results correctly. With an output schema present and annotations covering safety, no essential calling or interpretation information 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?

Schema coverage is 100%, and each optional parameter already has a rich description explaining its effect and interaction with environment variables. The description repeats some of this in the output-control section, but per the rubric the schema does the heavy lifting, so no more than the baseline 3 is warranted.

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 opens with a clear verb+resource statement ('列出断点') and enumerates the distinct result sections (internal records, Keil real table, and hardware FPB state), so an agent knows exactly what this tool returns. It separates this from set/clear breakpoint tools by focusing on inspection and even calls out Keil-vs-hardware domains.

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 intended use as the read-only inspection counterpart to set_breakpoint/clear_breakpoint is implied rather than stated; there is no explicit when-to-use or when-not-to-use guidance versus siblings. The rich interpretation guidance (real vs hardware vs uvoptx) helps an agent understand results, but not when to choose this tool over an alternative.

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