RF module design: transmit, receive and T/R chains, stackup, thermal, PDN and compliance.
Scored across 9 tools
Each tool targets a distinct concern: TX chain design, RX design, T/R module design, link budget, and four PCB analyses plus a grounding check. The main overlap is design_rf_chain vs design_tr_module (which internally designs a TX chain) and run_link_budget vs the design tools, but the descriptions clearly delineate when to use each.
All names use snake_case with a meaningful verb prefix, and there is a sensible split: design_* for design tasks, run_* for analyses, check_* for verification. Minor deviation in that three different verb styles coexist, but the pattern is readable and predictable.
Nine tools is well-scoped for an RF/PCB design engine, with each tool covering a clearly earned capability (design, budget, and physical analyses) without redundant variants.
The surface covers the core RF lifecycle (TX, RX, T/R, link budget) plus PCB stackup, PDN, thermal, compliance, and a fabrication check. Minor gaps exist, such as standalone antenna/filter design or report export, but core workflows have no dead ends.
Check a draft passage against the engine results computed in THIS session. It returns every figure no engine produced, and every claim it checks that the results do not support or contradict (for example a solver score called a loss), each in findings with the reason. Run it before publishing or handing over a report, fabrication sheet, BOM summary or any other figure-bearing deliverable built from these tools. It computes nothing and adds no evidence — it only reports what the results back. Fix each finding the way its why says: quote the engine's own value, call the tool that computes it, correct the wording, or say plainly in the text that the figure is not from a tool.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The draft passage to check, verbatim. Pass the prose the end user will actually read — including tables and captions, since a figure in a table is a figure. Markdown is fine. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds the useful behavioral facts that it 'computes nothing and adds no evidence' and only reports what the results back. It also names the output container (`findings`) and each entry's `why`, which goes beyond the annotations.
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 purpose is front-loaded in the first sentence, followed by scope, the recommended trigger, and remediation guidance. It is somewhat dense with backtick field references, but each sentence carries distinct information and nothing is wasted.
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?
For a read-only verification tool with no output schema, the description compensates by describing the return shape (`findings`) and what each finding's `why` contains. It also explains how to resolve findings, so an agent has enough to act correctly, though exact severity/formatting details are left implicit.
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?
With a single parameter at 100% schema description coverage, the schema already explains what `text` should be ('the prose the end user will actually read, including tables and captions'). The description reinforces that figures in tables count, but adds no syntax beyond what the schema provides, so the baseline 3 applies.
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?
States a specific verb and resource — 'check a draft passage against the engine results' — and immediately scopes it to results 'computed in THIS session'. It is clearly distinguishable from the design_*/run_* siblings because it explicitly declares 'It computes nothing and adds no evidence', making it a verifier rather than a generator.
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?
Gives a concrete trigger — 'Run it before publishing or handing over a report, fabrication sheet, BOM summary or any other figure-bearing deliverable built from these tools' — with a list of qualifying artifacts. It lacks an explicit exclusion or a named alternative ('use X instead of Y'), but the routing to the computing tools in the fix guidance is strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Target 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. | |
| bandwidth | No | Signal bandwidth in MHz (optional). | |
| frequency | Yes | Operating frequency in GHz (scalar). | |
| application | No | Application 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_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. | |
| input_power_dbm | No | The 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_bands | No | Bands 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_dbi | No | Antenna 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_dbc | No | The 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_channels | No | Drone 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_modulation | No | Drone 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_v | No | Highest 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_v | No | Lowest 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_power | Yes | Target transmitter output power in dBm. | |
| transmit_bias_pulsed | No | Pulsed 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_only | No | Prefer 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_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 28 V or 48 V bench/battery input. | |
| transmit_duty_cycle_percent | No | Transmit 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. |
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.
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.
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.
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.
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.
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.
Design or analyse a superheterodyne RECEIVER. Selects catalog parts for each slot (limiter, LNA, image filter, mixer, LO, IF filter, IF amp, step attenuator) and returns the frequency plan (image, half-IF, LO leakage), the cascaded noise figure, noise floor, MDS, sensitivity, SFDR and dynamic range, plus the ADC interface (sample rate, Nyquist zone, ENOB, jitter limit). Pass rfFrequencyHz to design one; pass stages[] only for a bench receiver the user described with their own numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| ifHz | No | Intermediate frequency in Hz. Omit to let the server choose one and disclose that it did. | |
| loSide | No | LO above or below the RF. Omit to let the server pick. | |
| stages | No | Explicit receive chain, ONLY for a bench receiver the user described with their own numbers. Do not hand-build this from memory — pass rfFrequencyHz instead and let the server select real parts. | |
| 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. Required for noise floor, MDS and sensitivity — omit it and those are reported as unavailable rather than assumed. | |
| 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. Omit for a full superheterodyne. | |
| 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. | |
| inputPowerDbm | No | Signal level at the antenna port, in dBm. Omit for a small-signal reference, which the result discloses. | |
| requiredSnrDb | No | SNR needed at the demodulator, in dB. | |
| rfFrequencyHz | No | RF centre frequency in Hz (e.g. 9.4e9 for X-band). | |
| 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. | |
| main_board_input_voltage | No | Board DC supply voltage in volts, the same argument design_rf_chain takes. This tool returns no bill of materials or power tree, so a value given here is reported back as unused rather than applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld annotations by disclosing what is withheld and when: omitted bandwidthHz makes noise floor/MDS/sensitivity unavailable, omitted user_request labels results 'caller-asserted', a passed main_board_input_voltage is reported back as unused, and missing nfSideband produces an ambiguity warning. It also states the server will pick and disclose IF and LO side, which is exactly the kind of behavioural context an agent needs.
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?
Front-loaded with purpose and a dense but justified enumeration of return values, which is necessary because there is no output schema. The second sentence delivers the usage rule immediately. The output list is long, but each item earns its place given the absence of a structured return contract.
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?
For a 12-parameter, no-output-schema, all-optional compute tool, the description is close to complete: it covers what is produced, which parameters are the primary design path, and how missing inputs are handled. The one real gap is that it never positions the tool against its closest sibling, design_rf_chain.
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 100% and every parameter already carries a detailed description, so the baseline is 3. The body text repeats the rfFrequencyHz vs stages[] distinction already present in the schema and adds no new syntax or format meaning beyond it.
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?
States a specific verb (design/analyse) and resource (superheterodyne receiver), and enumerates the exact deliverables (frequency plan, cascaded NF, MDS, SFDR, ADC interface), so the tool's scope is unmistakable. It never explicitly contrasts itself with the sibling design_rf_chain, which it only alludes to obliquely via 'the same label/argument design_rf_chain takes', so sibling differentiation is implied rather than stated.
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?
Gives a clear routing rule for the two main entry paths: 'Pass rfFrequencyHz to design one; pass stages[] only for a bench receiver the user described with their own numbers', reinforced by the schema's 'Do not hand-build this from memory'. It also explains the front_end_only architecture switch. It stops short of an explicit when-to-use-this-vs-design_rf_chain rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| 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 is excluded and disclosed. | |
| 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. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint/openWorldHint, and the description adds real behavioral substance beyond them: the four concrete safety budgets returned, that design runs 'through the existing engines', and the front-end selection logic. Combined with schema-level disclosures of refusals, defaults with 'not assumed' semantics, and withheld values, the agent knows how this behaves.
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?
Two sentences, front-loaded with purpose then invocation routing, with zero filler. The enumerated safety budgets are dense but each carries distinct information.
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?
For a 20-parameter tool with no output schema, the description covers the omission: it names the four returned budgets and both invocation modes, and the many defaults/refusals are documented per-parameter in the schema. Only marginal behavioral context (e.g. what the failure/over_limit output looks like) is left unstated, which is acceptable given no output schema.
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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema alone does not: the mutually exclusive design vs check parameter pairs and the purpose of each. It doesn't go further into units or validity ranges, which live in the schema.
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?
Names a specific verb and resource ('Design a T/R module that shares ONE antenna'), states what it builds (both chains via existing engines), what it selects (T/R switch or circulator + limiter), and what it returns (four named safety budgets). It is clearly distinguishable from design_rf_chain and design_rf_receiver, which it explicitly references for the shared 'application' label.
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?
Routes the agent explicitly: pass frequencyGhz + targetOutputPowerDbm to design, pass txPeakPowerDbm + isolationDb to only check a user-supplied front end. The 'ONLY' qualifier on txPeakPowerDbm and the note that it 'skips design entirely' prevents the wrong invocation path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit the solved stackup against PCB standards (IPC-2221, IPC-6012, IPC-4101, MIL, UL-94, RoHS, REACH): per-rule pass/fail with severities and remediation. Reuses the engine behind POST /api/compliance/check. Layers are derived from the solved stackup and standards default to IPC-2221 + IPC-6012 Class 2 — call with no arguments once a stackup exists.
| Name | Required | Description | Default |
|---|---|---|---|
| layers | No | Optional. Stackup layers. Derived from the solved stackup when omitted. | |
| standards | No | Optional. Standards to check (e.g. IPC_2221, IPC_6012_CLASS3, ROHS_3, ETSI_EN_300_328, ETSI_EN_301_893) or a region name for advisory reference limits (e.g. 'China', 'SRRC', 'Japan', 'Canada'). Defaults to IPC-2221 + IPC-6012 Class 2 when omitted. | |
| 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. | |
| stackup_config | No | Optional stackup config (layer_count, total_thickness_mm). Derived when omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real value beyond them: it discloses that layers are derived from the solved stackup, that standards default to IPC-2221 + IPC-6012 Class 2, that it reuses the POST /api/compliance/check engine, and that results are labelled 'caller-asserted' when user_request is omitted. It does not discuss cost, rate limits, or failure modes, so a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and scope, then defaults and invocation guidance. Dense but every clause carries information; the standards acronym list is slightly list-heavy but justified for an audit tool.
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?
With no output schema, the description compensates by describing the return shape (per-rule pass/fail with severities and remediation). Combined with default/derivation rules and the caller-asserted labelling behavior, an agent has enough to invoke it correctly; only minor gaps like expected runtime or result-size remain.
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 coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining that layers and stackup_config are derived when omitted and by restating the default standard set, which is the key behavioral detail an agent needs when calling with no arguments. It does not expand on the region-name form of standards beyond what the schema already documents.
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?
States a specific verb ('Audit') and resource ('the solved stackup against PCB standards'), enumerates the standards families, and names the concrete deliverable (per-rule pass/fail with severities and remediation). This clearly distinguishes it from siblings like run_stackup_solver or run_pdn_analysis without needing to open any schema.
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?
Gives an explicit usage condition: 'call with no arguments once a stackup exists,' which tells the agent both the precondition (a solved stackup must exist) and the default invocation. It does not name a specific alternative tool to use instead, so it falls just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute a cascaded RF link budget. For the chain just designed, call with NO arguments — the server derives stages and input power from the design. Pass stages + inputPowerDbm only for a bench/hypothetical chain. Returns per-stage output power, cumulative gain, Friis cascaded NF, gain-referred reciprocal-sum cascaded OIP3, P1dB headroom warnings, and overall risk. Optionally pass bandwidthHz (and requiredSnrDb) to also get the receiver noise floor, MDS, sensitivity, SFDR, and instantaneous dynamic range.
| Name | Required | Description | Default |
|---|---|---|---|
| stages | No | Ordered list of RF stages for a bench/hypothetical chain. Omit for a just-designed chain (derived server-side). Each stage may declare gainDB or lossDB (loss is treated as -|lossDB|), nfDB, oip3Dbm, p1dbDbm, and an authoritative outputPowerDbm that snap-seeds the cascade. Mark a mixer with mixerRole, plus nfSideband when the user or datasheet says which definition its nfDB uses. | |
| bandwidthHz | No | Optional receiver noise bandwidth in Hz. When given, the result adds the thermal noise floor, MDS, SFDR, and instantaneous dynamic range (a receiver figure of merit). | |
| 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. | |
| inputPowerDbm | No | Input power into the first stage, in dBm. Omit for a just-designed chain (derived from its power flow). | |
| requiredSnrDb | No | Optional SNR (dB) required for detection/demod. With bandwidthHz, yields receiver sensitivity = MDS + this SNR. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, it discloses concrete behavior: per-stage output power, Friis cascaded NF, reciprocal-sum cascaded OIP3, P1dB headroom warnings, overall risk, and the extra receiver figures unlocked by bandwidthHz. It also reveals warning behavior (ambiguous mixer NF, caller-asserted labeling).
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?
Front-loaded with purpose, then usage modes, then return values — a sensible order with no filler sentences. The return-value enumeration is long, though every clause maps to a distinct output an agent would want to know.
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?
With no output schema, the description carries the return-value burden and does so thoroughly, covering both the default and bandwidth-enabled output sets plus defaulting/derivation behavior. An agent can call this correctly without opening any other artifact.
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?
With 100% schema coverage, the baseline is 3, but the description adds real meaning: it explains the no-argument mode, that stages+inputPowerDbm are only for hypothetical chains, and how bandwidthHz/requiredSnrDb interact to add sensitivity results. It does not restate the per-field details already in the schema.
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?
'Compute a cascaded RF link budget' states a specific verb and resource. The description distinguishes this computation tool from the design siblings (design_rf_chain, run_pdn_analysis) by making clear it operates on an already-designed chain rather than producing one.
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 gives two explicit operating modes with conditions: call with NO arguments for a just-designed chain, or pass stages + inputPowerDbm only for a bench/hypothetical chain. Optional-parameter usage (bandwidthHz with requiredSnrDb) is also spelled out, 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.
Run a PDN (power delivery network) impedance analysis: interplanar plane-pair capacitance, multi-cap decoupling impedance vs. target impedance, violations, and recommended decoupling caps. Reuses the Phase-25 engine behind POST /api/pdn/analyze. Inputs are derived server-side from the solved stackup, the BOM's PDN passives, and the power-tree rail — call with no arguments once a design exists.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | Optional target-impedance config {voltage_v, ripple_pct, transient_current_a, rise_time_ns} or {preset_name}. Derived from the power-tree rail when omitted. | |
| plane_pairs | No | Optional. Power/ground plane pairs. Derived from the solved stackup when omitted. | |
| 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. | |
| decoupling_caps | No | Optional. Decoupling capacitors. Derived from the BOM's PDN passive lines when omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior: the Phase-25 engine reuse, the underlying POST /api/pdn/analyze endpoint, and that missing arguments are auto-derived from stackup, BOM passives, and power-tree rails. It does not describe result labeling or the caller-asserted consequence of omitting user_request, which is left to the schema.
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?
Front-loaded with the analysis scope followed by invocation guidance in two compact sentences with minimal waste. Slightly dense with enumerated outputs, but every clause carries information.
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?
With no output schema, the description compensates by enumerating the analysis results (violations, recommended caps). It covers the zero-required-parameter invocation model and the server-side derivation of inputs, leaving only minor gaps about result labeling.
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 100%, so the baseline is 3. The description's statement that inputs are derived server-side overlaps with what the schema already says for each optional parameter ("Derived from ... when omitted"), adding little new per-parameter meaning.
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?
States a specific verb and resource (run PDN impedance analysis) and enumerates the concrete outputs: interplanar plane-pair capacitance, multi-cap decoupling impedance vs. target, violations, and recommended caps. This clearly separates it from sibling analysis tools like run_stackup_solver and run_thermal_analysis.
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?
"call with no arguments once a design exists" gives a clear precondition and invocation pattern, and the note that inputs are derived server-side tells the agent when arguments are unnecessary. It stops short of naming alternatives or stating when not to use it, so it does not reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the impedance-aware stackup constraint solver to find optimal PCB configurations. Use when the user wants ranked material/thickness/copper solutions for a given layer count and frequency. Returns scored and ranked feasible stackups. Each solution's prepreg_thickness_mm is the catalog BASE (pre-lamination) ply thickness, so the per-ply numbers do NOT sum to total_thickness_mm — the total uses the pressed thickness, 0.04064 mm thinner per prepreg ply. Report both as returned; never 'correct' one to match the other.
| Name | Required | Description | Default |
|---|---|---|---|
| topology | No | Transmission line type: microstrip or stripline (default microstrip) | |
| build_type | No | Lamination build: 'single' (default) or HDI level hdi1-hdi4. HDI defaults cost_priority to performance. | |
| layer_count | Yes | Total copper layers (even number, 2-32) | |
| solder_mask | No | Solder mask covering the OUTER trace, as {thickness_mm, dk}. Mask raises the effective permittivity around the trace and pulls Z0 down, so the solver returns a NARROWER width for the same target impedance. OMIT IT (the default) and the microstrip is solved BARE — pass it only when the user says the outer traces are mask-covered, or states a mask thickness or mask Dk. Applies to microstrip targets only: a stripline is buried under laminate, not mask. Both members are optional and default to typical green LPI (0.02 mm, Dk 3.5); thickness_mm must be over 0 and at most 0.2, dk over 1 and at most 10. Mask LOSS is not modeled: the insertion-loss score leaves it out, and a masked result says so in diagnostics — tell your user when you cite a masked solve. | |
| construction | No | Lamination. OMIT it unless the user named one: an omitted lamination is built core_outer wherever core outer can be built (4+ layers, build_type 'single') and foil everywhere else (2 layers, any HDI build). 'foil' puts prepreg outermost, so an outer microstrip rides on prepreg; 'core_outer' puts a core outermost, so the core material, such as an RF laminate, sits directly under the outer microstrip — the same choice Guided Phase IV offers. 'auto' searches BOTH and ranks them together; send it only when the user asks to compare the two. Core outer makes EVERY core that material (N/2 cores), not only the outer pair. Each solution reports the construction it was built as; name it when you cite that solution. | |
| 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. | |
| cost_priority | No | Cost preference: low, balanced, or performance. Default balanced; an HDI build_type OR a frequency at or above 18 GHz defaults to performance instead, because at mm-wave a balanced weighting ranks an FR4-class laminate above every low-loss one. Pass it explicitly to override either default — a stated preference always wins. The priority actually used comes back as costPriority. | |
| frequency_ghz | Yes | Operating frequency in GHz | |
| max_solutions | No | Max solutions to return, 1-20 (default 5) | |
| impedance_ohms | No | Target impedance in Ohms (default 50). Single-target convenience — ignored when impedance_targets is given. | |
| reflow_process | No | Assembly reflow process; enforces a Tg floor on all dielectrics (default lead_free). | |
| copper_weight_oz | No | Restrict solutions to this copper weight in oz (0.5, 1, 2, or 3). Omit to let the solver optimize copper weight; an omitted value inherits the latest update_stackup_config copper weight automatically. The value is the FINISHED thickness, with outer-layer plating already included (1 oz = 0.035 mm finished, plated up from 0.5 oz starting foil). A spec written as '0.5 oz base foil + plating, 1.7 mil finished' uses the OTHER convention — pass 1, not 0.5. | |
| impedance_targets | No | Up to 4 impedance targets the stackup must satisfy SIMULTANEOUSLY, each {ohms, topology ('microstrip'|'stripline'), differential (bool), spacing_mm (differential pair gap in mm, default 0.15)}. Use for multi-impedance boards — e.g. 50 ohm RF plus a 100 ohm differential pair. Overrides impedance_ohms/topology. | |
| target_thickness_mils | No | Board thickness in mils (default 62) | |
| allowed_core_materials | No | Restrict core dielectrics to these catalog materials (e.g. RO4350B, MEGTRON6). Pass ONLY materials the user named; omit to search the full catalog. | |
| thickness_tolerance_mm | No | Allowed deviation from the target thickness in mm. OMIT it and the solver uses 10% of the target thickness. Set it only when the user states a tolerance. The value the solve used comes back as thicknessToleranceMm - cite that one. | |
| allowed_prepreg_materials | No | Restrict prepregs to these catalog materials (e.g. RO4450F, MEGTRON6). Pass ONLY materials the user named; omit to search the full catalog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint and openWorldHint, so the description carries the substantive burden and does well: it discloses the return profile ('scored and ranked feasible stackups') and a non-obvious semantic trap — that per-ply prepreg_thickness_mm is BASE thickness while total_thickness_mm uses pressed thickness (0.04064 mm thinner per ply), with an instruction never to reconcile them. Rate limits, auth, or failure modes are not covered, keeping it below 5.
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?
Front-loaded with purpose, then usage trigger, then return shape, then the critical thickness caveat — a logical reading order with no filler. The final caveat sentence is dense but genuinely earns its place by preventing a real reporting error.
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?
With no output schema, the description must convey the return value, which it does ('scored and ranked feasible stackups') plus the reporting caveat that makes the output interpretable. Combined with 100% schema coverage for 17 parameters, an agent has what it needs; only finer output-field detail (e.g. what the score comprises) is absent.
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 100%, so the exhaustive per-parameter documentation (defaults, omitted-value inheritance, mask Dk ranges, copper weight convention) already does the heavy lifting. The description adds no parameter-level detail beyond the return-value caveat, so the baseline 3 is correct.
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?
States a specific verb and resource ('Run the impedance-aware stackup constraint solver to find optimal PCB configurations') and adds a scope detail — ranked material/thickness/copper solutions for a layer count and frequency. This clearly distinguishes it from siblings like design_rf_chain, run_link_budget, or run_pdn_analysis, none of which produce stackup material solutions.
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?
'Use when the user wants ranked material/thickness/copper solutions for a given layer count and frequency' gives a clear triggering condition. It does not name sibling alternatives or state when NOT to use it, so it falls short of a 5, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a full PCB thermal analysis: via array Rth, junction-to-ambient stack, Kennedy spreading, Coffin-Manson barrel stress, Timoshenko warpage, and resin-flow estimation. Mirrors POST /api/stackups/{id}/thermal-analysis. Call with no arguments once a design exists: the server takes power_w from the designed chain's dissipated power and defaults ambient_c to 25 C. The result carries recommendations (thermal vias, copper, plating) — answer adjustment questions from those entries. If the user states a heatsink or airframe spreader, pass heatsink (θcs, θsa and mount, all three as stated — never guessed); Tj is then computed through it instead of still-air convection.
| Name | Required | Description | Default |
|---|---|---|---|
| heatsink | No | Optional user-STATED heatsink (or drone airframe spreader) the part is mounted to. ALL THREE properties are required together and NONE is ever defaulted — if the user has not stated one, ask; a partial object is rejected naming the missing field. When given it REPLACES still-air convection; the result echoes it with source 'user_supplied' and a heat_path. | |
| delta_t_c | No | Thermal-cycling ΔT in °C for Coffin-Manson fatigue analysis (e.g. 100 °C from −40 to +60 °C operating swing). | |
| via_config | No | Optional thermal via array. ALL SEVEN properties are required together — a partial object is rejected — and plating_thickness_mm must be < via_diameter_mm / 2. | |
| layer_count | No | Total copper layer count (even number, typically 2–32). Used to scale per-layer thermal contributions. | |
| 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. | |
| pour_area_mm2 | No | Total copper-pour spreader area in mm² on the heat-sink side; larger pours reduce the spreading-Rth term. | |
| analysis_input | No | Optional once a design exists. {power_w, ambient_c} are BOTH optional: the server fills power_w from the designed chain's dissipated power and defaults ambient_c to 25 C. Omit this entirely to run thermal on the current design. | |
| board_width_mm | No | Overall PCB width in mm (warpage / CTE inputs). | |
| stackup_layers | No | Optional per-layer thermal contributions. | |
| board_length_mm | No | Overall PCB length in mm — used for Timoshenko warpage and CTE-mismatch curvature estimates. | |
| source_area_mm2 | No | Heat source footprint area in mm² — typically the IC die or package pad footprint. Used for Kennedy spreading resistance. | |
| theta_jc_c_per_w | No | Device junction-to-case thermal resistance in °C/W (datasheet R_θJC). Optional — the server derives it from the designed chain's PA record when available. | |
| copper_thickness_mm | No | Plane/pour copper thickness in mm (e.g. 0.035 for 1 oz, 0.070 for 2 oz). Drives the lateral spreading conductance. | |
| effective_cte_z_ppm | No | Effective z-axis CTE in ppm/°C — input to Coffin-Manson barrel-stress life estimation. Typical 40–70 ppm/°C for FR4. | |
| copper_coverage_top_pct | No | Fractional copper coverage on the top side (0–100 %). Used for warpage symmetry and effective-CTE calculations. | |
| copper_coverage_bottom_pct | No | Fractional copper coverage on the bottom side (0–100 %). Asymmetry vs. top drives warpage predictions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, it discloses server-side defaults (power_w from the designed chain, ambient_c = 25 C), the precedence rule that a supplied heatsink REPLACES still-air convection, the source labelling ('user_supplied') and heat_path echoed in results, and the contents of the result's `recommendations`. This is meaningful behavioral context the annotations cannot convey, and nothing contradicts readOnlyHint.
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 description is front-loaded with what the analysis computes, then progressively narrows to invocation defaults and the heatsink conditional. It is dense but every clause carries operational information for a 16-parameter tool; only the model-name enumeration in the first sentence is arguably list-like padding.
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?
With no output schema, the description carries the burden of describing returns, and it does so partially by naming `recommendations`, the echoed source and heat_path. Given 16 optional parameters and nested objects, it is adequately complete for correct invocation, though it does not sketch the overall result shape (e.g. Tj, Rth values) that an agent would need to interpret output.
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 100%, so the baseline is 3; the description nonetheless adds decision-level meaning, notably that all three `heatsink` fields must be user-stated together and never guessed, and that omitting `analysis_input` runs against the current design. It stops short of explaining how the remaining physical inputs (delta_t_c, via_config geometry) interact, but it clearly exceeds the schema baseline.
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 names a specific verb+resource ("Run a full PCB thermal analysis") and enumerates the exact physical models computed (via array Rth, Kennedy spreading, Coffin-Manson, Timoshenko warpage), which cleanly separates it from siblings like run_pdn_analysis or run_compliance_analysis. It also anchors the tool to a concrete backend route, removing ambiguity about scope.
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 states the primary invocation path ("Call with no arguments once a design exists") and the conditional path ("If the user states a heatsink or airframe spreader, pass `heatsink`"), including the rule that values must be user-stated and never inferred. The trigger for answering follow-up questions from `recommendations` is also explicit, so an agent knows when and how to reuse this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_groundingdesign_rf_chaindesign_rf_receiverdesign_tr_modulerun_compliance_analysisrun_link_budgetrun_pdn_analysisrun_stackup_solverrun_thermal_analysis88 free engineering calculators: RF link budgets, LoRa/Meshtastic, PCB, solar, homelab. Keyless.
device.house — words become circuits. Design devices: BoM, enclosure, firmware, routed PCB.
Electronic component sourcing, BOM management, and PCB design workflows.
Create RF signal projects from prompts, inspect graphs, and export IQ data.
Add one secure layer between your agents and this server.
