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

With no annotations, the description carries the full burden, and it does so well. It discloses the config-file write, optional restart, replace behavior, channel-sharing permission via allow_overlap, and the critical UNIO SIGSEGV risk gated behind allow_crashy. This gives an agent a realistic sense of side effects and hazards.

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 purpose and then organizes parameter details in a compact, scannable format. Every sentence adds useful information, and the UNIO crash warning earns its place as critical safety 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 tool with 8 parameters, no annotations, and no output schema, the description is remarkably complete: it covers side effects, plugin selection, channel order, overlap, replacement, and crash risk. The main gaps are the undefined format_id parameter and the slightly cryptic 'After restart: start() -> export_decoded(analyzer=slot)' line, which could more explicitly state what the tool returns.

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 compensates for most parameters: plugin, channels with concrete per-plugin formats, parameters, allow_overlap, replace, and allow_crashy are all explained. However, format_id is left unexplained, and restart is only indirectly covered by 'optionally restarts', so the compensation is not complete.

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 the action ('Add a built-in decoder') and the concrete effect ('writes vis.config's <analyzers> and optionally restarts KingstVIS'). It clearly distinguishes this from sibling tools like remove_analyzer and list_analyzers, and gives enough detail to know exactly what resource is being modified.

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 context for when adding an analyzer is appropriate, including the script-control/no-GUI intent and a post-add workflow ('start() -> export_decoded(analyzer=slot)'). It references list_analyzer_plugins as the source for valid plugin names but does not explicitly state when not to use this tool or mention alternatives like raw_command.

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 behavioral burden. It discloses blocking behavior, the configure/start/export/parse sequence, the 'leave None to keep current settings' behavior, and the return of export plus parsed capture summaries. This is strong, though it stops short of error behavior or device-side side effects.

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?

Three sentences front-load the workflow and include the most important usage rules and return behavior. There is no filler, repetition, or wasted words.

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 default invocation path well: workflow, blocking, parameter defaults, and return summaries. However, with six undocumented parameters, no annotations, and no output schema, it leaves channels, filename, simulate, and depth/time precedence under-specified, so it is 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%, and the description only addresses rate/depth/time, mentioning that None preserves current settings and time_s is an alternative to depth. The channels, filename, and simulate parameters receive no semantic guidance, leaving significant gaps for a six-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 composite workflow: 'configure -> start (blocking) -> export kvdat -> parse npz' and the use case 'grabbing data for offline analysis'. It clearly distinguishes itself from lower-level siblings like start, export_data, and parse_file by being the one-shot convenience wrapper.

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 'one-shot' and 'convenient single call' framing clearly indicates when to use this tool instead of manually chaining lower-level operations. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to route 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 behavioral burden. It discloses that this opens a TCP connection, performs a handshake, depends on KingstVIS running with the Socket API enabled, and supports environment-variable defaults. It does not mention idempotency or behavior when already connected, but the core side effect is clearly stated.

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 concise sentences, front-loads the primary action, and then gives the necessary configuration detail. Every sentence earns its place without redundancy.

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 simple connect operation with two optional parameters and no output schema, the description covers the main invocation concerns: default endpoint and runtime prerequisites. It does not describe the success/error response shape, but this is a minor gap given the tool's simplicity.

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 schema provides no descriptions (0% coverage), but the description compensates by explaining that empty host/port values fall back to KINGSTVIS_HOST/KINGSTVIS_PORT with default 127.0.0.1:23367. This adds real meaning beyond the raw schema properties.

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 and resource: 'Open the TCP connection to KingstVIS and handshake'. It clearly conveys that this tool establishes a connection, distinguishing it from siblings like disconnect, get_status, and raw_command.

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 practical usage context: host/port can be left empty to use environment variables and a default address, and the software must be running with the Socket API enabled. It does not explicitly say when not to use it or mention alternatives, but the guidance is clear enough for a connection-establishment 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?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that the TCP connection is closed and, importantly, that KingstVIS keeps running, which is a non-obvious behavioral trait. It does not mention side effects like losing unsaved state or whether reconnect is needed, but for a simple disconnect operation the disclosed behavior is sufficient.

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 that immediately states the action and includes the key caveat about KingstVIS continuing to run. Every word is necessary and no filler is present.

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 simplicity—no parameters, no output schema, and a clearly named sibling set—the description fully covers what an agent needs to know to invoke the tool correctly. It specifies what the tool does and the one important behavioral consequence.

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 there is nothing for the description to add beyond the schema. Per the rubric, a tool with no parameters receives a baseline of 4, and the description satisfies that 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 states a specific verb ('Close') and a specific resource ('the TCP connection'), and adds a clarifying parenthetical that KingstVIS keeps running. This clearly distinguishes it from similar lifecycle tools like 'stop' or 'connect'.

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 to close the TCP connection while keeping the application alive, which provides clear context for when to use it. It does not explicitly name alternatives or when-not-to-use conditions, but the parenthetical about KingstVIS staying running effectively communicates the main scope boundary.

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 behavioral disclosure burden and does so well: it explains file side effects, the .npz naming convention, the non-overwrite guarantee for previous formats' npz files, the trigger=0 time convention, and automatic rate/depth use for csv/txt. It does not cover failure modes or permissions, but the disclosed behavior is substantial.

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 and mostly front-loaded, starting with a one-sentence summary followed by parameter-oriented notes. It earns its length, though some phrasing is cryptic such as 'end needs start' and 'summarized here'.

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 5-parameter tool with no annotations and no output schema, the description covers invocation details, file output, format selection, and parsing behavior. Missing details include the default filename/path when filename is omitted and the exact shape or location of the 'summary' returned.

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%, but the description compensates by explaining all five parameters: filename with format selection, channels subset, time_start_s/time_end_s cropping, and parse=true behavior. It adds concrete constraints such as 'end needs start' and the .npz naming convention, giving the agent far more than the raw 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?

The description states a clear verb and resource: it exports the current capture and parses kvdat to .npz. It is more specific than a mere restatement of the tool name, but it does not explicitly contrast itself with export_decoded, so the agent may still need to compare schemas to distinguish them.

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 phrase 'current capture' and the label 'entry point for offline analysis' imply when this tool is appropriate. However, it never explicitly names alternatives such as export_decoded or parse_file, nor does it say when not to use 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?

With no annotations, the description carries the burden of explaining behavior. It usefully discloses prerequisites, analyzer indexing semantics, and the need to wait for decoding. However, it does not mention whether existing files are overwritten, what the default filename behavior is, what errors may occur, or what the tool returns on success or failure.

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: the first sentence states the core purpose, and the remaining sentences provide necessary usage context without fluff. Every sentence contributes useful 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 two-parameter export tool with no annotations and no output schema, the description covers the main operational steps but leaves gaps around filename semantics, default behavior, and failure/return behavior. It is adequate but not complete enough for an agent to confidently handle edge cases.

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 explains that analyzer is a 0-based index into the GUI analyzer list, which adds real meaning. The filename parameter is left entirely unexplained, though its name and the .csv/.txt mention provide some implicit context.

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 exports a protocol analyzer's decode results to .csv/.txt, which is a specific verb and resource. It does not explicitly differentiate itself from the sibling export_data, but the focus on 'decode results' vs. raw data 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 practical guidance: the analyzer must already exist in the KingstVIS GUI, cannot be added via the Socket API, and the agent should wait after start() for decoding to finish. It does not explicitly mention alternatives or when not to use the tool, but the context is clear enough for a straightforward export operation.

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 burden of behavioral disclosure. It discloses one meaningful behavior: the actual depth can be less than configured. It does not mention behavior before any capture, error conditions, or return format, but for a simple getter this is minimally transparent.

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, front-loaded sentence delivers the core meaning and a useful caveat without redundancy. 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 zero-parameter getter, the description is nearly complete: it names the value and its important property. Minor gaps remain around return units and behavior when no capture has occurred, but these are not severe for such a simple 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?

The tool takes zero parameters, and the schema confirms an empty properties object. Therefore no parameter documentation is needed; the baseline for zero-parameter tools is appropriate.

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 resource (actual sample depth of the last capture) and the key qualifier that it may be below the configured value. It does not use an explicit verb like 'gets', but the noun phrase is unambiguous and separates this from configured-depth and sibling getters.

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 phrase 'of the last capture' implies the tool should be used after a capture to inspect measured depth, and 'may be less than configured' hints at comparing against set_sample_depth. However, no explicit when-to-use guidance or alternatives are named, so usage is implied rather than stated.

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 burden of behavioral disclosure. It does explain the key output semantics (capture window in seconds, trigger point at 0), which is useful, but it does not mention behavior before a capture, error cases, or whether any state is affected.

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 that front-loads the essential output semantics. Every token adds meaning, with no filler or redundancy.

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 getter with no output schema, this description is complete enough: it tells the agent the meaning of the returned values, their units, and the trigger reference. There are no arguments to configure and no hidden prerequisites stated beyond what is typical for a getter.

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 there is no parameter ambiguity. The description does not need to compensate for schema gaps, and the baseline of 4 applies.

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 resource: the actual capture window, and specifies the output as [start_s, end_s] with trigger point = 0. It is specific enough to distinguish from sibling tools like get_actual_sample_depth, though it lacks an explicit verb such as 'return' or 'get'.

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 versus alternatives like set_sample_time, get_actual_sample_depth, or capture. The description only states what the result represents, leaving usage context entirely 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?

There are no annotations, so the description carries full responsibility for behavioral disclosure. It only adds 'per official semantics,' which is vague and does not explain whether reading the error clears it, whether it can return null, or whether it has side effects.

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 with no filler. It is appropriately sized for a parameterless getter and is easy to parse.

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 simple no-argument getter, the description is mostly adequate. However, with no output schema and no annotations, the agent is left without information about return value shape, null handling, or whether the error is cleared on read, which could matter for correct use.

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 there is nothing for the description to explain. The baseline of 4 applies because parameter semantics are not a concern.

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 tool as returning the last error message from the software, which is a specific resource and purpose. However, it is essentially a restatement of the tool name and does not explicitly differentiate it from sibling diagnostic tools like get_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 about when to use this tool versus alternatives or how it fits into the broader diagnostic workflow. The description does not mention exclusions, prerequisites, or related 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?

No annotations are provided, so the description carries the burden. It communicates that this is a passive observation of the current sample rate and specifies the unit, but it does not explicitly state that the tool is read-only, has no side effects, or requires an established connection. This is minimal but not misleading.

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 phrase with no filler. It is appropriately sized for a parameterless getter and 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 simple zero-parameter getter with no output schema, the description covers the essential return value and unit. It does not mention operational prerequisites like connection state, but this is a minor gap given the tool's simplicity.

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 already shows an empty properties object, so there is nothing meaningful to add. The baseline for zero-parameter tools is 4, and the description introduces no unnecessary parameter-related details.

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 resource ('current sample rate') and its unit (Hz), and 'current' distinguishes it from sibling tools like set_sample_rate and get_supported_sample_rates. It lacks an explicit verb like 'get' but the meaning 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 word 'current' implies this reads the active sample rate, which helps distinguish it from set_sample_rate or get_supported_sample_rates. However, there is no explicit guidance about when to choose this tool over alternatives or any exclusions.

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 lists returned information but does not explicitly state that this is a read-only operation, say what happens when the device is disconnected, or describe the response structure. The noun-phrase format implies a query but fails to disclose side-effect-free behavior or error handling.

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 compact, front-loaded list of exactly what the tool returns. Every word contributes information, and there is no fluff or repetition. It is highly concise while still conveying the tool's scope.

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 status getter, the description lists the key output categories and is largely complete. However, the lack of an output schema and any note about connection-dependent behavior leaves a small gap about what the agent should expect in edge cases, such as when not connected.

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 description coverage is 100%, so there are no parameter semantics to explain. The baseline for a zero-parameter tool is 4, and the description appropriately adds no irrelevant parameter details.

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 enumerates the tool's output scope: connection state, sample rate, and supported sample rates. Though it lacks an explicit verb, the tool name 'get_status' supplies the action, making the purpose reasonably clear. It does not explicitly distinguish itself from its sibling getters get_sample_rate and get_supported_sample_rates, but the inclusion of 'connection state' gives it a distinct identity.

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 get_status versus the more specific sibling tools like get_sample_rate or get_supported_sample_rates. There is no mention of whether get_status should be preferred for one-stop status checks or avoided in favor of targeted getters, so an agent is left to infer usage context entirely.

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 does clarify that the result is about the connected device and that values are reported in Hz, which is useful. However, it does not disclose the return format, whether an error occurs when no device is connected, or whether the list is sorted.

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 that front-loads the core content: all supported sample rates. It contains no filler, redundant rephrasing, or unnecessary details. Every word earns its place for a tool this simple.

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-argument getter with no output schema, the description is largely complete: it names the result domain, ties it to the connected device, and gives units. It could be more explicit about the return type or error behavior when no device is connected, but those gaps are minor for such a simple invocation.

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 no parameter meaning for the description to add or clarify. The schema fully documents the invocation surface, and the description's unit mention adds value around the output rather than parameters. A baseline of 4 is appropriate for a no-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 communicates that the tool returns all sample rates the connected device supports, expressed in Hz. It is clear and distinguishes itself from get_sample_rate, which presumably returns the current rate rather than the list of supported options. However, it is a noun phrase rather than an explicit verb+resource statement, so it stops short of full specificity.

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 get_sample_rate or set_sample_rate. The description implies a capability enumeration use case, but it never states exclusions, prerequisites, or explicit context such as 'use this to discover valid values before setting the rate.' An agent is left to infer usage from the tool name.

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 burden. It discloses scope (built-in plugins, version-specific count of 46) and implies a read-only listing. It stops short of describing output format or ordering, making this adequate 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 front-loaded sentence where every part earns its place: scope, version context, and concrete examples. No filler 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-argument listing tool, the description is nearly complete: it identifies the returned set and gives representative members. The main gap is a precise statement of the return type and an explicit contrast with list_analyzers.

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 properties, so parameter semantics are trivially satisfied and the baseline of 4 applies. The description adds no parameter detail, but none is needed for a call with no arguments.

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: enumerates all built-in decoder plugins shipped with KingstVIS. The 'built-in' qualifier and the plugin-vs-analyzer distinction separate it from list_analyzers, and the concrete examples make the domain 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?

No guidance on when to use this tool instead of list_analyzers or other siblings. The description does not provide a use case (e.g., before configuring an analyzer) or exclusions (e.g., this does not list currently configured analyzers).

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, and it does: it reveals that analyzers are read from vis.config rather than a live Socket API, and that this family relies on writing config and restarting KingstVIS. This is useful context for understanding staleness or side effects. The only weakness is that the restart/write statement is phrased about the whole family, which could overgeneralize the read-only list 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 two sentences and roughly 30 words, with the core subject front-loaded and the config/restart caveat placed second. No redundant filler is present, and the docs reference is a compact pointer to further detail.

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-argument listing tool with no output schema, the description supplies the data source (vis.config), the entry shape (slot/plugin/settings), and the operational context (config write/restart family). It does not spell out the exact return format, but the tool name and first sentence make that inferable, so the definition is complete enough for correct invocation.

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, so the empty schema fully covers the call signature. The description's mention of slot/plugin/settings refers to the shape of listed entries, which is additional output context rather than parameter documentation. Under the zero-parameter baseline this is adequate.

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 identifies the resource as 'Analyzers currently configured in vis.config' with fields slot/plugin/settings, which is exactly what a list operation should return. It also distinguishes from the sibling list_analyzer_plugins by emphasizing current configuration rather than available plugins. The noun-phrase style relies on the tool name for the verb, but together the intent 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 implied use case is retrieving currently configured analyzers, which is clear from the first sentence. However, the description gives no explicit when-to-use guidance nor does it contrast with alternatives such as list_analyzer_plugins. The second sentence explains the config-file/restart mechanism for this tool family, which provides context but does not direct tool selection.

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 behavioral burden. It discloses paging behavior, the kind filter, and the output content, but it does not mention ordering, failure behavior, read-only guarantees, or whether a file must already be loaded.

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. It front-loads the core operation and output, then lists the kind values compactly.

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 and no annotations, so the description is the main source of behavior. It provides the returned fields but omits prerequisites, ordering, and edge-case behavior, making it incomplete for an agent that must invoke this tool correctly in a larger 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?

The schema has 0% description coverage, so the description must compensate. It does clarify 'kind' with 'all | rising | falling', 'channel' via 'for one channel', and 'Paged' implies the purpose of limit and offset. However, npz_path and exact limit/offset semantics are still left implicit.

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 operation as a paged edge listing for a single channel and specifies the returned data: positions, times in seconds, and the level after each edge. It also distinguishes the edge-kind filter, which separates this from sibling tools like list_analyzers or measure_channel.

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 what the tool does but gives no guidance on when to use it instead of parse_file, measure_channel, capture, or list_analyzers. It also does not state prerequisites such as needing a parsed .npz file or an active connection.

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 behavioral burden. It discloses that the tool is offline (not hardware-touching) and enumerates the exact measurements computed. It does not state return structure or error behavior, but for a read-oriented measurement tool this is adequate 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?

One dense sentence, front-loaded with scope ('one channel of a parsed capture') followed by a concrete, comma-separated list of outputs. No filler or redundant phrasing.

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 simple two-parameter tool with no output schema, the description covers what it computes and what input it needs. Minor omissions such as exact return format, npz_path provenance, and channel indexing convention keep it from being 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%, but the description maps npz_path to a parsed capture and channel to the single channel to measure. It does not provide path format or channel-range details, yet for only two parameters the description adds enough meaning beyond 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?

States a specific verb and resource: measure one channel of a parsed capture. The metric list (edge counts, frequency, duty cycle, pulse-width stats, first/last activity) makes the tool's function concrete and distinguishes it from live-capture or raw-command 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?

'Offline' and 'parsed capture' clearly position this tool as a post-parse analysis step, not a live device operation. It does not explicitly name alternatives or when-not-to-use conditions, but the intended context is clear enough for an agent to select it appropriately.

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 and discloses important side effects: it writes a .npz next to the source, uses a predictable naming scheme, never overwrites a different format's npz, and runs fully offline. It also explains how sample-rate information is obtained per format, which is behavior an agent would otherwise only discover by calling it.

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 yet information-dense. Core purpose and offline nature are front-loaded, and the parameter rules are grouped logically in a way that is easy for an agent to parse.

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?

Covers input formats, parameter requirements, output location/naming, collision behavior, and return summary. The minor gap is that 'capture summary' is not specified in structure or content, and same-format overwrite behavior is left implicit.

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%, and the description fully compensates: it defines when sample_rate_hz is needed versus embedded, and what n_samples is for. The required path parameter is implied by 'exported capture' and 'source.'

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 action ('Parse'), the exact source formats (.kvdat/.bin/.csv/.txt), and the output (.npz). The offline qualifier and file-extension scope set it apart from device-dependent siblings like capture/export_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?

It clearly says this tool is for already-exported capture files and needs no KingstVIS connection, which places it in a distinct workflow from capture/export_data/raw_command. It also gives per-format requirements (bin needs sample_rate_hz; csv/txt require it; n_samples is optional). It does not explicitly name alternatives or exclusions, but the intended context is clear.

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 behavioral burden and discloses key facts: commands are sent verbatim, replies are raw, ACK replies map to ok=true, and commands are limited to 2048 characters. It does not describe timeout behavior or non-ACK/error replies, but the pass-through nature is communicated.

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?

Three short sentences carry the essential information, with the purpose and escape-hatch framing front-loaded. No filler or repetition of schema fields.

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 generic escape hatch with no output schema and no annotations, the description covers purpose, example usage, length limit, and one reply-format detail. It is not fully complete because timeout_s semantics and non-ACK/error response behavior are absent, which an agent would need when invoking arbitrary commands.

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 gives concrete command examples and a length constraint for 'command', but says nothing about 'timeout_s' or how it affects execution, leaving one parameter effectively undocumented except by its name.

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 ('send any Socket API command verbatim') and a clear resource (Socket API), and frames itself as an escape hatch that returns the raw reply. This distinguishes it from the dedicated sibling tools, which are typed wrappers for individual commands.

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 'escape hatch' label implies it is a fallback for commands not covered by dedicated siblings, and the examples show the expected command format. However, it does not explicitly say when to prefer raw_command over a sibling such as get_sample_rate or set_trigger, and one example ('get-sample-rate') overlaps with an existing sibling, leaving some ambiguity.

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 discloses an important behavioral detail—remaining entries are written back as-is and legal channel overlaps never block removal—which helps the agent predict side effects. However, it does not clarify persistence across sessions, error behavior for invalid slots, or what happens if restart is false.

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 concise and front-loaded; the core action is stated first, followed by parameter guidance and behavioral nuance. Every sentence provides distinct value, with no filler 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 two-parameter removal tool with no annotations and no output schema, the description covers the essential context: what to remove, how to identify it, and whether to restart. It could additionally mention failure modes or persistence behavior, but it is sufficient for correct invocation in most cases.

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 both parameters. It does: 'slot' is tied to list_analyzers output and is 0-based, and 'restart' is described as optionally restarting KingstVIS so the change takes effect. This compensates well for the lack of schema-level 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 uses a specific verb ('Remove') and resource ('configured decoder by slot index'), making the action unambiguous. It also states the 0-based indexing, which is critical for correct invocation, and the purpose is clearly distinct from sibling tools like add_analyzer and list_analyzers.

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 that the slot comes from list_analyzers, giving the agent a clear prerequisite for using this tool. It also explains when restart is needed, though it does not explicitly contrast this tool with alternatives; the intended use case is nonetheless 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?

With no annotations, the description carries the full burden but only discloses that the value is in samples via the example. It does not mention valid ranges, whether a connection is required, whether the setting applies immediately, or how it interacts with sample time/rate.

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 entire description is one short sentence that front-loads the operation and then clarifies units with an example. There is no redundancy or wasted 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 simple one-parameter setter, the description is minimally viable but leaves gaps: no usage alternatives, no valid range, and no behavioral details. Since no annotations or output schema exist, the description should provide a bit more context about prerequisites or constraints.

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 schema has 0% description coverage and only labels the parameter as 'depth', so the description compensates by defining it as a sample count and providing a concrete example (20000000 = 20M). It could add bounds or allowed values, but it gives enough semantic meaning for the single parameter.

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, 'Set sample depth', and adds the meaningful unit 'in samples' with a concrete example. It does not explicitly differentiate from sibling tools like set_sample_time or set_sample_rate, so it misses the top score.

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 for when to use this tool versus alternatives such as set_sample_time or set_sample_rate. The description implies only that this tool sets depth, but does not state conditions, prerequisites, or exclusions.

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 behavioral burden. It discloses that unsupported values are rejected and implies validation against a supported list, which is useful behavioral information. It could additionally describe success effects or connection requirements, but the core behavior is adequately covered.

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 sentences carry all necessary information: the action and parameter meaning first, followed by the prerequisite and failure behavior. There is no redundant 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?

For a single-parameter setter with no output schema, the definition is complete: agents know what to set, how to express the value, how to obtain valid options, and what happens if they do not. The reference to get_supported_sample_rates also connects relevant 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 description must fully explain the 'hz' parameter. It does so clearly by stating the unit and giving a concrete example ('10000000 = 10M'), plus the validation behavior tied to valid values.

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 and resource: 'Set the sample rate in Hz', which clearly distinguishes it from get_sample_rate, get_supported_sample_rates, and other sample-related setters. The unit example reinforces the meaning without ambiguity.

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 instructs the agent to call get_supported_sample_rates first and warns that unsupported values are rejected. This provides a clear prerequisite and behavioral expectation, effectively guiding tool selection and invocation order.

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 explaining side effects and behavior. 'Set capture length by time in seconds' describes the operation's surface intent but does not disclose whether this applies immediately to the next capture, whether it conflicts with previously set depth, or what other settings may be affected. The 'alternative to depth' hint is useful but not sufficient.

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 filler. Every word contributes to the core meaning: the action, the value type, and the relationship to the alternative sibling. This is an example of appropriately concise tool documentation.

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 one-parameter setter, the description is minimally viable: an agent knows to pass a number of seconds to define the capture length. However, it lacks contextual details such as when the setting takes effect, how it interacts with sample rate or depth, and whether any constraints apply. With no annotations and no output schema, the description could reasonably provide more surrounding 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 description coverage is 0%, and the only parameter is 'seconds' with type number. The description adds that this value represents the capture length in seconds, which helpfully maps the parameter to its real-world meaning. However, it provides no range, default, or constraints beyond the schema, so the description only partially 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?

States a specific verb and resource: 'Set capture length by time in seconds.' It clearly identifies the operation and unit, and the parenthetical '(alternative to depth)' distinguishes it from the sibling set_sample_depth. This makes the tool's purpose immediately 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 an implied usage signal by calling itself an alternative to depth, which suggests choosing this tool when time-based capture length is desired rather than depth-based. However, it does not explicitly state when to prefer this over set_sample_depth or explain the relationship with capture/start. More direct guidance would improve this dimension.

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 behavioral burden. It discloses the allowed voltage range and gives a practical example, which is useful, but it does not describe side effects, persistence, error behavior, or what happens with out-of-range values.

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 that places the resource first, then the critical range, then an illustrative example. Every element earns its place and there is no redundancy.

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 simple single-parameter setter, the description is close to adequate because the range and example are the main operational details. However, with no annotations and no output schema, it would benefit from an explicit action statement and a note on expected behavior after setting the voltage.

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 compensates well by specifying units (V), the full allowed range (-4.0 to +4.0), and a concrete example. This gives the agent enough meaning for the single 'volts' parameter beyond the bare schema 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 identifies the target resource (IO threshold voltage) and the relevant range, and the tool name provides the action 'set'. It is not confused with any sibling tool, though the description itself does not explicitly distinguish it from 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?

Usage is implied by the resource name and the example value for 3.3V CMOS, which suggests this is used to configure IO logic-level thresholds. However, there is no explicit statement about when to use it versus alternatives, or any exclusions.

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 behavioral disclosure burden. It discloses non-obvious device behavior such as 'last one wins' for edge triggers and that reset=true clears existing conditions first. It does not mention error cases, permissions, or return behavior, but the key device quirks are covered.

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, front-loaded with the core purpose, and every sentence adds value: rule semantics, reset guidance, and representative examples. There is no filler 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?

The description explains the main configuration rules and gives examples, but it leaves some gaps: it does not specify whether parameters combine, whether all parameters are optional together, or what happens when reset=false and new conditions are mixed with existing ones. There is also no mention of expected result or error behavior, though the examples reduce ambiguity.

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 must add parameter meaning. It does this by associating pos_edge/neg_edge with edge-trigger channels and high_level/low_level with level-trigger channel lists, reinforced by concrete examples like pos_edge=0 and high_level=[1,2]. This materially clarifies the bare integer/array schema types.

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 specific verb 'Configure trigger conditions' and immediately clarifies the two trigger families: edge vs level. This distinguishes the tool from sibling configuration tools like set_sample_rate and set_threshold_voltage, which target different resources.

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: edge triggers take one channel while level triggers take several, and reset=true is recommended to clear existing conditions. It does not explicitly name alternatives or exclusion cases, but for its own parameter choices it provides actionable 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, the description carries the burden and discloses important behavior: the call blocks until capture completes, returns actual depth/time, and raises an error on a simulate mismatch so data authenticity is guaranteed. It could also mention prerequisites such as needing a connection, but the main behavioral traits are covered.

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?

Three sentences with no filler: the blocking behavior is front-loaded, followed by the simulation trade-off and the return value. Every sentence 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 one-parameter boolean tool with no output schema, the description covers blocking, mode selection, error behavior, and return value. Missing details like connection prerequisites or timeout behavior are minor given the tool's simplicity.

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 explains the only parameter, simulate, by saying it runs the Demo device and is mutually exclusive with real hardware capture. This adds functional meaning beyond the bare boolean name and default.

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 action ('Start one acquisition') with a distinctive blocking behavior that makes the core purpose unambiguous. It does not explicitly differentiate from sibling 'capture', so it falls short of full sibling-level clarity.

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 clear operating context: real capture needs hardware while simulate=true uses the Demo device, and the two modes are mutually exclusive with mismatch errors. It does not explicitly name when to prefer this tool over alternatives like 'capture', but the guidance is clear enough.

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 behavioral burden. It discloses the important ACK semantics and that no further sampling occurs after acknowledgment. It does not mention side effects, whether the device remains connected, or behavior when no acquisition is running.

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 that front-loads the operation and then adds one useful behavioral clarification. 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 parameterless command with no output schema, the description adequately covers the action and the meaning of the acknowledgment. Omitted details like preconditions or explicit sibling routing are minor given the tool's simplicity.

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 zero parameters, so the description has no parameter meanings to add beyond the schema. The baseline of 4 applies because there is nothing to compensate for.

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 ('Abort') and the target ('the current acquisition'). It differentiates the tool from siblings like start/capture and connect/disconnect by making clear this is specifically about stopping sampling.

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 implied: call this tool when you need to stop the current acquisition. However, the description does not explicitly state when not to use it or how it compares with alternatives such as disconnect or capture.

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