fishball-sdr-mcp

Transmit an IQ file

sdr_transmit_iq

Destructive

Transmit IQ waveform files through an SDR, supporting int16, complex64, WAV formats, and optional cyclic repeat for continuous output.

Instructions

Transmit an arbitrary IQ waveform read from a file on this machine.

Formats: 'int16' interleaved little-endian I,Q (what sdr_capture_iq writes), 'complex64' (what a GNU Radio file sink writes), 'wav' (2 channels as I and Q), or 'auto' to infer from the extension.

With cyclic=true the buffer REPEATS FOREVER and transmission continues after this call returns - use sdr_tx_disable to stop. With cyclic=false the buffer plays once. Requires SDR_MCP_ALLOW_TX=1. Only transmit into a dummy load or on frequencies you are licensed to use.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the IQ file
`lo_hz`	Yes	TX local oscillator in Hz
`scale`	No	Peak amplitude, 0 to 1
`cyclic`	No	Repeat forever (true) or play once (false)
`tx_gain_db`	No	TX attenuation in dB; 0 is full output. Must be set, because the firmware idles at maximum attenuation.
`file_format`	No	Input sample format	auto
`max_samples`	No
`sample_rate_hz`	No	TX sample rate; leave unset to keep the current one
`response_format`	No	markdown for reading, json for structured output	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 14, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description substantially expands on the annotations: it discloses that cyclic=true repeats forever and transmission outlives the call, names the stop tool, and adds the environment variable requirement plus the dummy-load/licensed-frequency safety constraint. With destructiveHint and openWorldHint already present, this is strong added behavioral context.

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

Conciseness5/5

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

The description is dense but well-structured: purpose first, then formats, then cyclic behavior, then safety and prerequisites. Every sentence earns its place, and there is no filler or restatement of schema defaults.

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

Completeness5/5

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

For a 9-parameter transmit tool with an output schema and annotations, the description covers the critical non-obvious details: file formats, repeat-forever semantics, how to stop, the required allow flag, and legal operation. Nothing essential is missing for an agent to select and safely invoke the tool.

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

Parameters4/5

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

Schema description coverage is 89%, so the baseline is 3, but the description adds genuine meaning for file_format by explaining exactly what int16, complex64, and wav represent and where they come from. It also clarifies the cyclic parameter's real-world behavior. The only gap is that max_samples is not semantically expanded, but the schema already carries most of the load.

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

Purpose4/5

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

The description clearly states a specific verb and resource: 'Transmit an arbitrary IQ waveform read from a file on this machine.' The file-based focus distinguishes it from tone/waveform siblings in practice, but it does not explicitly name or contrast those alternatives, so it stops short of a 5.

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

Usage Guidelines4/5

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

It gives clear usage context: use this tool to transmit an IQ file, with format inference options, cyclic repeat behavior, the stop mechanism via sdr_tx_disable, and the SDR_MCP_ALLOW_TX=1 requirement. It does not explicitly spell out when to prefer sdr_tx_tone or sdr_transmit_waveform, so it lacks the full alternatives guidance needed for a 5.

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

Deploy Server