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

With no annotations provided, the description carries the full disclosure burden. It does convey that this is a creation operation and that jobs are additive (multiple can coexist per waveform), which is a genuine behavioral fact. It omits error behavior for a missing open capture, idempotency, sync/async execution, and permission requirements, making disclosure partial.

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?

Two short sentences with no filler; the core action is front-loaded and the second sentence adds a non-obvious behavioral fact about multiple jobs. Every word 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?

For a tool with 6 parameters, nested objects (channel_map, options), and zero schema documentation, this description is too thin. The output schema covers return values, but an agent cannot reliably construct a valid channel_map or interpret time bounds without external probing, sibling calls, or trial.

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 0%, so the description must compensate, but it mentions no parameter details. The SPI/I2C example only weakly hints that protocol is a bus-protocol identifier; channel_map structure and values, t_min/t_max semantics, options, and job_id are entirely 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?

States a clear verb and resource: 'Create a DecodeJob on the open capture.' The SPI/I2C example clarifies it's a per-protocol decode action. It doesn't explicitly name or contrast siblings like protocol_list or interpret, so the boundary is inferred rather than stated.

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?

'On the open capture' implies the prerequisite that a capture must already be open, and 'Same waveform can have several jobs' signals that repeated calls are expected for stacking decodes. However, no alternatives, exclusions, or when-not-to-use conditions are given, leaving that decision to inference.

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?

With no annotations, the description must carry behavior disclosure. It communicates the load operation and returned capture_id/channels, but it does not mention side effects, supported file formats, error behavior, or whether loading replaces an existing capture. This is partial but not comprehensive transparency.

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 three short sentences and every sentence adds value: what it loads, what it returns, and where pin maps belong. There is no redundant filler or repetition of schema details.

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?

An output schema exists, so return values do not need full restatement. Still, given no annotations and zero parameter documentation, the description leaves format_id semantics and possible stateful effects unexplained. It is adequate for a simple call with just path, but not fully complete.

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 0%, so the description must explain the parameters. It weakly implies that path is a file path, but it does not clarify format_id at all, including when it should be provided or what formats it accepts. The optional parameter remains ambiguous.

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 clear verb and resource: 'Load a capture/trace file.' It also names the return values and explicitly routes pin-map work to bus_decode, which distinguishes it from the sibling tool of the same domain.

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 makes the loading use case clear and gives an explicit exclusion by stating 'Pin maps belong on bus_decode.' It does not explicitly contrast with instrument_capture, but the sibling names and 'Load a capture/trace file' make the intended context evident.

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?

No annotations are provided, so the description carries the full burden of disclosing side effects, read-only status, or state changes. It only restates the operation and does not say whether the tool reads a previous capture, produces artifacts, modifies state, or how it handles invalid DCS data.

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 a single compact sentence with no padding, and the core verb and resource appear early. The unexplained 'Sugar:' prefix is a minor structural blemish, but the overall text is appropriately sparse.

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 complex tool with seven optional parameters, no annotations, no schema descriptions, and several close siblings. The description is far too incomplete: it does not clarify what inputs are needed, what output is produced, or how display_analyze differs from display_reconstruct and interpret.

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 across seven parameters, the description needed to explain width, height, offsets, max_commands, and decode_job_id. It only gestures at 'display profile' and 'command_log sink', leaving the meaning and relationship of the numerical parameters mostly 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 names a specific verb (interpret), a resource (MIPI DCS + command_log sink), and a target (display profile), so it is not a tautology. However, it does not distinguish itself from sibling tools like 'interpret' or 'display_reconstruct', both of which could plausibly handle display data.

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 about when to use this tool versus alternatives such as interpret, display_reconstruct, or bus_decode. The 'Sugar:' prefix may imply a convenience wrapper, but the description never states the conditions that should lead an agent to pick this tool over its siblings.

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?

