Transmit a generated waveform

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

Annotations already mark destructiveHint=true and readOnlyHint=false, but the description adds substantial behavioral context: the transmission is always cyclic, it repeats until sdr_tx_disable is called, it needs SDR_MCP_ALLOW_TX=1, and it should only be used into a dummy load or licensed frequencies. This goes well beyond annotation signals and does not contradict them.

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 terse, front-loaded sentences: core purpose first, then lifecycle and safety. Every sentence earns its place and there is no filler.

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

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

Given the annotations and output schema, the description covers the important lifecycle behavior, environment requirement, and safety constraint. It lacks only an explicit note about when to prefer sibling tools like sdr_tx_tone or sdr_transmit_iq, 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?

The description adds useful meaning to the shape parameter by explaining the waveform types and their test purpose, and the schema already covers bandwidth_hz and tx_gain_db in detail. However, it provides no additional guidance for lo_hz, scale, or samples beyond their titles and defaults, so the coverage is adequate but not exemplary.

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 operation ('Synthesise and transmit a test signal') and resource ('without needing an IQ file'), and lists the four waveform shapes. This distinguishes it from sdr_transmit_iq, but it does not explicitly separate it from the sibling sdr_tx_tone when the user only needs a single tone.

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 provides clear conditions for use: generated test waveforms, no IQ file, always cyclic until sdr_tx_disable is called, and requires SDR_MCP_ALLOW_TX=1. It does not explicitly route the agent to sdr_tx_tone for simple tones or sdr_transmit_iq for IQ-file playback, so it narrowly misses a 5.

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