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

Annotations declare readOnlyHint=false and destructiveHint=false, but the description never explains the behavioral implications: that la_capture actually starts hardware acquisition, whether it blocks until done, whether samples are retained for a later export, or that export operations write files to disk (filename param). For a non-read-only tool with zero added context, the description leaves the agent guessing.

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?

One short purpose sentence followed by two compact call examples – front-loaded and free of filler. It is slightly under-specified rather than bloated, so conciseness itself is not the problem.

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 should explain what each of the six operation values yields (preview vs. last vs. export_summary are entirely opaque, and exports have no stated destination or return). Only 'single' and 'export_vcd' are illustrated, leaving the agent unable to anticipate return shape or side effects for the rest.

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 100%, so the schema already documents every parameter, including the operation enum, sample_rate_hz, and sample_count. The examples reinforce that operation and rate/count are used together, but add no semantics the schema lacks, making the baseline 3 correct.

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 verb+resource pair ('Acquire digital traces') plus a second capability ('export capture data'), so the agent knows this tool captures and exports. It does not, however, distinguish itself from siblings like la_trigger or la_decode, which also operate on capture data, so the agent must infer the boundary.

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 two worked examples imply usage patterns (a hardware capture vs. an export), which is better than nothing. But there is no explicit when-to-use guidance, no statement about prerequisites (must la_trigger be armed first?), and no routing to or away from sibling tools.

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 declare readOnlyHint=false and destructiveHint=false, so the agent already knows this is a non-destructive mutation. The description adds nothing beyond that: it does not say whether configuration persists across captures, whether it resets prior settings, whether a device must be connected, or how operations interact.

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?

One short purpose sentence followed by two compact examples, front-loaded with zero filler. The examples earn their place by showing concrete argument shapes, though the example block could have covered all four operations at the same cost.

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 4-parameter config tool with full schema coverage and no output schema, the description is adequate but thin. It never explains the get operation's return use, the simulator_pattern workflow, or how the configuration operations relate to the capture/decode siblings.

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 100%, so the schema already documents pattern, channels, operation, and sample_rate_hz. The examples show call syntax for two operations, which is mildly useful, but the get and simulator_pattern operations and the required-ness of operation vs. its arguments are not explained beyond what the schema provides.

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 (Configure) and resource (logic analyzer channels and sample rate), so the agent knows what domain this tool owns. It does not explicitly contrast itself with siblings like la_capture or la_trigger, which is the only gap.

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 two examples demonstrate channel and sample-rate configuration, implicitly showing when to use those operations. However, two of the four enum operations (get, simulator_pattern) and the pattern parameter get no guidance, and there is no when-not-to-use or alternative-tool routing.

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 readOnlyHint=true annotation already establishes this as a non-destructive operation, and "decode captured traces" is consistent with that. The description adds only that decoders may be real sigrok decoders or simulator stubs; it says nothing about where results go, what 'run' versus 'last' changes behaviorally, or any resource constraints. Moderate added value against a low annotation bar.

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?

One purpose sentence followed by three compact, illustrative examples; the purpose is front-loaded and nothing is padded. The examples are terse enough that they earn their place rather than bloating the definition.

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 9-parameter tool with no output schema, the description covers the common decode paths but leaves three of six operation values ('run', 'last', and spi usage) and any description of returned output unexplained. Adequate for the main use cases, incomplete for the full operation surface.

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, but the examples genuinely add meaning by binding parameter sets to operations (rx for uart, sda/scl for i2c), which the flat schema does not convey. This is real value beyond the structured fields, though 'run', 'last', and spi channel wiring remain unexplained.

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 ('Decode captured digital traces') and names the mechanisms involved (sigrok decoders, simulator stubs), which is meaningfully more specific than a bare restatement of the name. It does not explicitly contrast itself with siblings like la_capture or la_configure, so an agent must infer the boundary from the names alone.

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 three examples imply usage patterns by showing operation="list" versus protocol-specific calls like "uart" with rx and "i2c" with sda/scl, which is useful implied guidance. However, there is no explicit when-to-use statement, no prerequisite (e.g., that a capture must precede decoding), and no mention of when to prefer this over the sibling tools.

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 declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a state-mutating but non-destructive tool. The description adds a return-format contract {"success", "operation", "data"}, which is useful, but it never explains what connect/disconnect actually change in session state or backend selection behavior.

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?