No annotations are provided, so the description must disclose behavior itself, but it only says 'interpret' without explaining side effects, safety, output format, or processing behavior. It gives a vague sense of reading/decoding data sources but does not tell the agent what will happen when the tool is invoked.

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 short, but it is cryptic rather than clear, and the leading 'Sugar:' token wastes the front-loaded position. A one-line description can be excellent, but this one sacrifices useful structure and meaning for brevity.

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 10 parameters, no parameter descriptions, and no annotations, this description is severely incomplete. The output schema exists, but the agent still lacks enough context to know what input data is expected, what the tool does, or how to choose parameters 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 description coverage is 0%, and the description adds no meaning for any of the 10 parameters. Parameters like width, height, profile, offsets, and max_commands are left entirely unexplained by both schema and description, so an agent cannot know how to set them.

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 verb ('interpret') and resources ('MIPI DCS + command_log + framebuffer sinks'), so it is not a pure tautology. However, the 'Sugar:' prefix is cryptic and the description never states that the tool reconstructs display frames or what output it produces, making it hard to separate from the sibling 'interpret'.

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 about when to use this tool versus alternatives like 'interpret', 'display_analyze', or 'bus_decode'. The description only implies some kind of decoding/interpretation role, but no conditions, prerequisites, or exclusions are given.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only lists the information returned and does not state that the tool is a read-only query with no side effects, nor does it mention any requirements like an open instrument. An agent cannot infer safety or mutation behavior from this description alone.

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 a single, front-loaded sentence with no wasted words. It states the key content immediately and is appropriately concise for a tool with no parameters.

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 tool has an output schema (not shown but indicated) and the description covers the content of the response. However, it does not mention what happens if no instrument is open or whether the operation fails under certain conditions. For a simple zero-parameter query, this is nearly complete but leaves a small gap.

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 an empty object with 100% coverage, so there is nothing to explain. The description adds value by specifying what the returned data covers (sample rates, channels, trigger), but parameter semantics are trivially satisfied. Baseline for 0 params is 4.

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 what the tool does: it provides sample rates, channel names, and trigger support for the open instrument. It specifies a distinct resource ('the open instrument') and the kind of information returned, which differentiates it from siblings like instrument_list (which lists instruments) or instrument_scan (which scans for instruments).

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 implies the tool is used after opening an instrument ('for the open instrument'), but it does not explicitly state when to use it vs. alternatives, nor does it mention any exclusions or prerequisites. It lacks guidance on when not to use it (e.g., when no instrument is open) or which sibling to use instead for other needs.

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?

No annotations exist, so the description must carry behavioral transparency. It does communicate that the capture is blocking and writes into the session, and it notes a backend-specific exception for sample_rate_hz. However, it does not disclose effects on existing session state, required instrument state, or timeout/failure behavior, leaving significant behavioral uncertainty.

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 economically worded and front-loaded with the primary action. No filler exists, and the dsview note is relevant. However, for a 9-parameter tool this brevity crosses from concise to underspecified.

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 9 parameters, no annotations, and 0% schema coverage, the description is insufficient; it does not outline the capture workflow, prerequisites, or how parameters combine. It mentions blocking and session but not how the result is stored or returned. The output schema exists but does not cover this workflow context.

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% while there are 9 parameters; the description only adds semantic value for sample_rate_hz via the dsview note. Other parameters like extra are completely unexplained, and the description does not clarify how duration_s, timeout_s, and sample_count interact. Param names are self-descriptive but this does not compensate for the low coverage.

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 uses a specific verb ('Run') and object ('blocking capture') and states the destination ('session'), making the tool's core function clear. It does not explicitly name sibling tools, but the blocking qualifier and session target help disambiguate from instrument_start or instrument_wait. It lacks direct sibling differentiation, so not a 5.

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?

