rp_rx_connect

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

Beyond the annotations, the description discloses important behavior: it resets RX config/FIFO, requires exclusive app ownership, closing resets tuning/rate, and there is no server ACK/readback. These are meaningful operational caveats for a destructive, non-idempotent tool, though 'RP_ALLOW_RX' could be explained more precisely.

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 text is short, front-loaded, and mostly free of waste. The fragmentary style is dense but generally earns its place by packing in lifecycle and safety 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?

Given the annotations and an output schema, the description covers the major behavioral risks: destructive reset behavior, exclusivity, live-mode gating, and lack of readback. The main gap is that frequency_hz is never addressed, but overall it is sufficient for an agent to call the tool cautiously.

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 helpfully enumerates valid sample_rate values, but it omits frequency_hz entirely and only indirectly gestures at acknowledge_side_effects via 'acknowledgement', leaving two of three parameters under-explained.

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 ('Open RX') and clarifies that it resets RX config/FIFO. It is distinguishable from siblings like rp_rx_disconnect and rp_rx_read, though the phrase 'RX only' is terse and could be clearer about whether it means receive-only rather than only the RX subsystem.

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 prerequisites for opening RX in live mode ('RP_ALLOW_RX and acknowledgement') and notes exclusive app ownership. However, it does not explicitly say when to use this tool versus rp_connection_probe, rp_connection_status, or rp_rx_read, leaving usage largely implied.

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