Provides electromagnetic simulation and optimization of RF passive designs using Ansys HFSS, including S-parameter extraction, DRC gating, and full-fidelity verification for layouts.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rf-agent Design a 1:2 Wilkinson divider at 5.8 GHz with at least 25 dB return loss."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A closed loop for RF passive design: a requirement in words → a parametric layout → HFSS → Optuna → an EM-verified board in Altium, driven by an LLM over MCP.
requirement ──▶ RFSpec ──▶ parametric layout ──▶ HFSS (PyAEDT)
▲ │ │
│ │ DRC gate │ S-parameters
│ ▼ ▼
└──────── Optuna ◀──────────── metrics + objective
│
▼
verify at full fidelity ──▶ DXF + Altium + reportIt is the physics half of a pair. eda-agent
owns the board a human has open in Altium — ~400 tools for schematic,
PCB, library and design-agent work. rf-agent owns what eda-agent
cannot know: what the copper should be. Run both and an agent has the
whole path.
Status: working, narrow. The loop runs end to end and the EM model is correlated against a real X-band design. One device family (Wilkinson dividers, 1:2 and 1:4) and one cross-section (grounded coplanar waveguide over a single ground) are implemented. Everything else is scaffolding waiting for a second device.
examples/wilkinson_11g6/ is a complete
recorded run — an 11.6 GHz 1:2 divider taken from one sentence of
requirement to an EM-verified board, with all 30 HFSS solves, the trial
history, the S-parameters, the DXF and the generated report committed.
What it achieved. The textbook starting point fails: −17.07 dB return loss against a −20 dB requirement, with the match sitting 1.1 GHz above where it was asked for. Thirty trials and 24 minutes of solver time later:
analytic seed | after the loop | requirement | |
worst in-band S11 | −17.07 dB ✗ | −22.72 dB ✓ | ≤ −20 |
match centred at | 12.69 GHz | 11.83 GHz | 11.6 |
isolation | −20.04 dB | −18.43 dB ✓ | ≤ −18 |
amplitude imbalance | 0.02 dB | 0.03 dB ✓ | ≤ 0.3 |
phase imbalance | 0.12° | 0.05° ✓ | ≤ 3.0 |
A working X-band divider that meets every requirement, from one sentence of English, with nothing drawn by hand and nobody watching. Return loss improved 4.2 dB, the match moved 860 MHz onto centre, and the balance metrics came in 30× and 50× inside their limits.
The winner was then written into a live Altium session over the eda-agent bridge and read back to check it: 87 tracks, 41 vias, both pours, every net assignment and zero unrouted connections all match the plan. Doing that for real is what caught two bugs a dry run cannot — a net list joined with the wrong delimiter, and a missing ground plane. Screenshot and the plan-vs-actual record are committed.
The example is also worth reading for what it doesn't do: isolation clears by 0.44 dB and only after the widths round onto Altium's placement grid, and the report says so in those words instead of banking the pass. The written board carries no pads or footprints either — it is a routed RF structure, not yet a fabricable PcbDoc. That is the behaviour to check before trusting any of this on a real board.
Stage 1 of that example needs no Ansys licence and no Altium:
uv run python examples/wilkinson_11g6/01_synthesize.pyRelated MCP server: ansys-aedt-mcp
Synthesises, rather than templating. Trace widths come from a conformal-mapping grounded-CPW model, quarter-wave lengths from the effective permittivity that model returns, via pitch from λg/12 in the substrate. Change the laminate or the frequency and every dimension moves. Nothing is a constant carried over from one previous design.
The line model is anchored: on RO4350B 0.254 mm with a 0.25 mm gap it
returns 49.99 Ω at the HFSS-tuned width of 0.524 mm and 70.75 Ω at
0.275 mm — the two drawn widths of an X-band GCPW divider that was
tuned in HFSS and built. tests/test_lines.py holds that as a regression.
Rejects the unbuildable before it costs a solve. Every candidate is checked against the fab rules — trace and gap minima, annular ring, via clearance to signal copper, board-edge keepout — and a failure is scored from its violations rather than sent to HFSS. On a loop where one sample is a minute, that is most of the budget.
Seeds the optimiser with the textbook answer. Optuna trial 0 is always the analytic design, so TPE starts from a real gradient instead of a random corner. The seed is deliberately placed above the ideal quarter wave: a drawn Wilkinson arm always runs long, because the tee and the bends add electrical length the closed-form model cannot see. On the reference design that was about 19%.
Explores cheap, reports honest. The study runs a draft mesh and a short sweep. The winner is re-solved at full fidelity before anything is reported. And because Altium's PCB command surface is integer mils (1 mil = 25.4 µm), if rounding the trace widths onto that grid moves an impedance, the snapped geometry is solved again — so the report states what the board will do, not what the optimiser found.
Writes design intent, not polygons. The Altium export sends centrelines as tracks with their real widths, ground vias as vias, and the coplanar ground as a polygon pour plus a clearance rule sized to the gap the EM model used. Altium regenerates the copper from that, so the result is net-aware, routable and DRC-clean.
Needs Python 3.11+, and Ansys Electronics Desktop for anything that solves.
uv sync --extra plotOptional, for the Altium half: have eda-agent importable (pip install -e path/to/eda-agent, or set RF_AGENT_EDA_AGENT to its checkout).
Check the machine:
uv run rf-agent doctoruv run rf-agent line --laminate RO4350B-0.254 --f0 11.6 --z0 70.711uv run rf-agent synth --f0 11.6 --n-way 2uv run rf-agent design --f0 11.6 --n-way 2 --trials 40design runs the whole loop and writes a run directory: spec.json,
layout.png, sparams.png, the touchstone, the DXF, the HFSS project,
report.md and result.json.
Register the MCP server:
claude mcp add rf-agent -- uv --directory C:/path/to/rf-agent run rf-agent serveTools:
tool | what it is for |
| is HFSS reachable, is the Altium bridge live |
| impedance ↔ width, λg, loss, via pitch |
| requirement → structured spec |
| draw a candidate, DRC it, render it — no solve |
| one candidate through HFSS, scored |
| start a study; returns a job id |
| the whole loop; returns a job id |
| poll the long stages |
| why the bridge is not ready, specifically |
| commit a design into the open PCB |
The long stages return a job id rather than blocking — an MCP call that takes an hour is not usable by an agent.
skills/rfdesign/SKILL.md is the companion skill: how to sequence these,
and what not to claim about the results.
Correlated against that same built X-band divider, and reproduced by
src/rf_agent/em/hfss.py:
substrate box on the laminate material, PEC via barrels punched through
top copper as zero-thickness sheets with a finite-conductivity boundary carrying the real copper thickness and surface roughness
an air box above the board, outer faces left on HFSS's default PEC boundary — that is the metal housing, and it is why there is no radiation boundary anywhere in the file
isolation resistors as lumped RLC sheets bridging the two lands
wave ports on the board edges, integration line running from the ground plane up to the trace
Ports are sized from the line cross-section and from the spacing between neighbouring ports on the same edge. Two overlapping wave-port sheets assign without complaint and fail during the solve, which is an expensive way to find out.
Stated plainly, because a report that only shows the winning curve is not a report:
Isolation resistors are ideal. A real 0402's parasitic inductance degrades isolation above roughly 10 GHz. An X-band isolation figure from this loop is optimistic.
The enclosure is a perfect box. No lid channels, no absorber unless you configure one, no connector launches.
εr is a single design value. No dispersion, no batch tolerance, no temperature.
Conductor loss is first-order. The analytic attenuation is good to a few tens of percent — enough to rank candidates and sanity-check an HFSS insertion loss, not enough to quote.
One signal layer over one ground. Multilayer, buried structures and differential pairs are not in the stackup model.
The generator floods the pour interior with stitching vias, not just a fence along the traces. That is not conservatism. On 0.254 mm RO4350B at X band, running ground vias only along the trace edges leaves large un-stitched islands that behave as patch resonators between the top pour and the bottom ground — on the reference divider, a 3.9 dB notch 260 MHz from the design point. Islands too small to hold a via are dropped entirely rather than left floating.
src/rf_agent/
lines.py closed-form grounded CPW: the analytic seed layer
stackup.py laminates, via policy, fab rules
spec.py RFSpec: the contract between words and geometry
geometry.py Seg/Arc primitives, pour, stitching, DRC
devices/ parametric structures (wilkinson.py)
em/hfss.py PyAEDT model build, solve, content-addressed cache
metrics.py touchstone → worst-case-in-band numbers
objective.py metrics → the scalar Optuna minimises
optimize.py the study
pipeline.py the closed loop
export/ dxf.py (exact) and altium.py (via the eda-agent bridge)
report.py the design report
server.py MCP surface
cli.py the same, from a terminalAdding a device means adding one module under devices/: a parameter
space derived from the spec and a build() that returns a Geometry.
The solver, metrics, optimiser and exporters never learn its topology.
Is a live Altium session reachable, with a PCB open and ready to write?
Says which of the three things is missing -- eda-agent not importable, Altium not running, or the bridge script not started inside it -- and how to fix that one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does well: it discloses the three distinct failure modes (eda-agent not importable, Altium not running, bridge script not started) and states that the tool reports how to fix the missing piece. This gives an agent a clear model of what the tool examines and what it returns without overpromising. It does not explicitly state that the tool is read-only or whether it performs fixes itself, but the diagnostic framing makes that reasonably clear.
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 brief sentences with zero filler. The key question is front-loaded, followed by a list of the three checks and the fix behavior. Every sentence 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 zero-parameter diagnostic tool with an output schema, the description is largely complete: it covers what is checked and what is reported. It could be strengthened by explicitly stating when to run it (e.g., 'run before rf_export_altium') or confirming non-destructiveness, but these are minor gaps given the preflight naming and the question format.
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?
The tool has zero parameters, so the baseline is 4. Nothing in the description needs to explain parameter meanings, and the description instead clarifies what the tool checks internally. No parameter documentation gap exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's core function as a preflight check: determining whether a live Altium session is reachable with a PCB open and ready to write. It names the three conditions verified, which adds specificity beyond the tool name. However, the purpose is phrased as a question rather than an explicit verb+resource statement, and it does not directly distinguish itself from rf_export_altium or rf_design siblings by naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The name 'preflight' and the description imply this should be used before operations that require a live Altium session (e.g., export), but no explicit when-to-use or when-not-to-use guidance is given. It does not name alternative tools or state conditions that would route an agent elsewhere. Usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the whole closed loop: seed, optimise, verify, export, report.
Returns a job id; poll rf_job_status. The winner is re-solved at
full fidelity before anything is reported, and if rounding the trace
widths onto Altium's 1-mil grid shifts an impedance, the snapped
geometry is solved too so the report states what the board will
actually do rather than what the optimiser found.
write_altium=True commits the result into the PCB the user has open,
which needs a live eda-agent bridge -- check rf_doctor first.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | ||
| out_dir | No | ||
| n_trials | No | ||
| timeout_s | No | ||
| write_altium | No | ||
| altium_origin_mils | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden and does so richly: it is asynchronous, the winner is re-solved at full fidelity, Altium grid snapping is handled, and write_altium mutates an open PCB and requires a live eda-agent bridge. These are exactly the non-obvious behaviors 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?
The description is compact, front-loaded with the tool's purpose, and every sentence earns its place by explaining async behavior, fidelity guarantees, or side-effect prerequisites. No redundant wording.
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 tool with no schema descriptions and no annotations, the description covers the workflow and side effects well, but it omits crucial invocation details for the required spec parameter and most optional parameters. The output schema covers return value shape, so the main remaining gap is parameter-level guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all six parameters, but it only meaningfully explains write_altium and the Altium-grid behavior. spec is required and opaque, and out_dir, n_trials, timeout_s, and altium_origin_mils are not explained at all.
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 opens with a specific verb and resource: 'Run the whole closed loop: seed, optimise, verify, export, report.' This clearly distinguishes the end-to-end tool from siblings like rf_optimize, rf_synthesize, and rf_export_altium.
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 that this is the whole closed loop, implying use of individual siblings for narrower steps, and explicitly directs the agent to poll rf_job_status and to check rf_doctor before using write_altium. It does not exhaustively enumerate when-not-to-use conditions, but the workflow guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the RF toolchain on this machine before trusting any result.
Reports the AEDT install PyAEDT will drive, the Python packages the loop needs, and whether a live Altium bridge is reachable. Call this first when anything behaves oddly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the action ('Check', 'Reports') and lists the three check categories, but it does not state whether the tool modifies anything, makes network calls, or has runtime implications. Acceptable for a zero-parameter diagnostic, but not fully transparent.
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?
Three short sentences: the first states purpose, the second names the concrete output areas, and the third gives the usage rule. Every sentence earns its place with no padding or repetition of schema content.
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 zero-argument diagnostic with an output schema, the description fully tells an agent what the tool checks and when to call it. There are no hidden inputs or required clarifications, and the output schema can handle the exact return format.
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?
The tool has zero parameters, so the schema fully defines the invocation surface. The description adds task-level context about what will be checked, but no parameter-level detail is needed; baseline 4 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 ('Check') and resource ('the RF toolchain on this machine'), then enumerates the concrete checks: AEDT install, Python packages, and Altium bridge reachability. This clearly distinguishes it from the design, solve, and export siblings as a pre-flight diagnostic tool.
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 explicit timing guidance: 'Call this first when anything behaves oddly.' It lacks an explicit when-not-to-use or named alternatives, but the toolchain-wide diagnostic scope makes the intended use unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a design into the PCB document the user currently has open.
Emits design intent, not EM polygons: centrelines as tracks with their real widths, ground vias as vias, and the coplanar ground as a polygon pour with a clearance rule sized to the gap the EM model used.
dry_run=True (the default) resolves the whole plan to mils and
returns it without touching the board. Look at the quantisation report
before committing -- Altium's PCB command surface is integer mils, and
on a narrow high-impedance arm that rounding moves the impedance.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | ||
| params | No | ||
| dry_run | No | ||
| place_pour | No | ||
| place_vias | No | ||
| origin_mils | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses that non-dry runs touch the board, that the output is design intent rather than raw EM polygons, and the integer-mil rounding/impedance risk. This goes well beyond what the schema or annotations provide.
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?
Three short, purposeful paragraphs with the main action first, the output model second, and the critical dry-run warning third. Every sentence earns its place and the formatting improves scannability.
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?
The core workflow is well covered and an output schema exists for return values, so that burden is reduced. However, with six parameters and 0% schema coverage, several important inputs — especially the free-form spec and params — are not explained. It is adequate but has clear gaps for a tool of this complexity.
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 coverae is 0%, so the description must compensate for the six parameters. It only really explains dry_run — its default, effect, and purpose. spec, params, place_pour, place_vias, and origin_mils are left undocumented, leaving significant ambiguity about how an agent should populate them.
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 the exact action — 'Write a design into the PCB document the user currently has open' — and specifies the output form: centrelines as tracks, ground vias as vias, coplanar ground as polygon pour, explicitly distinguishing it from EM-polygon exports. The verb, resource, and style are all clear.
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?
Provides clear context: requires an open PCB document and directs the agent to use dry_run first and review the quantisation report before committing. It does not explicitly compare against sibling tools like rf_altium_preflight or state when not to use it, so it misses the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Progress of a running study or design loop, and its result when done.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| include_result | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does state that the tool returns progress and result when done, which is a basic behavioral trait, but it omits any information about whether the operation is read-only, whether it blocks, errors on unknown job_ids, or any authentication/rate-limit requirements. The information is minimal and insufficient for safe autonomous use.
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 a single, concise sentence with no filler, and the core purpose is front-loaded. However, it lacks structured elaboration, such as bullet points or clarifications, which might have improved clarity without adding fluff.
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?
While an output schema exists (which need not be duplicated in the description), the description fails to provide essential context: it doesn't mention that job_id likely originates from launching a design or optimization job, or that this tool complements rf_list_jobs. The description is too sparse to fully enable an agent to know when and how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation about the parameters job_id or include_result. It doesn't clarify the meaning of include_result (e.g., what result is, or the impact of setting it to false) or how job_id should be obtained. The tool relies entirely on parameter names, which is inadequate for 0% coverage.
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 clearly states the tool provides progress and result information for a running study or design loop, which distinguishes it from sibling tools like rf_design or rf_optimize that launch processes, and rf_list_jobs that likely list jobs. However, the phrase 'study or design loop' is somewhat vague and doesn't explicitly name any sibling or contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as rf_list_jobs or rf_design. There is no mention of polling patterns, prerequisites (e.g., needing a job_id from a prior call), or when this is the appropriate choice over other status-related tools. Usage context is entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grounded-CPW impedance, effective permittivity and wavelength.
Give width_mm to analyse a line, or z0 to synthesise the width
that hits an impedance. This is the closed-form model the optimiser
seeds from -- it is accurate enough to start from and not accurate
enough to finish on.
| Name | Required | Description | Default |
|---|---|---|---|
| z0 | No | ||
| f0_ghz | No | ||
| gap_mm | No | ||
| laminate | No | RO4350B-0.254 | |
| width_mm | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It honestly reveals that this is a closed-form approximation and explicitly warns that it is not accurate enough to finalize a design. This gives an agent useful expectations about fidelity and its role in the larger pipeline.
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 compact, well-ordered, and free of filler. It leads with the main outputs, then explains the two invocation modes, and ends with an important accuracy caveat. Every sentence adds value.
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 an output schema present, the description does not need to explain return values. It covers core invocation modes and accuracy context. Minor gaps remain around what happens when both width_mm and z0 are supplied or neither is supplied, and valid laminate values are not explained, but the description is broadly sufficient for an agent to select and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly explains the central width_mm/z0 analysis-vs-synthesis relationship, but it does not describe f0_ghz, gap_mm, or laminate beyond what their names and defaults imply. The parameter names are fairly self-explanatory, but the description leaves some semantic burden on 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?
The description clearly identifies the tool's domain (Grounded-CPW impedance, effective permittivity, wavelength) and its two operation modes: analyse with width_mm and synthesise with z0. It distinguishes itself from sibling tools by explicitly framing it as the closed-form model the optimizer seeds from, not a full solver or optimizer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance on when it should be used: it is accurate enough to start from but not accurate enough to finish on, which implies it is for initial estimates rather than final design. It also tells users when to provide width_mm versus z0. However, it does not explicitly name sibling alternatives or state when to prefer them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The parametric structures this server can synthesise and optimise.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state that the tool returns a list, that it is read-only, or any other behavior. The agent is left completely in the dark about what happens when called.
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 extremely short, but it is under-specified rather than concise. It omits essential information (e.g., that it lists something) and what it does say is vague and potentially misleading.
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?
Despite having an output schema, the description does not explain what the tool returns. A simple tool with zero parameters could be fully described in one clear sentence, but this is incomplete and leaves the agent uncertain about the tool's purpose and result.
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?
The tool has zero parameters, so the schema is already fully covered. The description adds nothing about parameters, but there is nothing to add. The baseline of 4 for zero-parameter tools is appropriate.
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 is a noun phrase ('The parametric structures...') rather than a verb phrase indicating an action. It does not state that this tool lists devices/structures, making its purpose ambiguous. It also fails to distinguish itself from sibling tools like rf_list_jobs.
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?
There is no guidance on when to use this tool or when to use an alternative. The description provides no context about the typical use case, and no sibling comparison is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every job this server has run in this session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It communicates that the tool enumerates all jobs run in the current session, which is useful, but it does not mention whether the operation is read-only, whether results include failed jobs, or any other behavioral nuance. The listing behavior itself is reasonably transparent.
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?
A single, short sentence that states the tool's scope without any filler. It is appropriately sized for a zero-parameter listing tool and is easy to parse.
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?
The description is adequate for a simple zero-parameter list operation, especially with an output schema available. However, it lacks any connection to sibling tools or usage context, so an agent may not know when to choose this over rf_job_status without additional inference.
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?
The tool has zero parameters, so the baseline is 4 and the description does not need to explain parameter meanings. The description adds no parameter information, but none is required.
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 clearly identifies the resource (jobs) and scope (this server, this session), and the name 'rf_list_jobs' reinforces the listing action. It is understandable and distinct from sibling tools like rf_job_status, though it lacks an explicit verb and does not directly contrast itself with any sibling.
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?
No guidance is provided on when to use this tool versus alternatives. The description implies a historical/session-scoped listing use case, but it does not mention rf_job_status or any other sibling, nor does it state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a requirement into the structured spec everything else reads.
Limits are stated the way a datasheet states them: s11_db=-20 means
S11 at or below -20 dB across the band, isolation_db=-18 means the
coupling between any two outputs stays at or below -18 dB. Keep
requirement_text -- it goes in the report so the design can be
traced back to the sentence that asked for it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| n_way | No | ||
| f0_ghz | Yes | ||
| gap_mm | No | ||
| s11_db | No | ||
| save_to | No | ||
| laminate | No | RO4350B-0.254 | |
| isolation_db | No | ||
| bandwidth_frac | No | ||
| excess_loss_db | No | ||
| requirement_text | No | ||
| amplitude_imbalance_db | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses that limit values mean 'at or below' and that requirement_text is retained for traceability in the report. However, it does not clarify whether the spec is returned, saved via save_to, or validated, leaving some side-effect behavior implicit.
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?
Three sentences carry real signal: purpose, limit convention, and traceability. No filler; the distinguishing fact that every downstream tool reads this spec is front-loaded.
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?
The output schema reduces the need to describe return values, and the most subtle parameter semantics are covered. Gaps remain around side effects (save_to behavior), the meaning of several un-described parameters, and explicit when-not-to-use guidance, so the definition is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly explains the meaning of s11_db and isolation_db as negative-dB max limits, and it explains requirement_text's role in the report. Most of the other 12 parameters, such as n_way, bandwidth_frac, excess_loss_db, and save_to, still lack descriptive semantics beyond their titles and defaults.
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 uses a concrete verb ('Turn') and identifies both the input ('requirement') and output ('structured spec'). 'Everything else reads' clearly positions this tool upstream of siblings like rf_design, rf_synthesize, and rf_solve, so an agent can distinguish it without opening any other tool definition.
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 context: when you have a requirement and need the canonical spec that all downstream tools consume. The pipeline positioning is clear, though it does not explicitly name when-not-to-use alternatives or list exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an Optuna study over the device's parameters, scored by HFSS.
Returns a job id immediately; poll rf_job_status. Trial 0 is always
the analytic seed. Exploration runs at draft mesh; call rf_design
instead if you want the winner verified, exported and reported in one
go.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| spec | Yes | ||
| n_trials | No | ||
| timeout_s | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does so well by explaining that the call returns a job id immediately, that trial 0 is always the analytic seed, that exploration runs at draft mesh, and that results are not verified/exported/reported unless rf_design is used.
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 compact and front-loaded: purpose first, then async behavior, then the caveat and alternative. Every sentence earns its place, and no filler is present.
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?
The description is operationally complete for an asynchronous optimization tool: it tells the agent what happens, what to do next, and which sibling to use for verified results. Minor gaps remain around configuring `spec` and what prerequisites exist, but the sibling tools and self-explanatory parameters fill most of those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate. It adds meaning to `spec` by referencing 'device's parameters' and clarifies the study's trial behavior, though it doesn't explicitly explain `seed`, `n_trials`, or `timeout_s`. The parameter names and defaults are largely self-explanatory, making this a solid but not exhaustive contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Start an Optuna study over the device's parameters, scored by HFSS.' It distinguishes itself from rf_design by explicitly saying to call rf_design instead when the winner should be verified, exported, and reported.
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 clearly tells the agent when this tool is appropriate: for exploration at draft mesh. It names the alternative, rf_design, and the condition for choosing it, while also directing the caller to poll rf_job_status after getting a job id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solve one candidate in HFSS and score it against the spec.
Blocking, and a full-fidelity solve on a small divider is minutes.
Use draft=True for a fast, coarser answer. Results are cached by
geometry content, so re-solving the same candidate is free.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | ||
| draft | No | ||
| params | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the behavioral burden. It discloses that the call is blocking, that full-fidelity is slower, that draft is coarser, and that results are cached by geometry content. This is good beyond the schema but does not cover return values or failure modes.
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?
Three sentences with no filler: purpose, perfomance expectation, draft toggle, and caching are each stated directly. Front-loaded with the main action.
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?
The description conveys the core workflow, timing, and the draft option, but leaves the 'params' argument unexplained and does not describe what the score result looks like. An agent could probably invoke it, but may not know what to pass in params or how to interpret the 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?
The schema provides no descriptions for spec, draft, or params. The description clarifies that spec is the candidate being solved and that draft toggles fast mode, but params is never explained. With low schema coverage, the description compensates only partially.
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 opens with a specific verb and resource: 'Solve one candidate in HFSS and score it against the spec.' This clearly distinguishes it from sibling tools like rf_synthesize or rf_optimize by focusing on solving/scoring a single candidate, not generating or optimizing.
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 clear context for using the tool: it is blocking, full-fidelity takes minutes, and draft=True provides a faster coarser answer. It also notes caching behavior. It does not explicitly compare with alternative siblings or state when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw a candidate layout without solving it.
With no params this returns the analytic seed -- the textbook
starting point the optimiser begins from. Always cheap; use it to
sanity-check dimensions, DRC and board size before committing solver
time. The PNG is worth looking at.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | ||
| params | No | ||
| render | No | ||
| out_dir | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It honestly reveals the no-solving behavior, the analytic-seed behavior when params is null, the low cost profile, and the PNG output. It does not clarify side effects such as whether out_dir writes files or how render affects output, so it is adequate but not rich.
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?
Extremely tight and front-loaded: the core behavior appears in the first sentence, usage guidance follows immediately, and the final sentence points at the inspectable output. Every line adds information; no filler.
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?
An output schema exists, so return-value details are not required. Still, with no annotations and a required spec parameter that has zero schema explanation, the description is not fully self-sufficient. It captures purpose and cost well but leaves parameter semantics and the distinction from rf_design under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only explains the null-params case and hints at a PNG. It does not explain what the required spec should be, nor what render or out_dir control. Three of four parameters remain effectively undocumented.
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 clear verb ('Draw') and object ('candidate layout') and adds a critical behavioral constraint ('without solving it'), which differentiates it from the solver siblings. However, it does not explicitly distinguish itself from rf_design, which may also be a layout-generation tool.
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?
Provides clear usage context: it is cheap and meant for sanity-checking dimensions, DRC, and board size before committing solver time. This implies a before-solve workflow, but it names no alternatives and does not state explicit when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct stage (spec, analytic model, candidate layout, solve, optimize, export) and the descriptions explicitly differentiate the high-level rf_design from rf_optimize and rf_doctor from rf_altium_preflight. Minor overlap exists between rf_line_model and rf_synthesize's analytic seed, and between the two environment-check tools, but the descriptions are clear enough to avoid serious misselection.
All tools share the rf_ prefix and snake_case verb_noun style (list_devices, make_spec, export_altium), making the surface easy to scan. A few names are noun-heavy or verbless — rf_doctor, rf_line_model, rf_job_status, rf_design — which slightly breaks the otherwise consistent pattern.
Twelve tools is well-scoped for an RF design-and-optimization workflow: preflight checks, spec creation, modeling, synthesis, solving, optimization, job tracking, and Altium export each have a dedicated entry point. No tool feels redundant, and the count is manageable.
The surface covers the full design loop: health checks, device discovery, spec capture, analytic modeling, candidate generation, full-fidelity solving, optimization, asynchronous job status, and Altium export with a dry-run safety path. There are no obvious dead ends or missing lifecycle steps for the stated RF synthesis and export purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered bioprotocol optimization — generate, search, and manage lab protocols via MCP
Open Design MCP capability governed by DigitalPipe.
MCP server for building and testing AI agents with multi-model experimentation and insights.
HiveCapital MCP Server — autonomous investment layer for AI agents
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tisn1678065900-dot/rf-agent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
