ILA GUI fallback: 打开调试器→扫链→检测核

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the operational workflow, the session-1 startup, popup handling, and prerequisites. It does not discuss timeouts, process leftovers, or success/failure semantics, but the GUI-launch behavior is well characterized.

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?

Four dense sentences, each earning its place: fallback status, alternatives/conditions, workflow steps, and prerequisite. No filler, and critical context is front-loaded.

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 the when, what, workflow, and prerequisites for a medium-complexity GUI tool. There is no output schema, and it does not describe return values or failure indications, but the title and workflow imply success is 'DebugCore detected/ready', which is enough for an agent to proceed.

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 the baseline is 3. The description adds a prerequisite emphasis on projectDir being a built FLA-containing directory, but the schema already states this and also documents host/user/pdsVersion meaning, so the description provides little extra parametric value beyond what structured fields already offer.

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 — launching and readying the Fabric Debugger via a concrete sequence (cdt_dbg → Search JTAG Chain → handle Open Cable popup → scan UIA tree for DebugCore) — and clearly labels itself as the GUI fallback, distinguishing it from the local default path. This makes the tool's function unmistakable even before reading the 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?

Explicitly names the preferred alternatives (fpga_jtag_flash → fpga_jtag_capture) and gives exact conditions for choosing this tool instead: when bare-metal capture lacks target support or remote interactive desktop is needed. This is textbook when-to-use guidance with no ambiguity.

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