No explicit when-to-use or when-not-to-use guidance is provided. It does not mention that the instrument must be opened or configured first, nor when one would prefer instrument_start/instrument_wait over this single blocking call. The only usage-adjacent note concerns sample_rate_hz for dsview, which is a parameter constraint, not tool-selection guidance.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It usefully states that the last LogicCapture is not deleted, which sets expectations about non-destructiveness, but it does not describe other side effects, state changes, or error conditions related to closing an instrument.

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 two sentences with no wasted words. It leads with the core action and immediately adds the most important caveat, making it easy to parse and act on.

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 present, the description is largely sufficient. The main gap is the lack of usage context relative to sibling tools, but the operation is simple and the non-deletion caveat covers the key behavioral risk.

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, so parameter semantics are not a concern. The description correctly adds no parameter information because none exists, and the empty input schema is self-explanatory.

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 clear action on a specific resource: 'Release the open instrument.' It is distinct from sibling open/stop tools through the word 'release' and the caveat about not deleting LogicCapture, though it does not explicitly name a sibling for contrast.

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 alternatives like instrument_stop or instrument_open. The phrase 'Release the open instrument' implies closure after use, but no explicit conditions, prerequisites, or exclusions are provided.

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?

There are no annotations, so the description carries the full behavioral burden. It does disclose the key side effect (mutating capture configuration) and explicitly clarifies that it does not start capture, which is important. However, it does not mention prerequisites like an open instrument, whether previous settings are overwritten, or how configuration interacts with a running 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?

The description is a single efficient sentence plus a short behavioral caveat. Every phrase contributes information, and the primary verb and resource are front-loaded. There is no repetition of the title or filler content.

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 8 parameters, no annotations, and zero schema description coverage, the description carries heavy weight. It provides the core semantic model and an important non-start clarification, but it omits lifecycle preconditions, the meaning of timeout_s and extra, and the relationship to instrument_start/capture. It is adequate for basic selection but not fully complete for every invocation workflow.

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 0%, so the description must add parameter meaning on its own. It successfully maps semantic families to the schema: rate→sample_rate_hz, channels, duration/samples→duration_s/sample_count, and trigger→trigger_edge/trigger_channel. It stops short of explaining timeout_s and extra, and units or mutual exclusivity are left to inference, but the main parameters are clarified well.

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 uses a specific verb ('Set') with a concrete resource ('live capture params') and enumerates the exact field families: rate, channels, duration or samples, trigger. It actively distinguishes itself from capture/start tools by adding 'Does not start yet.' This makes its purpose unmistakable and separates it from siblings like instrument_start and instrument_capture.

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 implies it should be used for configuring before starting a capture, and explicitly warns that it does not start anything. However, it does not state when to call it relative to instrument_open, instrument_capture, or instrument_start, nor does it name alternatives. The usage context is implied by the sibling set rather than clearly defined.

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?

With no annotations, the description carries the full burden of disclosing behavior. It mentions 'ask the vendor hub' and 'load it into the session,' but does not explain side effects, session mutation semantics, data flow, error behavior, or whether this is a safe read-like operation.

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 a single concise sentence with no filler and leads with the core action. However, the brevity comes at the cost of crucial detail, preventing a higher score.

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?

Three parameters are present but entirely undocumented, usage guidance is absent, and behavioral details are minimal. Even though an output schema exists, the description does not provide enough surrounding context for an agent to invoke 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?

Schema description coverage is 0%, and the description does not explain any of the three parameters: path, format, or out_dir. The agent receives no information about what values are valid or what each parameter controls.

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 provides a specific verb ('export') and a clear resource ('the last capture'), and adds what happens afterward ('load it into the session'). This distinguishes it from siblings like instrument_capture, though it does not explicitly name or contrast with alternatives.

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 explicit guidance on when to use this tool versus alternatives. The phrase 'last capture' implies it should be used after a capture exists, but no exclusions, prerequisites, or comparisons to sibling tools such as instrument_capture or capture_open are provided.

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?

