MagicON RF Design Engines

Design a T/R module

design_tr_module

Read-only

Design a T/R (transmit/receive) module that shares ONE antenna between a transmitter and a receiver. Designs both chains through the existing engines, selects the shared front end (a T/R switch, or a circulator with a receive-path limiter), and returns four safety budgets: TX-to-RX isolation against the receiver's damage limit, the receive window left after switching and limiter recovery (with the blind range: the closest echo the receiver can hear), limiter leakage driving the LNA into compression, and transmit power against each part's survivability rating. Pass frequencyGhz and targetOutputPowerDbm to design one; pass txPeakPowerDbm and isolationDb only to check a front end the user already described with their own numbers. For a transmitter alone, use design_rf_chain instead. For a receiver alone, use design_rf_receiver instead.

Input Schema

TableJSON Schema

Name	Required	Description
`prfHz`	No	Pulse repetition frequency in Hz, for a pulsed system. Omit and the switching/blanking budget is absent, not assumed.
`topology`	No	Shared-antenna element. Omit to use tr_switch, which the result discloses. Choose circulator_limiter for high transmit power — if the stress budget reports over_limit for a switch, re-run with this. switch_and_circulator belongs to architecture array_element only (and is its only topology); any other pairing is refused.
`application`	No	Application context, the same label design_rf_chain takes (e.g. drones, marine_radar, wifi_wlan). Every part is scored for it; free text is resolved to the nearest known label, and one that cannot be resolved is scored as 'general' with a warning saying so. Omit for 'general'.
`bandwidthHz`	No	Receiver noise bandwidth in Hz.
`isolationDb`	No	Transmit-to-receive isolation in dB, for the explicit-inputs path only.
`pulseWidthS`	No	Transmit pulse width in seconds (e.g. 1e-6).
`architecture`	No	front_end_only for a radio built on an integrated transceiver (drones): selects only limiter, preselector and LNA, ending at the transceiver input. array_element for ONE element of a phased array, beamformer port to antenna port: phase shifter + step attenuator shared by both paths, a low-power T/R switch and a circulator; requires beamformerDriveDbm. Omit for a full superheterodyne.
`frequencyGhz`	No	Operating frequency in GHz (e.g. 9.4 for X-band).
`user_request`	No	The end user's own words that prompted this call, verbatim. Used to verify that the figures you pass were stated by your user rather than inferred. Omit it and the results will be labelled caller-asserted.
`antennaFilter`	No	array_element only: true to add a shared bandpass filter between the circulator and the antenna, charged to both paths. Off unless the user asks for it.
`requiredSnrDb`	No	SNR needed at the demodulator, in dB.
`beamformerNfDb`	No	array_element only: the beamformer's own noise figure behind the common leg, in dB. Omit it and the system noise figure at the beamformer port is withheld.
`txPeakPowerDbm`	No	Peak transmit power AT THE ANTENNA PORT, in dBm. Pass this ONLY to check a front end the user already has — it skips design entirely. To design a module, pass targetOutputPowerDbm instead.
`transceiverNfDb`	No	The transceiver's own noise figure in dB, front_end_only only. Omit it and system NF, MDS and sensitivity are withheld, never assumed.
`beamformerDriveDbm`	No	array_element only: the input power at the beamformer port, in dBm, as the user stated it. Required for an array element — never assumed; the tool refuses and names it when absent.
`minDetectionRangeM`	No	The closest target the user must detect, in metres, when they state one. Checked against the blind range (pulse width + switch back to receive + limiter recovery). Needs prfHz and pulseWidthS; omit when not stated — no requirement is assumed.
`transmitBiasPulsed`	No	Pulsed designs only: true when the user says the transmit amplifier bias (gate or drain) is switched off between pulses, false when it stays on. Omit when not stated — the idle draw between pulses is then counted as heat, and the thermal disclosures say so.
`antennaReturnLossDb`	No	Antenna return loss in dB. Without it the antenna-mismatch leakage path assumes a 1.5:1 VSWR (13.98 dB) and says so.
`maxTxGainFlatnessDb`	No	The user's transmit gain flatness requirement across the band, in dB. Not computed; reported as not evaluated with the reason. Omit when not stated.
`minTxToRxIsolationDb`	No	The user's required TX-to-RX isolation in dB (e.g. 40 for '> 40 dB'). Judged against the shared part's own isolation and reported under requirements. Not the same as isolationDb. Omit when not stated.
`targetOutputPowerDbm`	No	Transmit output power the chain is designed to, in dBm (20 W = 43 dBm). Required — every safety budget is measured against it and no default is substituted.
`maxUnblankingRecoveryS`	No	The user's maximum unblanking (receiver) recovery time in seconds (e.g. 100e-9 for '< 100 ns'). Judged against the switch back to receive plus limiter recovery. Omit when not stated.
`maxPulseToPulsePhaseDeg`	No	The user's pulse-to-pulse phase stability requirement in degrees. Not computed; reported as not evaluated with the reason. Omit when not stated.
`main_board_input_voltage`	No	Board DC supply voltage in volts that the power tree steps down/up to the per-component rails (optional; defaults to 12 V). Set it when the user states their supply rail, e.g. a 14.8 V 4S battery or a 28 V bench input. Same meaning as on design_rf_chain.
`transmitDutyCyclePercent`	No	Transmit duty cycle in percent (e.g. 10 for a 10% pulsed radar). Selects each part's PULSED survivability rating instead of its CW rating, which for a limiter is commonly 7 dB higher. Omit for continuous wave — the CW rating is then used, and a part declaring no pulsed rating keeps its CW one with that substitution disclosed. Redundant if prfHz and pulseWidthS are both given, which imply it.
`maxPulseToPulseAmplitudeDb`	No	The user's pulse-to-pulse amplitude stability requirement in dB. Not computed; reported as not evaluated with the reason. Omit when not stated.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 8, 2026

