rftools-mcp

MCP server for rftools.io — 257 RF & electronics calculators + 14 server-side simulation tools for AI agents.

Give Claude, Cursor, or any MCP-compatible AI assistant access to validated engineering calculators and heavy server-side simulations. Microstrip impedance, link budgets, filter design, converter sizing, antenna patterns, and 200+ more calculators — plus NEC2 antenna simulation, FDTD, Monte Carlo, SMPS analysis, EMI estimation, and more, all callable as MCP tools.

Quick Start

Calculators work with no API key, and so do the simulation tools: without one, a job runs on the free lane. A key raises the limits — sign up at rftools.io and generate one from your dashboard. The one thing a key is required for is a file: uploading a file needs an API key; set RFTOOLS_API_KEY.

Related MCP server: mcp-engineering-tools

Setup

Without API key

All 257 calculators run locally with no sign-up required, and every simulation tool that takes no file still submits — on the free lane, with the free limits and the free-lane parameter bounds stated on the response.

A job type that takes a file is the exception. Uploading a file needs an API key; set RFTOOLS_API_KEY. Without one, a call carrying inputFiles or inputPaths is refused here, with that sentence, before the file is read and before any request leaves this machine.

With API key

Sign up at rftools.io and generate an API key from your dashboard. Free accounts include 5 simulation runs/month. Pro: 100/month. API tier: 10,000/month. A paid key also unlocks the modes the free lane cannot run: the antenna optimiser and the FDTD normal and fine meshes.

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "rftools": {
      "command": "npx",
      "args": ["-y", "rftools-mcp"],
      "env": {
        "RFTOOLS_API_KEY": "rfc_your_key_here"
      }
    }
  }
}

Omit the env block to use calculators only. Restart Claude Desktop after saving.

Claude Code

claude mcp add rftools-mcp -- npx -y rftools-mcp

To add your API key:

claude mcp add rftools-mcp -e RFTOOLS_API_KEY=rfc_your_key_here -- npx -y rftools-mcp

Cursor

Add to .cursor/mcp.json in your project:

{
  "mcpServers": {
    "rftools": {
      "command": "npx",
      "args": ["-y", "rftools-mcp"],
      "env": {
        "RFTOOLS_API_KEY": "rfc_your_key_here"
      }
    }
  }
}

Windsurf

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "rftools": {
      "command": "npx",
      "args": ["-y", "rftools-mcp"],
      "env": {
        "RFTOOLS_API_KEY": "rfc_your_key_here"
      }
    }
  }
}

Tools

25 tools: six for calculators, one simulate_* tool for each of the 14 job types, and five for the job lifecycle; plus the site's reference tables as resources.

What changed in 2.11.2

• simulate_impedance_field_solver: a solve checks where its materials were measured. Every layer's and the mask's refFreq must now lie between 100 kHz and 100 GHz (default 1 GHz), tanD must be below 1, and a dispersive material that the model would restate at a listed frequency as εr below 1 or tanδ of 1 or more is refused, before any charge. Until now any positive refFreq was taken: 1 Hz failed inside the solver and 1e15 Hz gave a wrong impedance. The layers and mask descriptions state the range.

• simulate_impedance_match: results with real parts. Small 0603 multilayer inductors (1.2 to 2.7 nH) were modelled with up to twice the typical datasheet Q and are now at or below it. A network counts as meeting the target only when it is at least 1 dB better than it at the band edges, the centre and across the band, so topology: "auto" no longer prefers one that only just touches the target. No parameter changed.

What changed in 2.11.1

• simulate_impedance_field_solver: the solder mask says where its figures were measured in a stack-up search too. mask.refFreq (Hz, default 1 GHz) was already read; its description now says a search applies the mask to both outer layers and accepts 100 kHz to 100 GHz, and a search refuses a value outside that range. A mask quoted at 1 MHz and read as 1 GHz made covered lines about 1 % narrow.

• simulate_impedance_match: snapped values reach further. With a part model, the snap now considers every standard value within 2× of each part's ideal value, and takes one only when the match is better, no more power is lost and the loaded Q is no higher. Some networks match several dB better; no parameter changed.

• simulate_antenna_sim's tool-page theory names front-to-rear among the Optimize goals.

What changed in 2.11.0

