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 clearly states that raw samples are never returned, that analyses defaults to all when omitted, that FFT results are limited by frequency_resolution_hz, and that math traces with the FFT operator are rejected with a rationale. This goes well beyond a minimal description.

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 information-dense but well organized, with the core behavior front-loaded and supporting details following logically. Every sentence earns its place, and the exclusions and alternatives are integrated clearly rather than bolted 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 tool with no output schema and no annotations, the description covers the main return contents, channel constraints, analysis options, precision caveat, and sibling routing. The only notable gap is the undocumented max_points parameter; otherwise the agent has enough context to call 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%, so the description must explain the parameters. It thoroughly explains channel values ('CH1'-'CH4' or 'MATH1'-'MATH4') and the semantics of analyses (stats vs fft, and the default behavior). However, max_points is never mentioned, leaving its meaning and effect 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 specific verb and resource ('Analyze a waveform on the host') and immediately defines the core boundary: it returns only the summary, never raw samples. It also names the sibling tool that does provide raw data, making it clearly distinct from capture_waveform.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit routing guidance: use capture_waveform when raw data is needed, use get_math_state for the instrument's own peak table, and fetch spectrum points with capture_waveform. It also explains why math traces using the FFT operator are rejected, preventing a likely misuse.

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 and does so thoroughly. It discloses that the operation changes settings substantially, that previous settings are lost, that the first call does not execute, and that the changed settings are returned in state afterward.

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 sentences with each sentence earning its place: purpose, destructive consequence, confirmation workflow, and resulting state. It is front-loaded with the core action and avoids unnecessary 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 single-parameter tool with no output schema and no annotations, the description covers the essential agent-facing facts: what changes, what is lost, the required confirmation flow, and what is returned. Nothing critical is missing 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 only parameter, confirm_token, has no schema description, but the description fully explains its purpose and lifecycle: the first call returns a token, and the second call uses it to confirm execution. This adds meaning far beyond the raw schema, which only shows a nullable string with a null 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?

The description clearly identifies the action as 'Run Auto Setup (autoscale)' and states that it auto-adjusts vertical scale, timebase, and trigger. This distinguishes it from manual sibling tools like configure_timebase and configure_trigger by emphasizing that settings are changed together and previous settings are lost.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit procedural guidance: call once to get a confirm_token, ask the human user whether to proceed, then call again with that token. It does not explicitly compare against alternatives or state when not to use auto-setup, but the workflow is clear and actionable.

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 discloses save location behavior, allowed-root restrictions, format options, and the return_image=false behavior. However, it does not specify the exact response structure (e.g., how the image is returned or what metadata fields are included) or default filename generation when path is a directory.

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 efficiently details each parameter in separate lines. Every sentence adds necessary information without redundancy or fluff.

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 no output schema and no annotations, the description covers the essential invocation details, constraints, and alternative routing. The main gap is the exact return structure (metadata fields, image encoding), which an agent might need to process the result correctly. Still, it is largely complete for a straightforward screenshot capture tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain all parameters. It does: path is described as a destination directory/file with resolution and allowed roots, format is enumerated as png/jpg/jpeg/bmp/webp, and return_image is explained as metadata-only when false. This fully compensates for the schema's lack of 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 ('Capture'), resource ('the screen'), and outcome ('save it, and also return the image'), which is unambiguous. It also differentiates itself from the sibling tool measure by explicitly saying 'For numeric readings use measure, not this image.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides when-not-to-use guidance with 'For numeric readings use measure, not this image.' It also gives context for options like 'With return_image=false only the metadata is returned, without the image (saves tokens)', and explains path resolution against the invocation directory and allowed-root restrictions.

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 zero annotations, the description carries the full behavioral burden and delivers exceptionally: CSV file fallback when there are many points with the path returned in data_file, screen decimation with a prescribed way to recover the true sample rate, and the FFT math-trace special case (x_unit 'Hz', sample_interval_s as frequency step, absent effective_sample_rate_sa_per_s). These are exactly the non-obvious behaviors an agent needs to interpret results correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four paragraphs, each load-bearing: core purpose and unit conversion, channel semantics and prerequisites, output/decimation behavior, then the FFT edge case. The description is front-loaded with the primary purpose and contains 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 tool with no output schema and no annotations, coverage is strong: return units, data_file path, sample-interval and x-axis semantics, and the FFT frequency-domain exception are all documented. The one vague spot is the normal time-axis case being left as 'the usual shape,' which assumes agent familiarity with the general return structure.

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 must compensate, and it does thoroughly for channel, documenting valid values, the two categories of sources, and their differing read semantics. max_points is only indirectly addressed through the 'many points' CSV behavior; its actual role in decimation or data-size limiting is never made explicit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Capture waveform data') plus distinctive behavior ('return it converted to volts (V)'), which clearly separates it from capture_screenshot and measure. The channel domain is spelled out exactly ('CH1'-'CH4' or math trace 'MATH1'-'MATH4'), leaving no ambiguity about what this tool produces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit prerequisites: math traces must be configured via configure_math and their display turned on before capture. It names a sibling tool (configure_math) and gives actionable context. However, it never explicitly contrasts this tool with related alternatives like measure or analyze_waveform for the common CH1-CH4 case, so it stops short of full when/when-not 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does this well by explaining that reading measurements enables Result view items, that they accumulate over time, and that re-measuring restores cleared items, which characterizes the tool's side effects and reversibility.

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 with the core action front-loaded in the first sentence. The following two sentences provide valuable behavioral context without filler, repetition, or unnecessary 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-parameter tool with no output schema and no annotations, the description is complete: it defines the action, explains why the action is needed, and tells the agent how to restore cleared items. Nothing essential is missing 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 has zero parameters, so the schema already provides complete coverage. The description correctly does not attempt to document parameters that do not exist, and a baseline of 4 is appropriate for a parameterless 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 opens with a precise verb 'Remove' and a clear object: 'all measurement items from the on-screen Result view.' It also explicitly differentiates itself from the sibling 'measure' tool by explaining that measure enables items on the Result view, so the agent can tell what this tool does and how it relates to nearby tools.

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 the accumulation behavior triggered by measure and states that this tool clears all items, which gives clear context for when to invoke it. It does not explicitly list exclusions or alternative tools, but no other sibling appears to serve the same clearing purpose, and the measure context provides sufficient 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, and it does so thoroughly. It discloses silent clamping with a recommendation to compare against read-back values, rejection of frequency writes for dc/noise, the server's refusal to manage instrument files, and modulation parameter behavior including silent ignoring when off and the server sending enable before parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but the complexity of an 11-parameter AFG configuration with modulation and impedance semantics justifies it. It is front-loaded with the most critical behavioral fact (output state is never touched), and each paragraph is organized around a coherent topic with 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?