One-line purpose is front-loaded, and the return-format plus example block is compact and skimmable. Nothing is redundant enough to waste space, though the examples only re-demonstrate schema-known arguments.

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?

There is no output schema, so the short return-format contract is a valuable addition. However, the six-value operation enum (capabilities, backends, disconnect) is only demonstrated for three values, leaving the agent to guess at the remaining operations' behavior.

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 100%, so backend, device_id, and operation are already documented in the schema, including the device_id format example. The description merely echoes device_id in an example call, adding no meaning beyond the schema 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 opens with a specific verb set and resource ('Discover, connect, and manage USB logic analyzer devices'), which clearly separates it from capture/configure/decode/trigger siblings. It doesn't name a sibling explicitly, but the device-management scope is 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?

Usage is only implied through three example invocations (list, connect, status); there is no statement of when to prefer this tool over la_capture or la_configure, nor any prerequisites. An agent can infer the shape of calls but not the routing conditions.

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?

readOnlyHint=true is consistent with a help tool, so no contradiction, but the description adds nothing beyond the annotation – no mention of whether it hits hardware, whether it can be called before configuration, or what it returns. With annotations covering only the safety profile, the remaining behavioral burden is unmet.

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?

One short sentence with no waste, but it is under-specified rather than genuinely concise – the terseness comes from omitting useful content, and nothing is front-loaded because there is only one clause to front-load.

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?

This is a multi-operation dispatcher with an enum of six modes, one of which (tool_help) requires a companion parameter, and there is no output schema. The description should at minimum enumerate what each operation returns or when to use it; instead it says nothing operation-specific.

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 100% and each parameter is documented in the schema (topic as FAQ filter, operation as help operation, tool_name for tool_help). The description adds no meaning beyond that, so the baseline 3 is appropriate. It notably does not explain the interaction between operation and the optional 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 names the domain (logic-analyzer-mcp) and the category of work (help, discovery, hardware guidance), which distinguishes it from the operational siblings la_capture/la_configure/la_decode/la_device/la_trigger. However, it bundles six unrelated operations (discover, tool_help, status, quickstart, faq, hardware_guide) without saying what any of them does, so the purpose is only broadly clear.

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?

There is no guidance on when to call this tool versus any sibling, nor which operation to pick for a given need (e.g. 'use discover to list available devices' or 'use tool_help with tool_name to learn another tool'). The agent must infer everything from the enum values alone.

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 declare readOnlyHint=false and destructiveHint=false, and the description adds that a read-only "get" operation exists alongside "set" — mild added context beyond the coarse annotation. It does not say whether trigger settings persist across captures, what mode="off" does, or how set interacts with an in-progress capture.

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?

One short purpose sentence followed by two compact examples; nothing is padded. The examples earn their space by showing required parameter combos, though the header formatting is slightly heavier than the content warrants.

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?

There is no output schema, so the description should say what operation="get" returns, and it does not. It also omits how level relates to pattern (edge vs level triggering) and any persistence semantics, leaving real gaps for a 5-parameter hardware tool.

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 100%, so all five parameters are already documented in the schema, including enum values for mode and pattern. The examples show a realistic parameter combination (channel, pattern, mode), adding marginal practical value but no syntax or constraint detail beyond the 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?

States a specific verb and resource: "Configure digital trigger source and pattern." An agent immediately knows this manipulates logic-analyzer trigger settings. It does not, however, distinguish itself from siblings like la_configure or la_capture, so an agent must infer the boundary.

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 two worked examples implicitly show when to use set vs get, which is useful, but there is no explicit statement of when to prefer this tool over la_configure or la_capture. Usage is demonstrated rather than explained.

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