With no annotations, the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, and the description names the output fields, but it provides no additional behavioral context such as whether the list is dynamically scanned, cached, or requires an active session. It is not misleading, but it is minimal.

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 a single sentence that front-loads the action and resource, then lists the exact fields returned. Every word is useful, and there is no fluff or repetition.

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 listing tool with an output schema, the description is sufficiently complete. The output schema covers the return structure, and the description names the key fields. No additional information is needed for an agent to invoke 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 input schema has zero parameters, so the description does not need to explain parameter behavior. The baseline for a no-parameter tool is 4, and there is nothing further to document.

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 uses a specific verb 'List' and a specific resource 'live-capture backends', and enumerates the fields returned (id, vendor, status, available, options_schema). This clearly states what the tool does, though it does not explicitly differentiate it from sibling tools like instrument_scan.

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 use this tool versus alternatives such as instrument_scan or capture_open. The usage is only implied by the word 'list', but no context or exclusions are provided to help an agent choose this tool correctly.

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?

No annotations are provided, so the description carries the full burden. It discloses that this opens a backend and returns device plus capabilities, but it does not mention that opening may create a persistent stateful resource, whether it replaces an existing session, or that it should be paired with instrument_close. For an open operation, this is a significant gap.

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?

A single sentence that front-loads the action, includes useful examples, and states the return value. Every part is relevant and there is no filler.

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 output schema covers return values, and the command is invocable with the required backend parameter thanks to the examples. Still, with zero schema coverage on extra and device_id and no lifecycle guidance, the description is only minimally complete for an agent that needs to use the full parameter set.

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 0%, and the description only compensates for the backend parameter by listing examples. It provides no meaning for extra or device_id, such as how device_id selects a device or what extra can configure, so two of three parameters remain effectively undocumented.

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 uses a specific verb ('Open') and resource ('live backend'), gives concrete backend examples (mock, dslogic, sigrok_cli), and states the return value ('device + capabilities'). This clearly distinguishes it from sibling tools like instrument_scan or instrument_capabilities.

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 context for the operation, so an agent can infer it is for opening a live backend. However, it does not explicitly name alternatives or state when not to use this tool, leaving the agent to figure out the boundary against siblings like instrument_list and instrument_scan.

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?

No annotations are provided, so the description must carry the behavioral burden. It only says 'Discover' and explains the omitted-backend default; it does not disclose side effects, connection requirements, runtime cost, or failure modes. This is sparse transparency for a tool that may scan multiple backends.

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?

Two short sentences, no filler, and the key default behavior is front-loaded. Every phrase contributes useful meaning.

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 one optional parameter and an output schema, this is close to minimally adequate: the agent knows the basic purpose and the default invocation. Still, it lacks backend value guidance and explicit context for choosing this tool over its many sibling tools.

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 0%, so the prose must clarify the backend parameter. It explains the omission behavior, but it does not state what valid backend values look like, what formats are accepted, or what happens when a specific backend is supplied.

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 'Discover analyzers,' a specific verb and resource, so an agent understands the core action without needing to infer it from the tool name. It does not explicitly differentiate this from sibling tools such as instrument_list or protocol_list, but the focus on analyzers and available backends is reasonably distinct.

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 a useful conditional cue: omit the backend parameter to scan every implemented backend that is available. However, it does not state when to prefer this tool over its many siblings, nor does it give exclusions or alternatives.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully states that the tool relies on GUI configuration rather than parameters, but it does not disclose blocking behavior, failure modes, whether an existing capture is stopped or replaced, or other side effects. For a trigger-style action this is a significant gap.

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 two short sentences with no filler. The core action is front-loaded, and the second sentence adds essential context about the GUI-driven configuration.

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 output schema exists and there are zero parameters, which reduces some completeness demands. Still, the description does not connect to prerequisite or companion tools such as instrument_open or instrument_stop, nor does it clarify behavior if no instrument is open or a capture is already running. It is adequate but not fully complete for integration.

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 is empty, so the baseline is 4. The description reinforces that all settings are inherited from the GUI and no arguments need to be supplied, which adds useful context even though there are no parameters to document.

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 action as 'start capture' on an open instrument, giving a specific verb and resource. However, it does not differentiate itself from the sibling tool instrument_capture, whose name suggests a similar or overlapping operation.

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 mentions that the instrument must be open and that configuration comes from the DSView GUI, but it provides no guidance on when to use this tool versus instrument_capture or other instrument_* siblings. No exclusions, prerequisites beyond 'open instrument', or alternative routing are given.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action without explaining side effects, whether data is preserved or discarded, idempotency, or behavior when no capture is in progress. This is minimal transparency.

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 a single sentence with no filler words or redundant detail. It is front-loaded and appropriately sized for such a simple tool.

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, this is minimally viable: the core action is clear. However, it lacks useful context about preconditions, behavior when no capture is active, and how stopping relates to the broader capture lifecycle, leaving clear gaps.

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 input schema is empty, so there is nothing for the description to clarify. The baseline of 4 for zero-parameter tools applies; no additional parameter semantics are needed.

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 uses a specific verb ('Stop') and a clear resource ('an in-progress capture'), making the action unambiguous. It implicitly distinguishes itself from sibling tools like instrument_start and instrument_capture, though it does not explicitly name alternatives.

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 about when to call this tool, what preconditions exist (e.g., a capture actively in progress), or how it relates to sibling tools like instrument_start or instrument_close. The agent must infer usage entirely from the tool name and one-line description.

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?