For a complex tool with no output schema and no annotations, the description covers all necessary context: parameter constraints, side effects, related tools, workflow ordering, edge cases, and silent-failure risks. An agent has everything needed to invoke this tool correctly and to know what to verify afterward.

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 compensate, and it does. Every parameter is explained with units, ranges, allowed values, and important distinctions such as amplitude being peak-to-peak rather than RMS and impedance being the generator's own output impedance rather than scope input impedance.

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: 'Configure the built-in function generator (AFG)' and immediately clarifies that omitted items are left unchanged. It also distinguishes itself from the sibling tools by explicitly stating it never turns the output on or off, and by referencing enable_afg, disable_afg, and get_afg_state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-not guidance: it never affects output state, so the agent should use enable_afg/disable_afg for output power control and get_afg_state for reading output state. It also clarifies that the AFG impedance parameter is unrelated to configure_channel, preventing misuse.

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 present, the description carries the full behavioral burden and does so excellently. It discloses partial-update semantics, value snapping with the need to trust the applied read-back value, and a safety-critical confirmation flow for impedance='50', including the fact that the first call does not execute and requires returning a confirm_token.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: the core purpose appears first, followed by parameter constraints, then the safety-critical confirmation flow. Every sentence earns its place, with no 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?

For a complex 9-parameter tool with no annotations and no output schema, the description is largely complete: it covers optionality, value snapping, and the dangerous impedance confirmation path. The main gap is that it never explicitly describes the response shape beyond mentioning confirm_token and the applied read-back value, but agents can still safely invoke the tool based on the available guidance.

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 tool description must compensate. It provides essential value constraints for channel ('CH1' to 'CH4'), coupling (DC / AC / GND), impedance ('1M' / '50'), and the confirm_token flow. Some parameters like offset_v, scale_v_per_div, and probe_ratio are left without explicit units or ranges, though their names provide reasonable hints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Configure the vertical axis (a channel).' This clearly distinguishes the tool from siblings like configure_timebase and configure_trigger, and it immediately signals the scope of what can be changed.

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 clearly tells the agent when to use the tool: to change vertical-axis channel settings, and it explains that omitted items stay unchanged and at least one item must be specified. It does not explicitly name alternative tools for reading state or configuring other subsystems, so it stops short of full when-to-use-vs-alternatives 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 and handles it thoroughly. It discloses that omitted items are unchanged, that the acquisition is untouched, that no output is driven, that mode-dependent parameter subtrees are enforced, and that the device may snap values so the read-back value should be trusted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but information-dense, with no filler. It is front-loaded with the core purpose and side-effect safety statement, then organized by parameter group. Every sentence contributes a meaningful constraint or clarification.

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 nine parameters, no annotations, and no output schema, the description is remarkably complete. It covers valid/invalid combinations, what happens when mode is omitted, the requirement to specify at least one item, and how to interpret the applied/read-back value. An agent has enough context to call this 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%, so the description must explain all parameters, and it does. It defines mode values, manual versus track parameter ownership, type values, allowed source names, and units for ax, ay, bx, by. This goes substantially 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?

The description opens with a specific verb and resource: 'Configure the on-screen measurement cursors.' It clearly distinguishes the tool from get_cursor_measurement by stating this tool only moves cursors, while reading cursor reports belongs to another tool.

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 points to get_cursor_measurement as the read counterpart, drawing a clear write-vs-read boundary. It also gives detailed conditions for when modes and position parameters are valid. It does not broadly enumerate alternatives among the many configure_* siblings, but the intended scope 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?

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses that omitted items remain unchanged, that unsupported protocol variants are rejected, that parallel bus_width/bit_sources only work when bus='user' and will be rejected otherwise, and that the tool only changes display/analysis behavior, not acquisition settings.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but appropriately so given the complex settings object. It is front-loaded with the core purpose, then organized into general parameter rules and per-protocol subsections with examples. Every section adds essential information; 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?