• simulate_antenna_sim: front-to-rear is an Optimize goal. optimize.goals[].figure and optimize.leadGoal accept frontToRear, the peak against the strongest direction 90° to 270° behind the beam, read as its lowest value across the band; a threshold is min in dB. Use it instead of frontToBack when rear rejection matters: a search on frontToBack can settle on a deep null at exactly 180° with strong lobes beside it. Requests that do not name it run exactly as before.

• simulate_impedance_field_solver: a pasted laminate can say where its figures were measured. In solveMode: "stackup", a stackup.catalogue core or prepreg that gives its own er and tanD takes an optional refFreq in Hz (100 kHz to 100 GHz, default 1 GHz), so a datasheet figure quoted at 10 GHz is not dispersed twice.

• simulate_impedance_match: a topology asked for by name returns parts you can buy. With a part model and no branch preference, a network whose parts are all inside the catalogue range is returned when it meets the target, as topology: "auto" already did; branchPreference's description now says so. Snapped values are searched exhaustively, so some networks match better than before. No parameter changed.

What changed in 2.10.1

• simulate_antenna_sim now says what it returns in full: every solve, sweep row and Optimize design carries front-to-rear (the strongest direction 90° to 270° behind the beam) beside front-to-back (180°). No parameter changed.

What changed in 2.10.0

• simulate_impedance_field_solver, a new tool (rftools impedance-field-solver): a 2-D boundary-element solve of a PCB cross-section, quasi-static, with every figure's uncertainty stated. Give planes (bottom, both or none), layers from the bottom up {thickness, er, tanD, dispersion, refFreq} and conductors {role, boundary, x, width, thickness, topWidth or etchFactor, plating} in metres; optionally a conformal mask, copper conductivity and roughness (Hammerstad-Jensen or Huray), several frequencies, solveFor {parameter: width | spacing, target} and tolerances for a first-order spread. It returns, per frequency, Z0 or a pair's differential, common, odd, even and uncoupled impedance, εeff, delay, L and C per length, conductor and dielectric loss, and the stated uncertainty. The free lane takes up to 8 frequencies and 1,200 unknowns; a larger request is refused with what to change.

• Two paid modes of that tool (Pro and API keys): solveMode: "yield" draws whole boards within the tolerances (uniform by default, or normal at 3σ) and tests a specification, 1,000 to 10,000 samples, and returns the pass fraction with its 95 % interval, histograms, the extreme samples and which tolerance to tighten; solveMode: "stackup" searches a catalogue (stackup: layer counts, net classes, fabrication rules, board thickness, a pasted or generic catalogue) for stack-ups that meet every class's impedance, ranked by loss, asymmetric ones marked for warp. A search needs no conductors. Both are refused before any credit is held when over the paid lane's 60-minute budget.