With no annotations, the description carries the full burden. It clearly discloses that the tool blocks (synchronous) and that it either completes when capture finishes or times out after timeout_s. This covers the core behavioral trait. However, it does not state what happens on timeout (e.g., error, return value), which remains a minor gap given the output schema exists.

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 sentence, no fluff, and the core action is front-loaded. The conditional phrase 'or timeout_s' efficiently captures the entire behavior. Every word 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 tool is simple with a single parameter and an output schema (though not shown). The description covers the essential behavior and parameter sufficiently for an agent to invoke it correctly in a typical flow. A minor omission is not stating what the return value is or timeout handling, but that may be addressed by the output schema. Overall, adequate.

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 0%, so the description must compensate. It explicitly mentions 'timeout_s' and ties it to the wait duration, adding meaning beyond the bare name and default. However, it does not elaborate on units (though the suffix 's' implies seconds) or edge cases (e.g., negative values). The description partially compensates but not fully.

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 ('Block') and a clear resource ('capture') with a precise condition ('completes or timeout_s'). This distinguishes it from siblings like instrument_start or instrument_stop, which initiate or terminate actions, whereas this is a waiting operation. The purpose 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?

The description gives no guidance on when to use this tool versus alternatives. It does not mention that it should follow instrument_start or instrument_capture, nor does it suggest any exclusion scenarios. Context must be inferred from the name and siblings, but no explicit direction is provided.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal two useful behaviors ('Default sink is command_log' and 'Add framebuffer for PNG'), but fails to mention whether the operation mutates state, requires prior decoding, what side effects occur, or what the output actually contains.

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 two sentences are free of fluff and front-load the primary verb, which is good. But for a tool with 13 undocumented parameters and no annotations, this is severe under-specification rather than appropriately concise prose; it omits essential structure and context.

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 13-parameter tool with zero annotation coverage and zero schema descriptions, the description is far too thin. It leaves the meaning of 'upper decoder', the purpose of most parameters, and the operational context entirely to inference, even though an output schema exists to cover return values.

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 0% across 13 parameters, and the description adds almost no parameter-level meaning. It alludes to sink and framebuffer concepts but never maps them to the schema's sinks, width, height, decoder, out_dir, profile, offsets, or limits, leaving the agent to guess the roles of nearly 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 states a specific action ('Run an upper decoder') on a specific resource ('DecodeJob'), which gives a basic anchor. However, 'upper decoder' is domain jargon that is not explained, and there is no distinction from sibling tools like bus_decode or display_reconstruct, leaving the exact purpose ambiguous.

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?