Despite having no output schema and minimal input schema, the description is complete for calling the tool correctly. It specifies model-dependent bus counts, supported protocols, all relevant settings per protocol, required sequencing for event_table, and the boundary between decode configuration and acquisition configuration.

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 0% description coverage and no enums, so the description is the sole source of parameter meaning. It fully compensates by defining protocol values, data_format values, source values, and providing detailed per-protocol settings keys with concrete examples for each protocol.

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 first sentence states a specific action and resource: 'Configure a serial protocol decode bus.' This clearly distinguishes it from sibling configure_* tools like configure_channel and configure_trigger, and the rest of the description reinforces that scope by listing protocol types and settings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage context: it notes the bus count can be checked via get_capabilities, instructs setting event_table=true before using get_decode_result, and clearly states that acquisition settings are untouched so channels and trigger must be configured separately. This provides both when-to-use and when-not-to-use 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 full burden and does so thoroughly. It discloses that the acquisition is untouched, no output is driven, omitted items remain unchanged, values may snap, reset is applied after settings, and bound-checking has host-side versus instrument-side behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured in clear, purposeful sections: overview, parameter details, constraints, reset behavior, and caveats. Each sentence adds meaningful information without filler, and important call-order and value-snapping details are front-loaded in 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 nine-parameter configuration tool with no output schema and zero schema descriptions, the description is exceptionally complete, covering side effects, constraints, and read-back trust. The only notable gap is the undocumented 'enabled' parameter, which prevents a perfect score.

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 parameters; it does for type, source, height, left_s, right_s, bottom_v, top_v, and reset, including constraints and semantics. However, the 'enabled' parameter is never mentioned, leaving one of nine parameters unexplained in both schema and description.

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 configuring the waveform histogram and contrasts it with reading statistics via get_histogram_result. It names the specific resource and operation, making it unambiguous alongside sibling configure_* tools.

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: use this to change histogram settings, and read the resulting statistics with get_histogram_result. It does not explicitly state when to avoid using it, but the configuration-vs-read separation is evident enough for an agent to choose 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?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses that the tool is non-destructive to acquisition, that omitted items are left unchanged, that the instrument enforces parameter validity, that rejected writes are reported as errors, and that the device may snap values so read-back should be trusted. This is exemplary 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 long but every section earns its place given the tool's complexity. It front-loads the one-line summary and partial-update behavior, then organizes parameter details into clear paragraphs. The structure makes dense information navigable.

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 12-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description is remarkably complete: it covers behavior, valid parameter combinations, error handling, read-back paths, trace fetching, and value snapping. The only notable gap is the undocumented 'display' parameter and the lack of explicit when-not-to-use guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since schema description coverage is 0%, the description must compensate, and it does extensively: operator enum values, source and lsource constraints, scale/offset/invert semantics, and detailed fft and filter subfields. However, the 'display' parameter from the schema is never mentioned, leaving one parameter unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Configure a math (waveform arithmetic) trace.' It further differentiates itself from acquisition tools by explaining that it computes a new trace from channels already being acquired, changes nothing about the acquisition, and drives no output. This makes it clearly distinguishable from configure_channel and configure_trigger.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: it operates on channels already being acquired, requires at least one item to be specified, and tells the agent to read results back with get_math_state and fetch traces with capture_waveform. It does not explicitly name alternatives or say 'use X instead of Y', but the guidance is strong enough for an agent to select and invoke the 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It discloses that the acquisition is untouched and no output is driven, that the device may snap values so the read-back 'applied' value should be trusted, and that rejected writes come back as errors. These are non-obvious behaviors that materially affect how an agent should use and interpret the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every paragraph earns its place: it maps cleanly to parameter groups and dependency rules. The opening sentence states the core purpose, and later paragraphs are front-loaded with the parameter name before explaining semantics. The length is justified by the tool's conditional behavior across two device kinds.

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 configuration tool with 7 parameters, no output schema, and no annotations, the description provides complete context: it explains all parameter semantics, the counter/DVM distinction, parameter dependencies, error behavior, ordering of clear_totalize, and the meaning of the read-back value. An agent has enough information to construct valid calls and interpret responses.

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 parameters, and it does. It defines kind values, mode values per kind, source constraints per kind, digits and totalize_enabled coupling to mode, clear_totalize timing, and the requirement to specify at least one item. Every parameter in the schema gets meaningful semantic explanation beyond its raw name and 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 opens with a specific verb and resource: 'Configure the frequency counter or the digital voltmeter.' It clearly distinguishes this tool from other configure_* siblings by defining its scope as the meter display reading only, and even names get_meter_value as the complementary read operation. An agent can tell exactly what this tool is for and what it is not for.

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 tells the agent when to use this tool versus get_meter_value: configure here, read there. It also gives strong usage context, such as 'Omitted items are left unchanged,' 'Specify at least one item to change,' and 'set the mode in the same call as the parameters that depend on it.' This is actionable guidance for correct invocation.

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 behavioral burden, and it excels. It discloses irreversibility of save=true, no undo, no way to check before overwriting, reset ordering, label_display being a global switch, and that the firmware accepts non-displayed sources despite the programming guide. It also notes the device may snap values and that applied should be trusted. This is exceptionally 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?

The description is long but dense and well-organized, with each paragraph covering a coherent aspect: slot semantics, source, display settings, global switch, save/reset behavior, and alternatives. It is front-loaded with the core concept and safety-relevant warnings. A small amount of trimming could improve brevity, but every sentence carries meaningful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and 0% schema coverage, the description leaves little unknown. It explains operation ordering, irreversibility, global side effects, read-back via get_reference_state, and even covers limitations (cannot be downloaded) with a numeric comparison alternative. The agent has enough context to call the tool correctly and safely.

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 define all parameters itself, and it does. It explains ref (slot 1-10), source ('CH1'-'CH4', 'MATH1'-'MATH4', 'D0'-'D15'), scale and offset_v (vertical scale/offset of stored trace), color and label (with allowed characters), label_display (global switch), save (stores source waveform, sent last), and reset (restores defaults, sent first). No parameter is left undefined.

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 configures a reference waveform slot, defines what a reference waveform is (a stored trace drawn over the live one), and distinguishes it from simple capture or math operations. The scope is explicit: it only changes display/computation, not acquisition or output. This fully separates it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool and when not to, pointing to alternatives: use get_reference_state to read back, use configure_math with subtract and capture_waveform for host-side numerical comparison. It also gives operational conditions such as 'Specify at least one item to change' and warns to ask the human before overwriting a slot. This is exemplary routing and usage context.

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

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

