Skip to main content
Glama

MagicON RF Design Engines

by io.github.magiccadai
OverviewDiscussionsAdmin

Design a transmit chain

design_rf_chain
Read-only

Design a complete RF transmitter chain with the convergent orchestrator: selects the driver, PA, filter, and connector (the signal source is the user's input power by default — no VCO unless one is explicitly the generator), matches drive power between stages, inserts a pre-driver or attenuator when needed to reach the target output power, and returns the BOM plus a convergence summary (achieved vs target output). When the BOM's pricingCoverage is 'partial', total_usd is a subtotal of pricedLines of totalLines parts: never call it the total, and state no figure for the unpriced parts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionNoTarget market / regulatory region (e.g. 'USA', 'Europe', 'Global'). Set it when the user states their market so the design-time power clamp can enforce the right limits — an EU/Europe design with a known antenna gain is held to the ETSI e.i.r.p. limit (EN 300 328 / EN 301 893), not just the FCC ISM conducted limit.
bandwidthNoSignal bandwidth in MHz (optional).
frequencyYesOperating frequency in GHz (scalar).
applicationNoApplication context (e.g. satcom_c_band, 5g_cellular, wifi_wlan). Defaults to 'general'. For a drone, send the most specific link the user names: drones_digital_video (digital/OFDM video: the PA is judged on LINEAR power), drones_analog_video (analog FM video: saturated power, plus the FCC 15.249 licence note) or drones_control_telemetry; plain 'drones' means the modulation is unknown (the PA is judged on P1dB).
user_requestNoThe 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.
input_power_dbmNoThe power the user's radio or signal source delivers into the chain, in dBm (e.g. 0 or -10), ONLY when the user states it. It is the INPUT, never the target output. Omit it when not stated — the result then says which level was assumed.
protected_bandsNoBands another radio on the same platform listens on (e.g. a drone's GNSS receiver), checked against the filters after the PA. Only when the user asks to protect a band. A cited ITU RNSS band is named by source ('table:rnss_1164_1215', 'table:rnss_1215_1240', 'table:rnss_1240_1300', 'table:rnss_1559_1610', 'table:rnss_5010_5030') and needs no edges; a band the user states uses source 'user' with name, fLowHz and fHighHz. requiredRejectionDb ONLY when the user states it — it narrows the filter choice. Never invent an edge or a requirement.
antenna_gain_dbiNoAntenna gain in dBi. Set it when the user states their antenna so an EU/ETSI design can enforce the e.i.r.p. limit at the real gain (conducted ceiling = e.i.r.p. limit − antenna gain); without it the ETSI clamp does NOT engage (no 0 dBi assumption is made in the design).
harmonic_2nd_dbcNoThe 2nd-harmonic limit at the output in dBc (a negative number, e.g. -40), ONLY when the user states one. The filters after the PA are then chosen and judged against it. Never guess it and never derive it from a regulation.
hopping_channelsNoDrone control/telemetry only: the number of hopping channels the link uses, WHEN THE USER STATES IT. 50 or more lifts the design ceiling from FCC 15.247(b)(2)'s 24 dBm to 30 dBm. Never guess it.
digital_modulationNoDrone control/telemetry only: true WHEN THE USER STATES the link uses digital modulation (FCC 15.247(b)(3)), which lifts the 24 dBm ceiling to 30 dBm. Never guess it.
input_voltage_max_vNoHighest voltage the board supply reaches, in volts (optional; e.g. a fully charged battery). Only when the user STATES it. Pair with input_voltage_min_v.
input_voltage_min_vNoLowest voltage the board supply reaches, in volts (optional; e.g. a battery at cut-off). Only when the user STATES it — never derive it from a cell count or chemistry. Give it together with input_voltage_max_v and a main_board_input_voltage inside the two; the power tree then picks regulators that work across the whole span.
target_output_powerYesTarget transmitter output power in dBm.
transmit_bias_pulsedNoPulsed designs only: true when the user says the 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.
internally_matched_onlyNoPrefer internally 50-ohm matched parts (optional). A preference, not a filter: an unmatched PA can still win on score, and the result's warnings then say so.
main_board_input_voltageNoBoard 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 28 V or 48 V bench/battery input.
transmit_duty_cycle_percentNoTransmit duty cycle in percent for a PULSED system (radar). Default 100 = continuous wave (CW). Set it to the real duty (e.g. 10 for a 10% radar) so thermal, stress, and compliance use AVERAGE power, not peak.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. Beyond that the description adds real behavioral value: the orchestration pipeline, the convergence summary returned, and an explicit reporting rule for partial pricingCoverage ('total_usd is a subtotal... never call it the total'). It stops short of noting failure/non-convergence behavior or limits, so 4 rather than 5.

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?

Purpose and scope are front-loaded in the first sentence, and the pricingCoverage caveat is a distinct, well-placed second sentence. The first sentence is long and clause-heavy but every clause (component selection, drive matching, pre-driver/attenuator, BOM/convergence return) earns its place.

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

Completeness4/5

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

For a complex 18-parameter design tool with no output schema, the description explains what is returned (BOM + convergence summary) and how to report it, which is the key missing piece since there is no output schema. Combined with the 100%-covered schema, this is nearly complete; only usage routing and converged/not-converged handling are left implicit.

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

Parameters3/5

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

Schema description coverage is 100% across 18 parameters, so the schema carries the parameter burden and the baseline is 3. The description adds only one meaningful mapping — that input power is the default signal source and no VCO is selected unless the user explicitly names one — which lightly clarifies input_power_dbm but nothing else.

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 (design) and resource (complete RF transmitter chain) and enumerates exactly what it does: selects driver, PA, filter and connector, matches drive power, inserts pre-driver/attenuator, and returns a BOM plus convergence summary. The 'transmitter' scope cleanly separates it from the sibling design_rf_receiver without needing to name it.

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

Usage Guidelines3/5

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

Usage context is implied rather than stated: the agent can infer this is the transmit-chain design path, and the description hints at the input-power-as-source convention, but it never states when to prefer this over design_rf_receiver or design_tr_module, nor any prerequisites. Adequate but with clear gaps.

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 toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources