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

With no annotations, the description carries the full burden and does well: it discloses the return content, that bandwidth is auto-estimated when omitted, and the VFO side-effect (SDR++ retunes and restores the original VFO unless tune_vfo=True). This is genuinely useful state-change disclosure, though permissions/rate behavior is not addressed.

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?

Dense but front-loaded: capability list first, then return values, then parameter/side-effect caveats. Every sentence adds signal; nothing is 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?

No output schema or annotations exist, so the description must stand alone, and it covers capabilities, outputs, and the VFO behavior well. The gaps are the undocumented frequency format and seconds parameter, which an agent would need to call with confidence.

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 compensate. It explains bandwidth_hz (estimated if omitted) and tune_vfo (leaves VFO on the signal for listening), covering two of four params, but says nothing about the required frequency format or the meaning of seconds (default 2). Partial compensation only.

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 (measure) and resource (a signal) and enumerates concrete measurements — occupied bandwidth, FM deviation, symbol rate, CTCSS tones — that make its role unambiguous against siblings like sdr_tune or spectrum_snapshot. It also names what it returns (modulation guesses, band-plan context, waterfall 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?

The framing 'to help identify it' implies the context (signal investigation), but the description never says when to choose this over nearby siblings such as identify_frequency, spectrum_snapshot, or band_sweep. No explicit exclusions or alternative routing is given.

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

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

With no annotations, the description carries the full burden and does well: it discloses the side effect that it moves the user's SDR++ view, that the original VFO frequency is restored afterwards, and what is returned (detected signals plus a combined spectrum image). It omits expected duration/blocking behavior and any interference with concurrent recording, keeping it below 5.

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

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

Three tight sentences, front-loaded with the core action and scope, then returns, then the side-effect note. No filler or repetition.

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

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

For a six-parameter tool with no annotations, no output schema, and 0% schema coverage, the description leaves too much unsaid: an agent cannot determine acceptable start/stop values or units, sweep duration implications of dwell_s/top, or detection sensitivity from threshold_db. Purpose and one side effect are covered, but the invocation-critical detail 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?

All six parameters have 0% schema description coverage, so the description must compensate and largely does not: start/stop units and format (string), dwell_s, fft_size, threshold_db, and the meaning of 'top' are never explained. 'Retuning in steps' hints loosely at the stepping parameters but provides no usable semantics.

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 ('Sweep a frequency range ... by retuning SDR++ in steps') and clarifies the scope that separates it from siblings: a range wider than the SDR's bandwidth, unlike the single-bandwidth spectrum_snapshot or single-frequency sdr_tune.

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 'wider than the SDR's bandwidth' implicitly tells the agent when this tool applies versus a single snapshot or a tune. It does not explicitly name the alternatives (spectrum_snapshot, sdr_tune) or state exclusions, so it falls short of 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 the description carries the full load, and it does disclose two genuinely useful traits: that long captures block for `seconds`, and a privacy caveat about personal information in pager traffic. It stops short of stating hardware/permission requirements or failure modes.

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?

Front-loaded with the core action, then bulleted decoder options, then the two caveats. Efficient, though the mid-sentence line break around the decoder list makes it slightly awkward 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 4-param, annotation-free tool with no output schema, the description covers decoders, duration, and privacy but leaves the frequency format (units/expected string) and bandwidth semantics unexplained, and gives no sense of what a successful decode returns.

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

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

Schema coverage is 0%, so the description must compensate. It meaningfully documents `decoder` (enumerating valid values) and gives `seconds` behavioral meaning (blocking duration), but `frequency` and `bandwidth_hz` get no format, unit, or range guidance. Partial compensation only.

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 ('capture and decode digital transmissions') and enumerates concrete decoder families (multimon-ng pager/POCSAG/FLEX/APRS/DTMF, rtl_433 ISM sensors), which distinguishes it from capture-only siblings like record_iq/record_audio and from analyze_signal. It does not explicitly name a sibling it is not, so it lands just below the top band.

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 gives practical routing hints ('rtl_433: ism -- run on captured IQ'), implying which decoder applies to which target, but never states when to choose decode over analyze_signal, record_iq, or identify_frequency, nor any prerequisites or exclusions. Usage is implied rather than prescribed.

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

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

No annotations are provided, so the description carries the full behavioral burden. It omits whether deletion is permanent/irreversible, whether it requires ownership or elevated permissions, and what happens to related data - all critical for a destructive operation.

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

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

A single short sentence that is front-loaded with the verb and resource. Nothing is wasted, though the extreme brevity is a consequence of under-specification rather than disciplined editing.

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

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

An output schema exists so return values need not be described, and complexity is low (one param). However, for a destructive tool with zero annotations, the absence of any permanence or permission context leaves a meaningful gap.

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

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

Schema coverage for entry_id is 0%, so the description's 'by id' is the only clue that the integer parameter is the entry identifier. It adds minimal but real meaning; it does not clarify format, range, or lookup behavior.

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 (Delete) and resource (logbook entry) plus the identification method (by id). It is unambiguous on its own, though it does nothing to differentiate itself from sibling logging tools like log_signal or search_log.

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 indication of when to use this versus alternatives, nor any prerequisite such as where the entry_id comes from (e.g., search_log). The agent is left to infer the retrieval workflow entirely.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses that this is a write operation, that it requires SDR++ to be closed, and that the previous bookmarks file is backed up (i.e., the existing data is replaced but recoverable). It does not describe failure behavior if SDR++ is open or where the backup lives, but the key mutation semantics are surfaced.

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 tight sentences, front-loaded with the action and immediately followed by the operational constraints. No filler or redundant restatement of the tool name.

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

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

An output schema exists, so return values need not be explained, and the description covers the precondition and backup behavior. It remains silent on the list_name parameter and on what happens when the 'SDR++ closed' precondition is violated, leaving small but real gaps for a mutation 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 single parameter list_name has 0% schema description coverage and a default of 'SDR Log', yet the description never mentions it. The phrase 'as a bookmark list' hints that a named list is produced, but it does not explain what list_name controls or how the default is used, so the description fails to compensate for the schema 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 description gives a specific verb and resource: writing the logbook into SDR++'s Frequency Manager as a bookmark list, with a clarifying note that it appears on the waterfall. That is clear enough to distinguish it from every sibling, though it never explicitly contrasts itself with alternatives (none of which export, so differentiation is implicit rather than stated).

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

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

It states one important precondition (SDR++ must be closed), which is real usage guidance, but it never says when to choose this tool versus other log-related siblings like search_log or log_signal. Usage is implied rather than framed as a when-to-use rule.

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 does disclose two meaningful traits: it is a pure lookup requiring no radio hardware, and its answers are limited to US/FCC and ITU Region 2 allocations. It says nothing about behavior on out-of-band or malformed input, or about lookup latency/coverage limits.

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 compact sentences, no filler, with the resource and scope front-loaded before the caveat. Every clause adds 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?

No output schema exists, and the description does partially characterize the return ('which allocation a frequency falls in and which well-known channels/services are nearby'), plus it fixes the regulatory scope. However, with 0% parameter documentation the description leaves the required 'frequency' format and the role of 'window_khz' entirely unaddressed, which is the main completeness gap.

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

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

Schema description coverage is 0%: 'frequency' is a bare string with no stated unit or format (MHz? Hz? '146.520'?), and 'window_khz' has only a default of 50 with no explanation of what window it governs. The description never compensates for either gap, so an agent must guess the input format for the required parameter.

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

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

Uses a specific verb+resource ('Band-plan lookup... which allocation a frequency falls in') and scopes it to a defined regulatory regime (US/FCC, ITU Region 2). The added clause 'No radio access needed' cleanly separates it from hardware-touching siblings like sdr_tune, band_sweep, and spectrum_snapshot.

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 radio access needed' implies the main condition that selects this tool over the sdr_* and sweep tools (offline/regulatory question vs. live capture), but it never states that explicitly or names an alternative. No guidance on when this is the wrong choice versus band_sweep or spectrum_snapshot.

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 for what is clearly a write/persistence operation. It never states whether entries append, overwrite, deduplicate, require permissions, or what the save returns. The only behavioral content is the confidence vocabulary (confirmed/likely/guess).

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

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

Two short, front-loaded sentences with no filler; the action leads and the confidence vocabulary follows. The second fragment is telegraphic but still earns its place as enum-like guidance.

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 an 8-parameter mutation tool with no annotations, no output schema, and zero schema description coverage, the description is far too thin. It establishes intent but leaves parameter formats, write semantics, and result behavior unspecified.

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

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

Schema description coverage is 0% across 8 parameters, so the description must compensate, but it clarifies only 'confidence' (confirmed/likely/guess) — a genuinely useful addition since the schema defines it as a bare string with no enum. The other seven parameters, including required 'frequency' and 'label' and ambiguous ones like 'mode', 'files', 'bandwidth_hz', and 'identification', get no meaning or format 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 gives a specific verb and resource: 'Save ... signal to the logbook,' which plainly distinguishes it from sibling log tools like search_log and delete_log_entry. It also covers the identified-or-mystery case, but does not explicitly name or contrast 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?

There is no statement of when to log versus running identify_frequency or analyze_signal first, nor any exclusion or alternative. The phrase 'identified (or mystery)' hints that both confirmed and unknown signals are valid inputs, but no operational guidance is given.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that output is a saved WAV and that it runs independently of SDR++'s own audio stream, but omits where the file is written, whether the call blocks for the recording duration, and any permission/concurrency constraints.

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 core action and followed by the differentiator and the mode vocabulary. Every clause earns its place with no padding.

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

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

For a 5-parameter file-producing tool with no annotations and no output schema, the description covers the artifact and modes but leaves the required frequency format, file destination, and blocking behavior unspecified. 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?

Schema description coverage is 0% and there are no enums, so the schema explains nothing. The description compensates by enumerating valid mode values (FM/NFM, WFM, AM, USB, LSB, CW), which is genuinely valuable, but leaves frequency format, seconds, audio_rate, and bandwidth_hz entirely unexplained.

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

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

States a specific compound action (demodulate a frequency and save a WAV) and the output artifact, so an agent knows exactly what it does. It does not, however, name or distinguish itself from the closely related sibling record_iq, which records raw IQ rather than demodulated audio.

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 parenthetical 'so the user can keep listening elsewhere' implies one use scenario, but there is no explicit guidance on when to choose this over record_iq, decode, or sdr_tune, nor any stated prerequisites (e.g. SDR must be running/tuned).

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. It usefully discloses format options, that output sample rate is exactly bandwidth_hz, and that the filename carries frequency and rate, but it omits file location, overwrite behavior, permissions, and any return or completion details.

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 compact sentences with the purpose front-loaded and no obvious filler. The format and default guidance are integrated efficiently, though the shorthand 'freq' and 'fmt_' keeps it slightly less polished.

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-annotation, no-output-schema recording tool with four parameters, the description is incomplete. It omits the seconds parameter, does not specify the frequency syntax, and does not say where files are saved, leaving the agent with important gaps 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?

Schema description coverage is 0%, so the description must compensate. It explains fmt_ values and the bandwidth_hz/sample-rate relationship, but it does not describe the required frequency format or mention the seconds parameter at all.

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 gives a specific verb and resource: 'Save channelised IQ around a frequency.' It clearly distinguishes IQ capture from audio recording and signal analysis, but it does not explicitly name or contrast itself with any sibling 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?

It implies usage through format guidance, noting that 'cu8' suits rtl_433 / most tools and that the 250 kS/s default suits rtl_433. However, it never states when to choose this tool over alternatives such as record_audio, spectrum_snapshot, or analyze_signal.

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 discloses idempotent-ish behavior (won't start if already running) and what autostart does, but says nothing about what happens when the app is already up (error vs. no-op), permission requirements, or failure modes.

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 with no waste; the primary action is front-loaded and the parameter caveat is parenthetical rather than buried.

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

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

For a one-optional-parameter launch tool with an output schema present, the description covers the essential action and the one parameter's effect. Only the already-running case is left unstated, a minor gap.

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

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

Schema coverage is 0% and the schema only labels the boolean "Autostart", so the description must supply meaning. It does: autostart=True also starts the SDR source, explaining the parameter's real effect beyond a bare boolean.

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?

Names a specific verb and resource ("Start SDR++") and a clear scope, so an agent can tell it apart from sdr_status or sdr_power at a glance. It stops short of explicitly contrasting with those siblings, but 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?

"if it isn't running" implies the operating condition (only launch when the app is down), which is useful guidance, but it names no alternatives and gives no prerequisites or fallback path if the launch fails.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the core semantic of the boolean (start vs stop) via the play/stop analogy, but says nothing about permissions, whether stopping is reversible, error behavior, or the runtime state implications of toggling the source.

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 wastes nothing and places the action and its parameter semantics before the explanatory parenthetical.

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

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

For a one-parameter toggle with an output schema available for return values, the description is nearly sufficient. The only shortfall is the absence of any behavioral or usage context beyond the bare operation.

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

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

Schema coverage is 0% and the single 'on' parameter has only a type, so the description must compensate. It does so fully by mapping on=True to start and on=False to stop, which is the essential meaning an agent needs.

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 ('start/stop the SDR source in SDR++') and clarifies the operation with the '(the play/stop button)' analogy. It distinguishes itself from sdr_launch implicitly by implying toggling of an already-available source, though it never names a sibling explicitly.

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 start/stop framing implies when to use it, but there is no explicit guidance on when to prefer this over sdr_launch or how it interacts with sdr_status. Usage is left to inference rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only operation by 'Report' and lists what information is returned, but does not explicitly state that it has no side effects, requires no special permissions, or has any rate limits.

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 begins with the core action and then enumerates the relevant state fields. Every element earns its place; there is 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?

No output schema exists, so the description compensates by enumerating the returned state fields. It does not specify the output format or error behavior, but for a zero-parameter status tool this is fairly 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 takes zero parameters, so the baseline score is 4. There are no parameter semantics to add beyond what the empty schema already conveys.

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 'Report' and resource 'SDR++ state', and enumerates the exact state fields. However, it does not explicitly differentiate from sibling tools (e.g., sdr_tune, sdr_power) beyond being the only status-reporting 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?

No guidance on when to use this tool versus alternatives. It does not state prerequisites, exclusions, or that it should be called before tuning or after launching. Usage is only implied by the purpose.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing: no mention of permissions, whether retuning interrupts active recording/decoding, or persistence of settings. It only lists mode values and bandwidth examples.

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?

Purpose is front-loaded, followed by the mode enumeration and bandwidth examples. Two dense sentences with no filler, though the parenthetical mode/bandwidth lists are packed together.

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, no annotations, and 0% schema description coverage, the description covers mode and bandwidth adequately but omits the format/units for the one required parameter ('frequency') and any behavioral or failure context. Adequate but with clear gaps for a core tuning 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 coverage is 0%, so the description must compensate, and it largely does: it enumerates mode values (FM=NFM, WFM, AM, DSB, USB, LSB, CW, RAW) and gives concrete bandwidth_hz examples tied to each mode. It never explains the required 'frequency' parameter's format or units, leaving a notable 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?

States a specific verb ('Tune') and resource ('SDR++'s Radio VFO') plus the outcome ('so the user hears the frequency'). The action is unambiguous and distinct from siblings like band_sweep or spectrum_snapshot, though it doesn't explicitly name those 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?

No explicit when-to-use or when-not-to-use guidance, and no alternatives are named against a large sibling set (identify_frequency, analyze_signal, band_sweep, record_audio). The phrase 'so the user hears the frequency' hints at intent but gives no conditions for choosing this tool over others.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether text matching is case-insensitive/substring, how start/stop are interpreted, whether both filters combine with AND, or how results are ordered; only the existence of an output schema spares it from explaining return values.

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

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

A single front-loaded sentence with no filler; the filter dimensions come before any elaboration. The brevity is appropriate in form even though the content is thin.

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

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

For a 4-parameter search tool with zero schema descriptions, the description leaves matching semantics, frequency-range format, limit/ordering behavior, and empty-result handling undefined. The presence of an output schema only offsets the return-value gap.

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

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

Schema description coverage is 0% for 4 parameters, so the description must compensate. It loosely maps to text and to start/stop via 'frequency range', but never explains that start/stop are frequency strings, what the string format is, or what 'limit' (default 50) controls.

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

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

States a specific verb ('Search') and resource ('the logbook') plus the two filter dimensions (text, frequency range), which separates it from log_signal and delete_log_entry. It is clear but minimal, with no explicit naming of the sibling it complements.

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 retrieval from the logbook but never says when to prefer this over log_signal, delete_log_entry, or export_bookmarks, nor any prerequisites. An agent must infer the use case entirely.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses that 'max-hold' detection means short bursts count and defines 'duty' output semantics, but leaves out permission needs, rate limits, the meaning of the top/seconds/fft_size/threshold_db parameters, and any failure modes. Valuable domain details are present 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?

Two compact sentences front-load the purpose and outputs, with the optional retune and the duty definition following. No fluff, though the duty definition could be integrated more smoothly into the first sentence.

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

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

For a 5-parameter tool with no annotations, no output schema, and 0% schema coverage, the description is too thin. It should clarify what seconds, top, fft_size, and threshold_db control, and perhaps what the table columns are. As it stands, an agent cannot confidently choose values or 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?

Schema description coverage is 0%, so five parameters are undocumented in both schema and description. The description only tangentially mentions 'frequency' (optional retune) and 'duty' (an output term, not a parameter). It does not explain top, seconds, fft_size, or threshold_db at all, falling well short of compensating for the coverage 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 description states a specific verb and resource ('Capture the full SDR++ passband, detect signals') and describes the two outputs (table + image). It is clearly distinct from siblings like band_sweep or analyze_signal, though it doesn't name any sibling explicitly.

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

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

No guidance on when to use this versus band_sweep (which likely sweeps multiple bands) or analyze_signal. The optional retune hint is the only usage cue, and it doesn't explain why or when to retune first.

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