With no annotations, the description carries the burden of behavioral disclosure, and it does well: it explains partial updates, the minimum requirement, the possibility of value snapping, and advises trusting the read-back value. This gives the agent important expectations about device behavior beyond the basic input schema.

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, with each sentence earning its place: purpose, partial-update semantics, validation requirement, and a behavioral warning. No redundant or filler content exists.

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 gives essential behavioral context and implies a read-back value, but it does not explain prerequisites, return structure, or parameter semantics. For a simple two-parameter configure tool it is adequate, yet the lack of parameter explanation and explicit usage guidance leaves some 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?

Schema description coverage is 0%, so the description should compensate by explaining parameter meanings, but it does not mention position_s or scale_s_per_div explicitly. It refers to 'items' generically, leaving the agent to rely on the schema titles with no additional semantic guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Configure') and the resource ('horizontal axis (timebase)'), making the tool's purpose immediately obvious. It is also distinct from sibling configure tools like configure_channel, configure_trigger, and configure_decode, so an agent can tell them apart.

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 this tool is for changing timebase settings, but it does not explicitly state when to choose it over alternatives or provide exclusions. The 'Specify at least one item to change' line is useful, but there is no direct comparison to other configure 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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It does disclose a non-obvious behavior: 'Omitted items are left unchanged' (partial update semantics) and requires at least one item to change. However, it does not mention side effects on acquisition, error handling, or whether the configuration persists across runs. The update semantics are useful but incomplete.

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 brief and to the point, using line breaks to separate parameter details. It avoids fluff and front-loads the primary purpose. The only minor issue is that level_v is not mentioned, but that is a completeness issue rather than a conciseness one. The structure is efficient.

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 mutation tool with no output schema, the description should explain expected return/confirmation, prerequisites (e.g., device connection), and all parameters. It omits level_v entirely and provides no information on the return value or any constraints that might cause errors. This leaves an agent without enough context to call it confidently in all 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 has no descriptions (0% coverage), so the description must explain parameters. It does explain source, slope, and sweep_mode with their allowed values, which adds meaning. However, it completely omits level_v, leaving its units and range undocumented. It covers 3 of 4 parameters, providing partial but not complete compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Configure the edge trigger.' It specifies the resource (edge trigger) and the verb (configure), and the allowed parameters make it distinct from sibling tools like get_trigger or configure_channel. This is a specific, unambiguous definition.

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 context that this is for configuring the edge trigger and lists allowed values for three parameters, which implicitly guides usage. However, it does not explicitly state when to use this tool instead of alternatives like get_trigger or configure_timebase, nor does it mention any prerequisites or exclusions. Some implied guidance but lacks explicit comparison.

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 explicitly states a key side effect: 'Any existing connection is replaced.' It also discloses default inference behavior for transport and port, which helps the agent predict what will happen beyond the parameter schema.

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, front-loaded with the core purpose, and every sentence adds necessary guidance. It avoids redundant restatement of the tool name and keeps the important behavioral details in a small, scannable block.

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 connection tool with three optional parameters and no output schema, the description covers the essential context: what to pass, what to do when information is missing, default inference behavior, and the side effect of replacing an existing connection. It does not explain failure modes, but the invocation contract is sufficiently 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 does: address is the user-provided connection target, transport is inferred from the address format, and port defaults to the profile value. It does not enumerate all transport options, but it compensates for the schema gap effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb-plus-resource statement, 'Connect to the oscilloscope,' which identifies the tool's purpose and distinguishes it from sibling operations like disconnect, configure_trigger, or run. It does not explicitly contrast itself with alternatives, but the action is specific and 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 provides concrete usage guidance: pass the address the user provided, ask the user rather than guessing, and rely on inference/defaults when values are omitted. It does not mention when to prefer sibling tools, but it gives clear operational context for calling connect 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?

With no annotations, the description carries the full burden, and it excels: it discloses immediate effect, no confirmation flow, the safety rationale, that waveform settings persist, and that the return value contains channel state with output false. This goes well beyond the structured 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 front-loaded with the core action, then adds rationale, usage timing, persistence behavior, and return value in a compact, well-organized way. Every sentence adds distinct value 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 one-parameter, side-effect-bearing tool with no output schema, the description is complete: it explains what happens, when to use it, why no confirmation is needed, what is preserved, and what the return value contains. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should compensate. It mentions 'the channel in state' and implies the channel parameter selects the AFG output to disable, but it never explicitly defines valid values or clarifies that the channel is the single parameter. The name/default make it inferable, but explicit guidance is missing.

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 ('Turn off') and resource ('function generator output') with an immediate consequence ('no signal comes out any more'). This clearly differentiates it from enable_afg and other stop-type 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?

Gives explicit directives: 'Use it as soon as the measurement is done, and whenever the user asks for the signal to stop.' It also explains that no confirmation is needed by design, which tells the agent when direct invocation is safe, and references enable_afg as the counterpart for re-enabling.

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 explicitly notes that closing an already disconnected connection is not an error, which is a useful non-obvious behavior. However, it does not disclose side effects like resource cleanup or impact on other operations, but for a simple disconnect the key behavior is 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?

A single, front-loaded sentence that states the core action and the one important edge case. No wasted words, and the key non-error condition is included. Ideal conciseness for 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 parameter-less, side-effect-simple action, the description is largely complete. It tells the agent what happens (closes the connection) and that being already disconnected is not an error. It does not describe what happens to ongoing operations or resources, but such detail may be unnecessary for this tool's simplicity. Given the lack of output schema and annotations, this is 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?

The tool has zero parameters, so the schema already trivially covers 100%. The description adds no parameter-specific meaning, but none is needed. A baseline of 4 is appropriate for parameter-less tools.

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 current connection'). It clearly distinguishes from the sibling 'connect' and other configuration tools. 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?