No usage context is provided: the description never says when to use this tool versus alternatives, nor mentions prerequisites or typical scenarios. The only guidance is the default sink and a framebuffer tip, which are behavioral hints, not usage guidance.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'List' and the absence of parameters transparently signal a non-mutating discovery call, but the description does not explicitly state side-effect freedom, potential I/O latency, or failure behavior. This is adequate for a parameterless read-only tool, but not rich.

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?

A single sentence that is front-loaded with the verb and lists all output categories. There is no filler, repetition, or unnecessary context.

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 parameterless schema, a declared output schema, and a simple enumeration purpose, the description covers what an agent needs to invoke the tool correctly. It names every category the listing covers, and the output schema handles return-value expectations.

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 takes zero parameters, and the schema confirms this with an empty properties object and 100% schema coverage, so the baseline is 4. The description correctly focuses on the enumerated output categories rather than parameter details, since there are no parameters to explain.

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 the verb 'List' and names a concrete resource set: instrument backends, capture adapters, bus decoders, upper decoders, profiles, and sinks. This clearly separates it from action-oriented siblings like bus_decode or capture_open. It could name protocol_roles explicitly, but the resource list is specific enough.

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 implies a discovery/enumeration use case but never states when to call this tool versus alternatives. It gives no exclusions, prerequisites, or contrast with related siblings such as protocol_roles, which might also surface protocol-related information. An agent must infer the intended context from the word 'List' 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?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the subject matter and does not say whether the operation is read-only, whether it mutates state, or what side effects or errors are possible.

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 one short sentence and easy to scan, which is good, but it is under-specified for a tool definition. It is concise by omission rather than by dense, deliberate content.

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 one required parameter and an output schema, the description is too thin to support confident selection and invocation. It omits usage context, parameter semantics, and any behavioral guarantees, leaving the agent to guess.

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 should explain the 'protocol' parameter. It only implies that protocol identifies a bus decoder, without stating valid values, format, or examples.

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 specific content ('channel roles and options_schema') and the resource ('bus decoder'), so an agent can roughly identify what the tool covers. However, it lacks a verb that states the operation (get/return/configure), making it read more as a label than a purpose. It doesn't explicitly differentiate from siblings like protocol_list or bus_decode.

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?

No guidance is given about when to use this tool over sibling tools such as protocol_list or bus_decode. There are no context signals about prerequisites, alternatives, or scenarios where this tool is the right choice.

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?

No annotations are provided, so the description carries the full burden. It states 'Open' which implies an action, but the title suggests read-only status retrieval. The description doesn't disclose side effects, whether it initiates processes, or authentication requirements. It mentions aggregating capture, decode/interpret jobs, and artifacts but not whether this is a safe query.

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 a single short sentence, so it's concise, but it lacks structure and clarity. The verb 'Open' is front-loaded and misleading, and the sentence doesn't build logically to convey the tool's purpose as a status query.

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 tool with an output schema, the description should clarify its role among siblings. It doesn't explain that it aggregates status of capture, decode, and interpret processes, nor that it's a query operation. Given the surrounding tools (capture_open, bus_decode, interpret), the description is insufficient for an agent to correctly select and use this 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?

With zero parameters and 100% schema coverage, the baseline is 4. The description adds context about what the status covers (capture, decode/interpret jobs, artifacts), which is helpful even though no parameters exist to explain.

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 says 'Open capture plus all decode/interpret jobs and artifacts,' which lists resource categories but uses the ambiguous verb 'Open.' Given the title 'Session Status,' a read operation is implied, but the description could be confused with capture_open, which likely opens a capture. It doesn't clearly state that the tool retrieves session status.

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?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention that it's for viewing current session state, nor does it differentiate from capture_open, bus_decode, or interpret. There's no context on prerequisites or typical usage scenarios.

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