addedInput schema / properties / maxPulseToPulseAmplitudeDb

Added value: +{
+  "description": "The user's pulse-to-pulse amplitude stability requirement in dB. Not computed; reported as not evaluated with the reason. Omit when not stated.",
+  "type": "number"
+}

addedInput schema / properties / maxPulseToPulsePhaseDeg

Added value: +{
+  "description": "The user's pulse-to-pulse phase stability requirement in degrees. Not computed; reported as not evaluated with the reason. Omit when not stated.",
+  "type": "number"
+}

addedInput schema / properties / maxTxGainFlatnessDb

Added value: +{
+  "description": "The user's transmit gain flatness requirement across the band, in dB. Not computed; reported as not evaluated with the reason. Omit when not stated.",
+  "type": "number"
+}

addedInput schema / properties / maxUnblankingRecoveryS

Added value: +{
+  "description": "The user's maximum unblanking (receiver) recovery time in seconds (e.g. 100e-9 for '< 100 ns'). Judged against the switch back to receive plus limiter recovery. Omit when not stated.",
+  "type": "number"
+}

addedInput schema / properties / minDetectionRangeM

Added value: +{
+  "description": "The closest target the user must detect, in metres, when they state one. Checked against the blind range (pulse width + switch back to receive + limiter recovery). Needs prfHz and pulseWidthS; omit when not stated — no requirement is assumed.",
+  "type": "number"
+}

addedInput schema / properties / minTxToRxIsolationDb

Added value: +{
+  "description": "The user's required TX-to-RX isolation in dB (e.g. 40 for '> 40 dB'). Judged against the shared part's own isolation and reported under requirements. Not the same as isolationDb. Omit when not stated.",
+  "type": "number"
+}

Changed1 schema field changedOct 4, 2026

changedInput schema / properties / antennaReturnLossDb / description

Previous value: -"Antenna return loss in dB. Without it the antenna-mismatch leakage path is excluded and disclosed."New value: +"Antenna return loss in dB. Without it the antenna-mismatch leakage path assumes a 1.5:1 VSWR (13.98 dB) and says so."

Changed1 schema field changedOct 4, 2026
- addedInput schema / properties / user_request / maxLength
```
Added value: +4000
```
First observedOct 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true and openWorldHint=false, consistent with a design/compute tool. Beyond that, the description discloses refusal behavior ('any other pairing is refused'), defaults-vs-withholding semantics ('the switching/blanking budget is absent, not assumed'), and scoring fallbacks, which are genuine behavioral facts the annotations cannot carry.

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

Conciseness4/5

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

The core paragraph is dense but front-loaded: purpose and the two usage paths come first, safety budgets next, alternatives last. Every sentence earns its place, though the run-on enumeration of budgets and the very long single paragraph slightly reduce scannability.

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 26-parameter tool with no output schema and no formally required parameters, the description supplies what an agent needs: the two invocation modes, the design outcome (four safety budgets), what is withheld when inputs are omitted, and refusal conditions. Nothing essential is missing.

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 coverage is 100%, so the schema already documents each of the 26 parameters, making 3 the baseline. The description still adds cross-parameter routing logic the schema cannot express: which inputs select the design path vs. the explicit-inputs path, and that omitted inputs are withheld rather than defaulted. That is meaningful added meaning, though most per-parameter detail remains in the schema.

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

Purpose5/5

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

States a specific verb+resource ('Design a T/R (transmit/receive) module that shares ONE antenna'), names the shared-antenna front-end choices, and enumerates the four safety budgets returned. It explicitly contrasts itself with design_rf_chain (transmitter alone) and design_rf_receiver (receiver alone), so an agent can route correctly without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use routing: 'Pass frequencyGhz and targetOutputPowerDbm to design one; pass txPeakPowerDbm and isolationDb only to check a front end the user already described with their own numbers.' It also names the alternatives (design_rf_chain, design_rf_receiver) and their selection condition, leaving nothing to inference.

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

All MagicON RF Design Engines tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?