No explicit guidance on when to use this tool versus alternatives. The context (a session lifecycle) implies it should be used after 'connect', but the description does not state this. There is no mention of alternatives or exclusions, leaving usage timing 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 carries the full burden and exceeds it. It discloses the dangerous nature, the two-step confirmation flow (first call returns token, second call consumes it), token properties (channel-bound, single-use, expires), and the critical safety requirement to never self-confirm or drive live circuits. It also states the exact return shape ('settings with output true'). This is thorough behavioral disclosure well beyond the schema.

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?

Every sentence earns its place. The dangerous warning is front-loaded, followed by the two-step flow, then required safety checks, and finally return behavior and pointer to disable_afg. There is no redundant or vague wording; the structure guides the agent from danger identification to safe execution.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (dangerous action, two-step confirmation, no output schema, no annotations), the description is remarkably complete. It covers prerequisites, the exact calling sequence, safety constraints, token lifetime, and return value. It even tells the agent what to show the human user. Any missing edge cases (e.g., invalid token error) are minor given the strong procedural guidance.

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 thoroughly explains confirm_token: it comes from the first call, is required for the second, is single-use and expires. Channel is less explicit; the description references 'this channel' in the token binding but doesn't directly explain the parameter's valid values or meaning. Still, the description adds substantial semantic value for the more complex parameter, earning a 4 rather than a 3.

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?

Purpose is explicitly stated with a specific verb and resource: 'turn the function generator output on (a real signal starts coming out).' It distinguishes itself from disable_afg by explicitly naming it as the complementary off-switch, and from get_afg_state as the read-before-act tool. No ambiguity about what this tool does.

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 states it is 'the only tool that makes the instrument drive a signal,' which clearly establishes when to use it versus any sibling. It also prescribes a specific workflow: read get_afg_state first, show the user, ask about safety, then confirm. It names disable_afg as the tool for turning the output off, giving clear alternatives and conditions.

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

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

With no annotations, the description carries the full burden. 'Return' implies a read-only query, but the description does not explicitly confirm it is non-mutating or mention any side effects. For a simple getter this is minimal but acceptable.

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, direct sentence that front-loads the key information without any filler. Every word contributes.

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 getter with no params and no output schema, the description is adequate but lacks usage guidance and does not detail the exact return format or possible values (e.g., what the trigger status looks like).

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 no parameter explanation is needed. The schema is trivially covered, and the baseline for zero-parameter tools 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 the action ('Return'), the resource ('acquisition state'), and the content ('whether it is running, and the trigger status'). This makes it easy to distinguish from generic siblings like 'get_state' or 'get_trigger'.

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 such as 'get_state' or 'get_trigger'. The description lacks any conditions, exclusions, or comparisons to 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 carries the full burden. It explicitly discloses that reading never changes output, that the operation is read-only, and that it costs about 14 queries per channel. It also explains the output and modulation semantics in useful detail.

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 detailed yet efficient. It front-loads the core purpose, then adds precisely the behavioral and structural details an agent needs. Every sentence contributes meaningful information without fluff.

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?

Despite having no output schema and no annotations, the description covers return shape, per-channel behavior, output semantics, modulation details, and performance cost. An agent can select and invoke this tool effectively with the information provided.

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 description for the channel parameter, but the description thoroughly explains both cases: with channel given returns flat settings, and with channel omitted returns all channels keyed by channel number as a string. This fully compensates for the 0% schema 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 states a specific verb and resource: 'Return the function generator settings, including whether the output is on.' This makes the tool's purpose immediately clear and distinct from sibling tools like configure_afg, enable_afg, and get_state.

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 clearly implies this is for reading AFG state and explicitly notes it is read-only and 'never changes' the output. However, it does not explicitly name alternatives or state when not to use it, such as using configure_afg or enable_afg for changes.

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 useful non-obvious behavior: profile confidence levels, the caveat that 'guide' is decoded from the programming guide and not confirmed on hardware, restriction of unverified features below 'verified', and the null behavior of 'options'. It could still explicitly state that it is read-only and does not modify device state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the main purpose, followed by dense caveats. Every sentence contributes information, though the phrase 'Below verified, unverified features are restricted' is awkward and could have been worded more clearly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description makes a reasonable effort to explain the return content and edge cases such as null options and unverified feature restrictions. It does not specify the exact response structure, but for a parameterless capability query this is sufficient for an agent to call and interpret results.

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 are no parameter semantics to document. The description adds value by explaining the meaning of returned capability fields, such as confidence, options, and restrictions, which is more useful than the empty input 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+resource: 'Return the features available on the connected device' and gives examples like channel count and supported features. It is clear what the tool does, but it does not explicitly contrast it with siblings such as get_state or get_acquisition_state.

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?

Implies the tool is used to discover device capabilities after connecting, but gives no explicit when-to-use or when-not-to-use guidance. There are no clearly overlapping siblings, so the omission is not fatal, but the usage decision is left mostly to the agent.

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

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

No annotations are provided, so the description must fully disclose behavior. It implies a read-only query via 'return' but does not clarify whether a connection is required, what exactly constitutes 'state', or if there are any side effects. This is minimal disclosure.

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. It delivers the core purpose and parameter constraint up front.

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 no output schema and the description does not describe the return format or the semantics of 'state'. It also omits any prerequisites (e.g., connection state). For a simple getter, an agent would still benefit from knowing what the response looks like, so the description is incomplete.

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 provides no description for the 'channel' parameter (0% coverage). The description compensates by specifying the allowed values ('CH1' to 'CH4'), which is essential and non-obvious from the schema alone.

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 ('return') and resource ('state of one channel'), and explicitly enumerates valid channel values ('CH1' to 'CH4'). This makes the tool's purpose unambiguous and distinguishes it from siblings like configure_channel and get_state.

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. The description does not mention conditions, prerequisites, or exclusions, leaving the agent without context for 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?