• The bundled impedance calculators are corrected for copper thickness against that solver: stripline takes Wheeler's 1978 thickness factor, microstrip Hammerstad and Jensen's own 1980 correction, the pairs and coplanar waveguide fitted thickness terms, and a cover's thickness is now measured over the copper's top. Results with copper move by up to a few percent (the coupled stripline's odd mode by more), toward the field solver.

• No tool removed and no argument renamed.

What changed in 2.9.0

• simulate_impedance_matching models real parts (rftools matching-real-parts). partModel: "generic" with packageSize (0201, 0402, 0603 or 0805) and inductorTechnology (wirewound or multilayer) models each element as a real chip part fitted to manufacturers' guaranteed datasheet figures: C0G capacitors with series resistance and inductance, inductors with series resistance and the parallel capacitance that sets their self-resonance. Six pairs are offered (0201 multilayer, 0402 and 0603 wirewound or multilayer, 0805 wirewound). The snap picks the standard value whose reactance at f0 is nearest the one asked for, among values that self-resonate at least 1.2 times above the band. Results add performance.real with the dissipation loss, each part's self-resonance, part Q, ESR and effective value at f0, and a note that the models are generic.

• A tolerance yield. yieldTrials (up to 1,000 free, 100,000 on Pro and API) draws every part uniformly within capTolerance / indTolerance (or the component series' default) and returns the share of builds meeting targetRL across the band, with a 95 % Wilson interval, the 5/50/95 % worst-case return loss and the |S11| band. It is estimated and charged like any paid run.

• Without the new arguments a call returns exactly what it did before. No tool removed and no argument renamed.

What changed in 2.8.0

• simulate_antenna_sim's Optimize chooses its goals (rftools antenna-optimizer-v2). optimize.goals sets each of peak gain, front-to-back ratio, VSWR and gain toward an elevation angle (over ground) to optimise, threshold (min, or max for VSWR) or off, with at most three optimised, and leadGoal names the one the recommendation ranks by. Without goals the search is the original one: gain, front-to-back and VSWR, recommended by the 2:1 rule.

• A band: give freqStart, freqStop and freqPoints to Optimize, and every goal is read across them (the lowest gain and front-to-back ratio, the worst or average VSWR).

• A build check: optimize.buildTolerance {mm, trials} re-solves the designs with every element's length and position moved at random within ±mm, reports each design's 10th/90th-percentile figures and the share of builds meeting every threshold, and recommends a design that meets them in at least 90% of builds.

• Mounting height: optimize.heightRange [low, high] (metres, the feed's height) is searched too, over ground; and the sweep mode sweeps height at one frequency with sweepVariable: "height", heightStart, heightStop and heightPoints, reporting each height's gain, takeoff angle, impedance and VSWR.

• The search runs on pymoo 0.6.2 with the same operator settings as before, and each result names its engine and version (searchEngine). A seed reproduces a search on the same engine version; seeds from earlier versions do not reproduce. populationSize no longer needs to be a multiple of 4.

• No tool removed and no argument renamed.

What changed in 2.7.0

No tool was added, removed or renamed, and no tool's arguments changed.

• Two new motor calculators (257 in all) for running a three-phase induction motor from a single-phase supply, on one symmetrical-component model:

  • steinmetz-connection gives the run capacitor, the start capacitor for a chosen starting torque, the voltages, unbalance and highest winding current, the usable output, and the capacitor voltage rating. A second mode gives the exact capacitor and inductor balancer.

  • rotary-phase-converter gives the balancing capacitors of an idler-motor converter, at idle and at full load, the capacitance to switch in between them, and what each set does at the other load.

What changed in 2.5.7

No tool changed. Results follow rftools.io's trace thermal model (changelog, 2026-10-14):

• trace-width-current gains widthBoardMm and pcb-trace-temp gains tempRiseBoard and maxTempBoard: the width and rise for this board, from rftools' own thermal model (never labelled IPC-2152), with inModelRange and a 15 % margin. New optional inputs: boardThickness, planeDistance, planeCopperWeight (and isExternal on pcb-trace-temp).

• provenance.validRange.models lists both fitted models on these two calculators, each with its own inside.

• Both calculators refuse a zero or negative current, rise, copper weight or length, as the API does.

What changed in 2.5.6

No tool changed. simulate_emi_radiated's fields now use the exact π·µ₀/c and µ₀ (once the worker deploys), and calculator results follow the rftools.io formula follow-up (changelog, 2026-10-13):

• Seven outputs are removed (breaking): differential-via's five impedances (a field solution showed they depend on the plane pitch, which is not an input), usb-termination eyeOpening and parabolic-dish-antenna noiseTemperature.

• Values that do not exist are null (breaking): USB 3.0 rise time, crosstalk above the weak-coupling limit, sealed subwoofer at Qts ≥ 0.707, spiral Q at or above resonance, a lossless LC circuit's Q, a via with no stub; and a refused input returns no values instead of zeros.

• Models corrected: the planar spiral's self-resonance and Q, Paul's two-end crosstalk with a far-end output, Margolis & Small port tuning, coupled-microstrip pcb-crosstalk, Balanis' slot model for the patch, LC Q in parallel mode plus the impedance at resonance, microvia arrays, via self-heating, BGA escape rows, IPC-2222 aspect ratios.

• Exact constants: one η₀ = µ₀·c, η₀/2π in every microstrip impedance (−0.069 %), and IEC 60028 copper.

• New inputs: planar-spiral-inductor frequency, pcb-crosstalk dielectricConst, aperture-diagonal routerBit.

What changed in 2.5.5

No tool or argument changed. Calculator inputs and outputs follow the rftools.io input audit (changelog, 2026-10-12):

• Twelve inputs that never changed a result are retired: a call that still sends one is computed and answered with the warning "Input 'X' is not read by this calculator and was ignored." (get_calculator_schema no longer lists them).

• Eight inputs now drive new outputs: patch-antenna's feed resistance at the inset, flyback's primary inductance, solar autonomy, the RS-485 baud rate against the cable's maximum, the ADC's Nyquist zone and alias, bldc-thermal's share of the rating, bldc-winding's no-load speed, and the ISM band. Yagi reports assumedBoomLength.

• Four constant outputs are removed (breaking): balun-transformer vswr and insertionLoss, opamp-bandwidth slewLimited, capacitor-code voltageCode.

• loop-antenna's gain includes its radiation efficiency (it always read 1.76 dBi); a radiationEfficiency output is added.

What changed in 2.5.4

No tool or name changed. trace-width-current's IPC-2152 width (width2152mm) is now IPC-2152 Figure 5-1 (the conservative chart, by its published closed form) instead of IPC-2221 × 0.75/0.85, which erred on the unsafe side: 5 A at a 10 °C rise in 1 oz copper needs 7.19 mm, not 2.09 mm. A new optional traceWidth input sets the width that resistance, voltage drop and power are computed at. pcb-trace-temp adds the Figure 5-1 rise and maximum temperature (rftools.io changelog, 2026-10-12).

What changed in 2.5.3

No tool, argument or name changed. Twelve calculators now compute the model they cite (rftools.io changelog, 2026-10-12):

• mosfet-operating-point solves the drain load line (11.96 mA at the defaults, not 450 mA; biasMode 1 keeps the entered V_DS);

• radar-range-equation takes the range at the required SNR (Albersheim, new pd, pfa and pulses inputs);

• cable-shield-effectiveness refers the shielding to a 50 Ω line;

• ferrite-bead uses a complex bead model (AN-1368);

• bldc-motor solves the loaded speed;

• ethernet-cable uses TIA-568-C.2 insertion loss at each PHY's signalling frequency (Category 8 on IEEE 802.3bq draft coefficients);

• bldc-efficiency and bldc-thermal take I²·R copper loss, and bldc-thermal's hot resistance (it is null above the runaway current);

• class-d-efficiency and motor-driver-power count two conducting FETs;

• coax-impedance and via-calculator use η₀/2π.

What changed in 2.5.2

No tool, argument or name changed. bldc-winding now counts both coil sides in each slot (a double-layer winding), so its fill factor is 2·N·A_wire/A_slot and is no longer capped at 100 %. Its distribution factor comes from the star-of-slots method (12N14P: 0.933, not 0.966), and its default maximum current is 5 A, a winding that builds (rftools.io changelog, 2026-10-11).

What changed in 2.5.1

No tool, argument or name changed. Thirty-one calculators that computed something other than their cited reference now compute it, with the same numbers as the website and the REST API (rftools.io changelog, 2026-10-07). Among them: shielding-effectiveness (reflection loss carries η₀, 45.5 dB was missing; multiple reflections added), ground-plane-impedance (µ₀·h·l/w, with a new optional separation input, default 1 mm), speaker-crossover (2nd-order inductors √2·R/ω_c), esd-tvs-diode (IEC 61000-4-2's 3.75 A/kV first peak), common-mode-choke (a 50 Ω/50 Ω system), minimum-conductor-spacing (IPC-2221B Table 6-1 by band), radiated-emission-estimate (CISPR 32 Class B at the distance; no margin below 30 MHz or above 6 GHz) and via-thermal-resistance (IPC-2221 current capacity, new optional tempRise).

What changed in 2.5.0

No tool was added, removed or renamed, and no tool's arguments changed.

• Fourteen new calculators (255 in all), each checked against a cited textbook, standard or datasheet value:

  • antennas: helical-antenna, monopole-antenna, antenna-downtilt;

  • RF: line-of-sight, wilkinson-power-divider, directional-coupler, circular-waveguide, microstrip-mitered-bend, 5g-nr-band-lookup (3GPP Release 18 band table) and 5g-nr-link-budget;

  • power: rc-snubber, rcd-clamp-snubber.

• A new category, iot ("IoT & LPWAN"), holding lora-link-budget and ble-link-budget. list_calculators with category: "iot" lists them.

• Corrected outputs:

  • filter-designer: its Chebyshev prototype values were wrong from order 4 (g3 1.5733, now 2.3661), a first-order Butterworth gave g1 = 1 (now 2), and the band-pass element values were ten times too small at Q = 10. The values are now computed, not tabulated.

  • waveguide-cutoff, free-space-path-loss, rf-link-budget, fresnel-zone, link-margin and radar-range-equation use the exact speed of light, not 3×10⁸. Lengths move by about 0.07 % and path loss by 0.006 dB. radar-range-equation also uses the exact Boltzmann constant.

  • planar-spiral-inductor refuses an inner diameter at or above the outer one instead of returning NaN.

What changed in 2.4.0

No existing tool was removed or renamed, and no existing tool's arguments changed: every name and every argument 2.3.0 accepted is accepted the same way.

• New tool: search_calculators. Finds calculators by words — "trace impedance on FR4 microstrip" — instead of listing all 257. It matches English titles, keywords, input and output names and descriptions, and the German, Spanish, French, Japanese, Korean and Portuguese titles and keywords, so "マイクロストリップ インピーダンス" finds the microstrip calculator too.

• New tool: get_calculator_schema. One calculator's inputs as a JSON Schema (2020-12): each a number with its unit, minimum, maximum, default and description, with the outputs, the formula and its reference, and the page URL. A misspelt identifier is refused with the closest ones.

• run_calculation lists what it assumed. A new defaultedInputs field names every declared input the call left out, which therefore took its default. An undeclared input key is still computed around and named in a warning, in the REST API's wording; it is not refused.

• Every tool carries annotations: a title and readOnlyHint, destructiveHint, idempotentHint and openWorldHint, so a host can tell what it may run without asking (see Annotations below).

• Every description says what the tool answers, its inputs' units and ranges (or which tool states them), one complete example call and what it returns. The 14 simulate_* descriptions are generated from the website's tool registry, so they change when the tool does.

• Reference tables as resources: frequency bands, RF connectors, standard values, component marking codes and PCB specifications, at rftools://reference/{domain}/{id} (see Reference resources below).

• --manifest: npx rftools-mcp --manifest prints what this build lists — tools, resources, templates, counts — as JSON, and exits.

• run_calculation's webUrl is now the page's canonical address, with its trailing slash.

Annotations

A tool that starts a job or makes a metered call spends the account's monthly allowance, so it is not marked read-only — a host that runs read-only tools without asking would otherwise spend a free account's five runs unprompted — and it is not idempotent, because a repeat spends again (identical job submissions merge only inside 60 seconds). Nothing deletes or overwrites anything, and every tool talks only to rftools.io, so no tool is destructive or open-world.

What changed in 2.2.0

• New tool: solve_calculation. Finds the value of one calculator input that makes an output equal a target — the trace width for 50 Ω, the gap for 90 Ω — instead of an agent guessing values and calling run_calculation in a loop. Unlike every other calculator tool, this runs the search server-side on rftools.io and requires an API key and spends one metered call — see solve_calculation below.

What changed in 2.1.0

• Calculator results carry provenance. run_calculation returns a provenance object beside the values: the method (calculator:<slug>), the engine (mcp@<version>), the published formula source, the calculator's stated assumptions, the inputs it computed from, whether they lie inside the range the calculator is stated for (and, for a fitted model, its validated range and worst-case error), when it was computed and how long it took. It is the same object the rftools.io API returns.

• An input left out takes its default, as on the website and the API; it used to reach the calculator as undefined. An input the calculator does not read is named in warnings, and so is an input outside its stated range — the value is still computed.

• A simulation result's provenance is returned whole in the default summary. Series are still described rather than listed.

What changed in 2.0.0

• One typed tool per job type. Each of the 13 simulation job types now has its own simulate_<jobType> tool (e.g. simulate_impedance_matching) with a real input schema — name, type, unit, range, options and default per parameter — generated from the job type's parameter contract. run_simulation still exists as a compatibility form that takes jobType and params, but prefer the typed tool: it is the one an agent can read the schema of.

• Uploads go through this server, inline (inputFiles: [{name, content}]) or by path on this machine (inputPaths); a file-input job type needs RFTOOLS_API_KEY — see Files below.

• submit_simulation / get_simulation_status / get_simulation_result are the fire-and-forget primitives underneath run_simulation and the typed tools, for a caller that wants to submit, do other work, and poll later.

• run_simulation is now bounded by waitSeconds (default 90, maximum 600): it submits, polls, and if the job has not finished by the bound it returns the job id, status, progress and stage rather than blocking further — the job keeps running, and a later get_simulation_status / get_simulation_result call picks it up.

• Results are summarised by default — summary, warnings, provenance, every scalar value, and long series described by length and extremes rather than listed in full. Pass full: true for the whole payload.

• No defaults are posted. A simulate_* call sends only the parameters you name; it no longer fills in the contract's defaults itself. Since a sampling job type's random seed is derived from the request body, omitting a parameter and sending it at its default are the same request to the solver but not the same body, and can draw a different sample. Set randomSeed to pin a run exactly.

• Typed errors. Failures are classified by the service's errorKind, not by matching message text — see When something goes wrong below.

Breaking:

• list_simulation_tools no longer carries a hand-written sentence describing each job type's parameters; it lists them as a plain array of names (params: string[]). Read a simulate_* tool's own input schema for the type, unit, range, options and default of each parameter.

• Unknown parameter keys are now refused locally, before any request leaves this machine — the same contract the service validates against, checked here first.

Calculator tools

list_calculators, search_calculators, get_calculator_info, get_calculator_schema and run_calculation need no API key — they run locally, for free. solve_calculation is the exception: it runs on rftools.io itself and needs a key, exactly as run_calculation needs none — see its own section below.

list_calculators

List available calculators, optionally filtered by category.

"List all RF calculators"
"What antenna calculators are available?"
"Show me power electronics calculators"

Parameters:

• category (optional): rf, pcb, power, signal, antenna, general, motor, protocol, emc, thermal, sensor, unit-conversion, audio, iot

search_calculators

Find calculators by words, in English or in any of the site's other six languages, ranked by how well they match.

"Which calculator gives trace impedance on FR4 microstrip?"
"Find a calculator for battery charge time"

Parameters:

• query (required): the words to match

• category (optional): restrict to one category; an unknown one is refused with the list

• limit (optional): 1 to 25 results, default 10

Each result carries slug, title, category, a one-line description, the page url and its score; matched says how many calculators matched in all. A search that matches nothing is returned as an error saying so, not as an empty list.

The ranking is deterministic, so the hosted endpoint can reproduce it exactly: text is NFKC-normalised and lower-cased; Latin text splits into words (accents folded, one plural s dropped), Japanese and Korean into character bigrams; each calculator field has a weight (English title 10, translated title 8, keywords 6, translated keywords 5, input and output names 3, description 2); a calculator scores the sum over the query's words of its best field weight times ln(1 + N/df); ties keep registry order. The rules are written out in src/calculator-search.ts.

get_calculator_info

Get detailed info about a calculator — inputs with units/defaults, outputs, and the formula used.

"What inputs does the microstrip impedance calculator need?"
"Show me the buck converter calculator parameters"

Parameters:

• slug (required): Calculator identifier (e.g. "microstrip-impedance")

Each input carries its stated min/max (the same bounds run_calculation's provenance.validRange checks against). An input with neither is unbounded — solve_calculation needs an explicit range to solve for one of those.

get_calculator_schema

The same inputs as a JSON Schema (draft 2020-12) — what a call to run_calculation may send — with the outputs, the formula and the page URL.

Parameters:

• slug (required): Calculator identifier. A misspelt one is refused, naming the three closest (microstrip-impedence → microstrip-impedance, …).

Returns inputSchema (each property a number with title, description — label, unit and tooltip — default, minimum, maximum and x-unit), outputs (key, label, unit), formula (primary, latex where there is one, and reference, the source the formula comes from) and url.

run_calculation

Run a calculator with specific inputs. Returns results with units, a link to the interactive version on rftools.io, defaultedInputs, and the result's provenance (formula source, assumptions, inputs used, whether they lie inside the calculator's stated range, engine version and time). An input left out takes its default and is named in defaultedInputs; an input key the calculator does not declare is not read and is named in warnings; a value outside the stated range is computed and named in warnings. Runs locally — instant, no quota consumed.

"Calculate microstrip impedance for a 0.3mm trace on 0.2mm Rogers RO4003C"
"What's the link budget for a 2.4 GHz link over 500m?"
"Size a buck converter: 12V in, 3.3V out, 2A"

Parameters:

• slug (required): Calculator identifier

• inputs (required): Object with input values, e.g. {"traceWidth": 0.3, "substrateHeight": 0.2}

solve_calculation — needs an API key, spends one metered call

Find the value of one calculator input that makes an output equal a target, instead of calling run_calculation in a loop to search for it yourself. The search runs server-side on rftools.io's own calculators — the same engine /calculate uses — so it needs an API key (RFTOOLS_API_KEY), the same one /calculate itself requires, and it is metered like any other API call. reached: false means no value inside the search range reaches the target; the value returned is then the nearest one the search found, not a guess.

"What trace width gives 50 Ω on 1.6mm FR4 with 1oz copper?"
"Find the gap that gives 90 Ω differential impedance for a 0.15mm trace"

Parameters:

• slug (required): Calculator identifier

• inputs (required): The calculator's other inputs, keyed by name — not including solveFor's own input

• solveFor (required): Which declared numeric input to solve for, e.g. "traceWidth"

• target (required): {"output": "impedance", "value": 50} — the output key and the value it should reach

• grid (optional): Round the solution to the nearest multiple of this manufacturing grid, e.g. 0.001 (mm)

• range (optional): [low, high], narrowing the search inside solveFor's stated bound. Required when get_calculator_info shows no min/max for that input.

The response carries value (on the grid, if one was given), unrounded, reached, evaluations, the solve's own warnings (e.g. another crossing exists in range), and result — exactly what run_calculation//calculate return for the calculator at that value, provenance included.

Simulation tools — no API key required unless the job takes a file

Server-side jobs that are too heavy for in-browser computation. Each of the 14 job types is its own tool, simulate_<name>, whose input schema is generated from that job type's parameter contract: every parameter typed, with its unit, range, options, default and any free-lane bound stated. A call is checked against that contract before anything is sent, so a wrong parameter name comes back naming the key and the keys that are accepted, and spends no quota.

Quota: Free: 5 runs/month · Pro: 100/month · API tier: 10,000/month. Without a key a job that takes no file still runs, on the free lane, and the response says which limits applied. A job that takes a file needs a key — see Files below.

Waiting: a simulate_* call submits and waits up to waitSeconds (default 90, maximum 600), polling immediately — a mode that finishes in a second costs no delay — and reporting progress to hosts that ask for it. On reaching the bound it returns the job id, status, progress and stage; the job keeps running, and get_simulation_status and get_simulation_result pick it up. waitSeconds: 0 submits and returns at once.

Results: the default is a summary — the result's summary, warnings and provenance, every scalar value, and links — with series longer than 50 points described by their length and extremes rather than listed, so a 100 kB result arrives as about 6 kB. Pass full: true for the whole payload. The link to the stored result (resultUrl) is presigned and lives 15 minutes; ask for the status again to mint a fresh one.

Repeat submissions: an identical submission inside 60 seconds returns the job already running rather than starting a second one.

Files: a file-input job type takes either inputFiles: [{name, content}] (inline text, up to 5 MB in one call) or inputPaths: ["/path/to/file.s2p"] (read from this machine). The server obtains the presigned upload, sends the file, and submits the job with the resulting key.

Uploading a file needs an API key; set RFTOOLS_API_KEY. The service refuses an anonymous upload, so this server refuses it first — locally, before the file is read and before any request is made — and says which variable to set rather than passing back a bare 401. The uploaded object is recorded against the key's account, and only that account may submit it.

The 14 job types

The time budget is the lane's cap, not an estimate: most jobs finish in 15–120 seconds, and queue wait may add more.

list_simulation_tools

Every job type with its tool name, parameter names, file rules, time budget and free-lane bounds — all read from the same contract the tools are generated from.

submit_simulation

Submit by job type and return at once with the job id, queue position and time budget. Takes jobType, params, and inputFiles / inputPaths for file-input job types — which need an API key; set RFTOOLS_API_KEY.

get_simulation_status

Progress, stage, queue position, start and finish times for a job id.

get_simulation_result

The finished result for a job id, summarised by default, whole with full: true.

run_simulation

The compatibility form of a simulate_* call: jobType, params, optional files (which need a key, as above), waitSeconds (default 90, max 600) and full. Prefer the typed simulate_* tool for the job you want — it is the one whose schema an agent can read.

"Analyse the PDN of a 100 × 80 mm four-layer board, port at the IC, target 10 mΩ"
"Run an eye diagram on this .s4p at 10 Gbps with PRBS-15"
"Synthesize a broadband matching network from 50Ω to 200Ω between 800–1200 MHz"
"Simulate a 3-element Yagi at 144 MHz and give me the pattern"
"Estimate radiated emissions from a 10 cm trace carrying 50 mA at 100 MHz"

When something goes wrong

Failures are classified by HTTP status and by the service's own error kind, never by matching text: an invalid key, a spent allowance, a rate limit with its retry time, a refused parameter (with the service's own detail, unchanged), a job too large for its lane, a mode the tier does not carry, a timeout and a service fault each read differently. Polling stops at once on a 4xx, and after five failures in a row that are not.

Reference resources

The tables published under rftools.io/reference are MCP resources, one per page, built from the same data the pages are, so the counts always match the site. Each domain has a template for lookup by identifier:

A read returns JSON with the entry's values, its source (the standards the page names and its note on where the values come from) and the page url. An unknown identifier fails with invalid params, naming the template and the valid identifiers. Hosts that offer completion can complete {id}.

Example Conversations

PCB Design

You: I need a 50-ohm microstrip on 1.6mm FR4 with 1oz copper. What trace width?

AI: Calls run_calculation with microstrip-impedance → A trace width of ~2.9mm gives you 50.2 Ω on 1.6mm FR4 (εr=4.2). View on rftools.io →

RF Link Budget

You: Will my 100mW 915 MHz LoRa link work at 2km with 3dBi antennas?

AI: Calls run_calculation with rf-link-budget → Received power: -72 dBm. With LoRa sensitivity at -137 dBm, you have 65 dB of link margin. Easily workable. View on rftools.io →

Power Electronics

You: Design a buck converter: 24V input, 5V output, 3A load, 500kHz switching.

AI: Calls run_calculation with buck-converter → Duty cycle: 20.8%, inductor: 17.4 μH, output cap: 22 μF. View on rftools.io →

All 257 Calculators

Why Use This Instead of Asking the AI to Calculate?

LLMs are unreliable at arithmetic. They may:

• Use simplified formulas that omit corrections (e.g. copper thickness in microstrip)

• Confuse units (mils vs mm, dBm vs dBW)

• Accumulate rounding errors

• Confidently present wrong answers

This MCP server calls the exact same validated calculator code that runs on rftools.io. Hammerstad-Jensen for microstrip, Friis for path loss, exact dB/linear conversions — real engineering formulas, not LLM approximations.

How It Works

Calculators are bundled as pure TypeScript functions — no API calls, no network latency, no rate limits. The AI calls the function directly and gets instant results.

AI Agent ←stdio→ rftools-mcp ←direct call→ calculator function

solve_calculation is the one calculator tool that is not a direct call: it runs the search on rftools.io's own calculators, so it needs an API key and is metered like a plain /calculate call — no queue, no polling, one request and one response.

AI Agent ←stdio→ rftools-mcp ←HTTPS (key required)→ POST /calculate/solve

Simulation tools run server-side on rftools.io infrastructure (AWS Lambda + SQS + EC2/Fargate workers). Their input schemas are generated at build time from the same parameter contract the website's forms are built from, so a contract change reaches the agent at the next release rather than through a hand-edited string. The server validates the call, uploads any files, submits the job, polls it within the wait bound while reporting progress, and returns a summarised result with a link to the whole payload.

AI Agent ←stdio→ rftools-mcp ←HTTPS (key optional)→ rftools.io API → SQS → worker
                                ←poll /v1/jobs/{id}←
                                ←result JSON from a 15-minute presigned link←

Machine-Readable Documentation

• rftools.io/agents — This server's tools, install steps and example prompts, in seven languages

• rftools.io/llms.txt — Summary with API info and MCP setup

• rftools.io/llms-full.txt — Complete listing of all 257 calculators with inputs, outputs, units, and URLs

• npx rftools-mcp --manifest — Everything this build lists (tools with their descriptions, annotations and input schemas, resources, templates and counts) as one JSON document; the agents page is built from it

Links

• Website: rftools.io

• npm: npmjs.com/package/rftools-mcp

• Blog: rftools.io/blog

• Announcement: rftools.io Now Speaks MCP

License

MIT