Because no annotations are provided, the description carries the full behavioral burden. It transparently explains mode-dependent return behavior, the null case for 1/deltaX with deltaX=0, and the fact that only mode is returned when there is nothing to read. It doesn't discuss errors or permissions, but for a non-mutating instrument read this is strong coverage.

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 well organized: a one-line purpose, a precise list of output fields with units, and a short edge-case paragraph. Every sentence contributes useful information 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?

There is no output schema, so the description fully compensates by documenting the return fields, their units, the null behavior, and the only-mode behavior in invalid cursor modes. It also supplies the prerequisite action (configure_cursor first), making it complete for safe 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, so the schema is trivially complete and parameter semantics do not need elaboration. The description appropriately focuses on return values instead of parameters, matching the 0-param baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific read verb and resource ('Read what the cursors currently measure'), then enumerates the exact returned values and their units. It distinguishes itself from the sibling configure_cursor by explicitly positioning that tool as the prerequisite for placing cursors, so an agent can tell get vs. configure apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: when cursor mode is off or xy, there is nothing to read, and only mode is returned; it also instructs the agent to call configure_cursor first. It does not explicitly contrast with other measurement siblings like measure, but the read-only retrieval role is well established.

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 excels: it warns that no table is read if configuration is missing, that the table is only a snapshot if acquisition is running, that column names are variable, and that values are strings formatted according to data_format. It also discloses truncation semantics via max_events and event_count.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and dense, with the core purpose front-loaded, followed by prerequisites, then data-format caveats. Every sentence adds value, and no fluff or repetition exists.

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?

Despite having no output schema or annotations, the description fully equips an agent to call the tool correctly: it covers preconditions, variable column names, units, formatting, and truncation behavior. No critical gap remains.

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 does: 'bus' is explained as decode bus 1-4, and 'max_events' is described as returning only the first N events, with event_count always the total count before truncation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Read the decoded event table of a decode bus (bus 1-4).' It clearly distinguishes this tool from siblings like configure_decode and stop, and the bus range adds precise scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states prerequisites: call configure_decode with enabled=true and event_table=true first, and stop acquisition before reading. It also explains the consequence of not following these steps, leaving no doubt about when and how to use the 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?

No annotations are present, so the description carries full responsibility and delivers thoroughly: it explains raw always present, parsed stats keys, base-unit conversion, _unit keys, warnings behavior, and the disabled-histogram case where raw is empty. This is exceptional behavioral disclosure.

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?

Every sentence earns its place: purpose first, then return-value semantics, then usage guidance. Despite being detailed, it remains tightly structured and front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description must explain return values and edge cases itself, and it does so completely: raw format, stats fields, unit handling, warnings, disabled behavior, and operational prerequisites. Nothing needed to call the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema is empty, so there are no parameter semantics to document. The baseline of 4 applies; the description instead adds value by explaining what the read operation returns.

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?

Opens with a specific verb and resource: 'Read the histogram statistics.' The tool name and sibling list confirm this is the getter for histogram results, and the description's detailed focus on histogram data clearly separates it from other 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?

Clearly states prerequisites: 'Enable the histogram with configure_histogram first' and advises stopping acquisition for a stable snapshot. It does not explicitly contrast with alternative read tools, but the usage context is concrete and actionable.

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 present, the description carries the full burden and handles it thoroughly. It explicitly says the operation is read-only, never changes the display, costs a few queries per trace, and discloses operator-dependent response behavior including FFT peak handling and warnings.

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, then uses short paragraphs to cover the optional parameter behavior, operator-dependent keys, and side-effect/cost notes. Each sentence adds necessary information that is not already in the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description is unusually complete: it documents return shapes for both parameter modes, key selection per operator, FFT peak details and warnings, and the cost profile. Nothing an agent needs to call the tool correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides only the type and default for channel, with zero property descriptions. The description compensates fully by stating the valid channel range (1-4), the flattened single-trace result shape, the all-traces result shape when omitted, and how traces are keyed by string numbers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Return the math trace settings') and enumerates the exact scope (channel, display, operator, sources). This is distinct from generic sibling getters like get_state or get_channel, so an agent can identify the tool's purpose immediately.

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 invocation context by explaining both the channel-given and channel-omitted cases, effectively telling an agent how to request a single trace versus all traces. It does not explicitly name an alternative getter or state when not to use this tool, so it stops short of full alternative routing.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so thoroughly. It explains that value is null when the instrument cannot produce a reading, null while enabled is false, the source is reported, and that the counter may return 0 or null for the first three seconds after enabling—an important non-obvious behavior an agent would otherwise misread as a real null reading.

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 read operation, then adds only behaviorally relevant details: allowed kind values, unit mapping, null semantics, the configure_meter prerequisite, and the settling-time caveat. Every sentence carries useful information, and the structure is logical from summary to operational caveats.

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?

Even without an output schema or annotations, the description is complete enough for an agent to call the tool correctly: it specifies the parameter values, expected return fields (value, unit, mode, settings, source), null behavior, and timing caveats. No critical operational detail is missing for a single-parameter read 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 schema only says kind is a string with 0% description coverage, so the description must compensate. It explicitly defines the allowed values ('counter' or 'dvm'), links them to the returned unit and mode, and explains the effect of the parameter—making the single parameter fully meaningful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Read the current frequency counter or digital voltmeter value with its unit.' It further clarifies that kind selects the meter mode and distinguishes this read operation from other instrument tools, so an agent can identify what this tool does and what it applies to.

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: use kind='counter' or 'dvm', configure_meter must be called first to turn the meter on, and the counter needs about three seconds to settle after being enabled. It does not explicitly compare this tool to siblings or state when not to use it, so it misses the exclusion/alternative guidance that would make it a 5.

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

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

With no annotations present, the description carries the full burden and does this thoroughly: it explicitly states the operation is read-only and never changes the display, discloses the six-queries-per-slot cost, and explains the global label_display behavior and the inability to detect stored waveforms.

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?

Every sentence adds meaningful information: purpose, parameter effect, output shape, global-label caveat, limitation, safety, and cost. The structure is front-loaded with the definition and branches into details, with no redundant or filler text.

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?

Because no output schema is provided, the description needs to explain return shapes and caveats, and it does. It covers both response forms, the field set, the global label switch behavior, the unqueryable stored-waveform status, and the query cost — enough for an agent to call and interpret results 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 only defines 'ref' as an optional integer/null with zero description coverage. The description compensates fully by specifying the valid range (1-10), the flat return with ref, the keyed channels structure without ref, and the string-keyed slot numbers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Return the reference waveform settings') and enumerates the returned fields. This clearly distinguishes it from sibling getters like get_channel and get_state, which target different subsystems.

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 explains the two invocation modes (ref given vs omitted) and the resulting response shape, and notes that the tool cannot be used to check whether a slot holds a stored waveform. It does not name an alternative sibling, but there is no ambiguous overlap for reference-state queries, so the context is sufficient.

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 a significant performance characteristic: 'a full read is about 39 queries and can take several seconds,' which is beyond what annotations would provide. It also clarifies the effect of the sections parameter on the response. However, it doesn't mention any potential side effects or return format, but for a read-only getter, the disclosure is solid.

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 sentences long, front-loaded with the tool's purpose, followed by usage guidance and behavior. Every sentence adds value with no redundancy or filler. It is well-structured and 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 tool with one optional parameter and no output schema, the description is mostly complete. It explains the purpose, parameter semantics, and performance tradeoff. The only gap is a lack of explicit return value structure, but the tool is a simple getter and the description states it returns the requested sections, which is sufficient for 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 schema provides only a name and type for 'sections' with no description, so the description must compensate. It does: it explains that narrowing with sections is faster and that omitting returns every section, giving the parameter semantic meaning. It also lists the possible section names in parentheses (channels / timebase / trigger / acquisition), which helps an agent know what values to pass.

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 'Get the main settings (channels / timebase / trigger / acquisition) in one call,' using a specific verb and resource. It distinguishes itself from sibling tools like get_channel, get_timebase, get_trigger, and get_acquisition_state by emphasizing it retrieves multiple sections in a single call.

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 explicitly tells when to use the sections parameter: 'When you know what you need, narrowing with sections is much faster' and explains the tradeoff with a full read. It also states 'Omitting sections returns every section,' providing clear behavioral expectations. While it doesn't explicitly name alternatives, the guidance is sufficient for an agent to decide when to use this tool versus narrower getters.

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 states the getter nature ('Return'), implying a non-destructive read, but does not mention prerequisites (e.g., connection state), side effects, or return format. For a simple getter, this is minimally adequate but lacks depth.

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 with no superfluous words. It is front-loaded with the action and resource, and every word earns its place. Perfect conciseness.

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, read-only getter with no output schema, the description provides sufficient context. It specifies the exact aspect of state being returned (horizontal timebase) and is complete for the low complexity. The only minor gap is lack of mention of return format, but this is not critical 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 has zero parameters, so the baseline for parameter semantics is 4 per the rules. The description correctly implies no parameters are needed by not mentioning any, and there is nothing to add beyond the schema which is already 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 clearly states the verb 'Return' and the resource 'the horizontal (timebase) state'. It distinguishes the tool from siblings like get_trigger and get_acquisition_state by specifying the timebase focus. The purpose is 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?

There is no guidance on when to use this tool versus alternatives such as get_state or get_trigger. The description only gives the action and resource, leaving the agent to infer usage context. No exclusions or alternative routing are mentioned.

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. 'Return' implies a read-only operation, but the description does not explicitly state that it has no side effects, nor does it mention whether a connection or configuration is required. It adds the scope 'settings and status' but leaves the exact behavioral profile implicit.

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 the action verb first and the target resource immediately after. It contains no filler or redundant phrases, making it highly scannable and appropriately sized for a trivial getter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read with no output schema, the description gives only a high-level indication of what is returned. It does not enumerate which trigger settings or what status fields are included, and with no annotations or output schema, an agent has limited information to anticipate the response shape. Additional detail about return contents would make it 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?

The tool has zero parameters, so the input schema is empty and schema coverage is trivially 100%. The baseline for zero-parameter tools is 4, and the description correctly avoids inventing parameter details that do not exist.

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 the specific verb 'Return' and identifies the resource 'trigger' with the scope 'settings and status.' This clearly differentiates it from configure_trigger, which modifies trigger settings, and from broader getters like get_state, so an agent can select it without needing to open schemas.

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 guidance is provided. The description does not state when to use this tool versus configure_trigger or get_state, nor does it mention any prerequisites or exclusions. The agent must infer usage entirely from the tool name and the bare 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 usefully states that returned values use SI-suffixed keys and warns about quality validity. However, it does not disclose whether the operation is read-only, requires an active acquisition, or how errors are reported.

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-loads the core action, followed by the measurement enum and output format. All sentences contribute value, though the line breaks could be more structured for readability.

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?

Without output schema or annotations, the description must stand alone. It covers the key inputs and output format, but omits details such as error behavior, whether a waveform must already be acquired, and the exact shape of the returned object. Adequate but with 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 input schema provides zero descriptions, so the description compensates by listing the allowed measurement strings and the output key naming convention. It adds real meaning beyond the bare schema, though the channel parameter is not further clarified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Measure the given channel' and enumerates the measurement types, making the primary function unambiguous. However, it does not explicitly distinguish this tool from siblings like analyze_waveform or capture_waveform, so it misses full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no context about how it fits into a workflow. The list of measurements only hints at parameter selection, not 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, the description must carry behavioral disclosure. It adds 'continuous run,' which is useful, but it does not state whether acquisition continues until stopped, what happens if already running, whether it blocks, or what prerequisites exist. These are significant gaps for a control action.

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 communicates the action and the key mode distinction without any filler. It is perfectly sized for a no-parameter command.

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-parameter trigger, the description is minimally viable, but it leaves clear gaps: no usage guidance versus single, no mention of stop as the counterpart, and no behavioral side effects. These omissions matter even in 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 has zero parameters and an empty schema, so the description has no parameter semantics to clarify. This matches the baseline for a no-parameter tool; there is nothing missing.

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 ('Start') and resource ('waveform acquisition'), and the parenthetical 'continuous run' distinguishes it from one-shot acquisition tools like single. This is clear and unambiguous even without naming 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?

The phrase 'continuous run' implies use for continuous acquisition rather than single-shot, and the sibling list includes single and stop, but the description never explicitly says when to use run versus single or how to stop it. Usage context is implied, not 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 full burden. It discloses the disconnected behavior (returns connected: false instead of error) and mentions the *IDN? query, adding useful context. However, it doesn't describe potential failure modes beyond disconnection or the format of the returned identity/profile.

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, front-loaded with the main function, then a note on disconnected behavior. 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 parameterless identification tool, the description covers what it returns and the key edge case (disconnected). Without an output schema, it doesn't need to detail return formatting. It is sufficient for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, the schema fully covers parameter semantics. The description need not add parameter detail, and the 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 a specific verb (Return) and resource (connection state and device identity including *IDN? and profile). It distinguishes from siblings like get_state by combining connection state and identity, though it doesn't 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?

The description provides clear usage context: it is safe to call when disconnected, implying it can be used to check connection state. It does not explicitly list alternatives or exclusions, which are unnecessary for this simple 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 provided, the description must carry the full burden of behavioral disclosure. It does state that the action 'triggers once, then stops', which is a meaningful behavioral trait, but it does not explain side effects (e.g., what happens to previously acquired data, whether this changes the device state, or if it requires a configured trigger). For a simple control action, this is partial transparency but lacks full context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no redundant words. It front-loads the core action ('single-shot acquisition') and immediately states the stopping behavior. This is an ideal conciseness level for a no-parameter 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?

The tool is simple: no parameters, no output schema, and a clear one-sentence behavior. Given its elementary nature, the description is practically complete. However, it does not mention how it relates to sibling tools like 'run' or 'stop', nor does it clarify whether it requires a preconfigured trigger. These small omissions keep it from being a perfect 5.

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 the input schema is empty and schema description coverage is trivially 100%. The baseline for no parameters is 4, and the description does not need to compensate for any parameter documentation gaps. It correctly implies there are no configurable options.

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 ('single-shot acquisition') with a clear behavioral qualifier ('triggers once, then stops'). It distinguishes itself from likely continuous acquisition tools like 'run' and from 'capture_waveform' by emphasizing the 'single' nature, though it does not explicitly name any sibling. This makes the purpose clear, but slightly generic because 'acquisition' is not defined further.

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 such as 'run', 'stop', or 'capture_waveform'. The description does not mention conditions that would favor this tool over a continuous acquisition, nor any prerequisites or relationship to other tools. The agent is left to infer that 'single' is appropriate for one-shot measurements, but this is not explicit.

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 the behavioral effect ('freezes the waveform on screen') and the state change (stopping acquisition). However, it does not specify idempotency, side effects (e.g., whether the acquisition resumes later), or error conditions if already stopped. These omissions are minor for a simple tool.

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 of ten words, front-loaded with the action and result, with no filler. It is appropriately sized for the tool's simplicity and makes efficient use of the description space.

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 trivial nature (no parameters, no output schema, no annotations), the description provides the essential information: what it does and the observable effect. There is no additional context the agent would need to invoke it correctly, aside from the usage ambiguity already noted, which is covered under usage guidelines.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema coverage is 100% (none to describe). The baseline for 0 params is 4; the description correctly avoids adding any parameter-related noise. No compensation is 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 resource ('waveform acquisition') and clarifies the result ('freezes the waveform on screen'). This clearly distinguishes it from siblings like 'run' and 'single'—an agent can infer its core function 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?

No explicit guidance on when to use this tool versus alternatives. The description implies stopping an ongoing acquisition, but it does not mention that 'single' also halts after one trigger, which could lead to confusion. There is no contrast with siblings or mention of prerequisites like needing an active run.

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 does an excellent job. It discloses the re-application of preset frequency/phase, the dual-channel effect, the condition for visible effect, the lack of impact on amplitude/output state, that no confirmation is needed, and the SCPI prefix routing nuance. This is thoroughly 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?

The description is compact and efficiently front-loads the core purpose in the first sentence. Every subsequent sentence adds meaningful behavioral or conditional detail without 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 simple one-parameter tool with no annotations and no output schema, this description is complete. It explains purpose, behavior, side effects, parameter semantics, and the conditions under which the operation matters. An agent has everything needed 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 schema provides only a bare integer 'channel' with no description (0% coverage). The description compensates by explaining that 'channel selects which channel's SCPI prefix issues the command, but both generator channels are affected.' This prevents a critical misunderstanding. It could still be more explicit about valid channel values, but the default in the schema covers one gap.

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 opening sentence states a specific action: 'Align the phase of both function generator channels to their preset settings.' It clearly distinguishes this from siblings like configure_afg or get_afg_state by focusing on a dedicated sync operation that affects both channels.

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 on when the action has a visible effect: only when channel frequencies are identical or integer multiples. It also clarifies that amplitude and output state are untouched, which helps an agent decide when this tool is appropriate. It does not explicitly name alternative tools, losing the fifth point.

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