Skip to main content
Glama

MagicON RF Design Engines

Solve a PCB stackup

run_stackup_solver
Read-only

Run the impedance-aware stackup constraint solver to find optimal PCB configurations. Use when the user wants ranked material/thickness/copper solutions for a given layer count and frequency. Returns scored and ranked feasible stackups. Each solution's prepreg_thickness_mm is the catalog BASE (pre-lamination) ply thickness, so the per-ply numbers do NOT sum to total_thickness_mm — the total uses the pressed thickness, 0.04064 mm thinner per prepreg ply. Report both as returned; never 'correct' one to match the other.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topologyNoTransmission line type: microstrip or stripline (default microstrip)
build_typeNoLamination build: 'single' (default) or HDI level hdi1-hdi4. HDI defaults cost_priority to performance.
layer_countYesTotal copper layers (even number, 2-32)
solder_maskNoSolder mask covering the OUTER trace, as {thickness_mm, dk}. Mask raises the effective permittivity around the trace and pulls Z0 down, so the solver returns a NARROWER width for the same target impedance. OMIT IT (the default) and the microstrip is solved BARE — pass it only when the user says the outer traces are mask-covered, or states a mask thickness or mask Dk. Applies to microstrip targets only: a stripline is buried under laminate, not mask. Both members are optional and default to typical green LPI (0.02 mm, Dk 3.5); thickness_mm must be over 0 and at most 0.2, dk over 1 and at most 10. Mask LOSS is not modeled: the insertion-loss score leaves it out, and a masked result says so in diagnostics — tell your user when you cite a masked solve.
constructionNoLamination. OMIT it unless the user named one: an omitted lamination is built core_outer wherever core outer can be built (4+ layers, build_type 'single') and foil everywhere else (2 layers, any HDI build). 'foil' puts prepreg outermost, so an outer microstrip rides on prepreg; 'core_outer' puts a core outermost, so the core material, such as an RF laminate, sits directly under the outer microstrip — the same choice Guided Phase IV offers. 'auto' searches BOTH and ranks them together; send it only when the user asks to compare the two. Core outer makes EVERY core that material (N/2 cores), not only the outer pair. Each solution reports the construction it was built as; name it when you cite that solution.
user_requestNoThe end user's own words that prompted this call, verbatim. Used to verify that the figures you pass were stated by your user rather than inferred. Omit it and the results will be labelled caller-asserted.
cost_priorityNoCost preference: low, balanced, or performance. Default balanced; an HDI build_type OR a frequency at or above 18 GHz defaults to performance instead, because at mm-wave a balanced weighting ranks an FR4-class laminate above every low-loss one. Pass it explicitly to override either default — a stated preference always wins. The priority actually used comes back as costPriority.
frequency_ghzYesOperating frequency in GHz
max_solutionsNoMax solutions to return, 1-20 (default 5)
impedance_ohmsNoTarget impedance in Ohms (default 50). Single-target convenience — ignored when impedance_targets is given.
reflow_processNoAssembly reflow process; enforces a Tg floor on all dielectrics (default lead_free).
copper_weight_ozNoRestrict solutions to this copper weight in oz (0.5, 1, 2, or 3). Omit to let the solver optimize copper weight; an omitted value inherits the latest update_stackup_config copper weight automatically. The value is the FINISHED thickness, with outer-layer plating already included (1 oz = 0.035 mm finished, plated up from 0.5 oz starting foil). A spec written as '0.5 oz base foil + plating, 1.7 mil finished' uses the OTHER convention — pass 1, not 0.5.
impedance_targetsNoUp to 4 impedance targets the stackup must satisfy SIMULTANEOUSLY, each {ohms, topology ('microstrip'|'stripline'), differential (bool), spacing_mm (differential pair gap in mm, default 0.15)}. Use for multi-impedance boards — e.g. 50 ohm RF plus a 100 ohm differential pair. Overrides impedance_ohms/topology.
target_thickness_milsNoBoard thickness in mils (default 62)
allowed_core_materialsNoRestrict core dielectrics to these catalog materials (e.g. RO4350B, MEGTRON6). Pass ONLY materials the user named; omit to search the full catalog.
thickness_tolerance_mmNoAllowed deviation from the target thickness in mm. OMIT it and the solver uses 10% of the target thickness. Set it only when the user states a tolerance. The value the solve used comes back as thicknessToleranceMm - cite that one.
allowed_prepreg_materialsNoRestrict prepregs to these catalog materials (e.g. RO4450F, MEGTRON6). Pass ONLY materials the user named; omit to search the full catalog.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only cover readOnlyHint and openWorldHint, so the description carries the substantive burden and does well: it discloses the return profile ('scored and ranked feasible stackups') and a non-obvious semantic trap — that per-ply prepreg_thickness_mm is BASE thickness while total_thickness_mm uses pressed thickness (0.04064 mm thinner per ply), with an instruction never to reconcile them. Rate limits, auth, or failure modes are not covered, keeping it below 5.

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

Conciseness4/5

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

Front-loaded with purpose, then usage trigger, then return shape, then the critical thickness caveat — a logical reading order with no filler. The final caveat sentence is dense but genuinely earns its place by preventing a real reporting error.

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

Completeness4/5

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

With no output schema, the description must convey the return value, which it does ('scored and ranked feasible stackups') plus the reporting caveat that makes the output interpretable. Combined with 100% schema coverage for 17 parameters, an agent has what it needs; only finer output-field detail (e.g. what the score comprises) is absent.

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

Parameters3/5

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

Schema description coverage is 100%, so the exhaustive per-parameter documentation (defaults, omitted-value inheritance, mask Dk ranges, copper weight convention) already does the heavy lifting. The description adds no parameter-level detail beyond the return-value caveat, so the baseline 3 is correct.

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

Purpose5/5

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

States a specific verb and resource ('Run the impedance-aware stackup constraint solver to find optimal PCB configurations') and adds a scope detail — ranked material/thickness/copper solutions for a layer count and frequency. This clearly distinguishes it from siblings like design_rf_chain, run_link_budget, or run_pdn_analysis, none of which produce stackup material solutions.

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

Usage Guidelines4/5

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

'Use when the user wants ranked material/thickness/copper solutions for a given layer count and frequency' gives a clear triggering condition. It does not name sibling alternatives or state when NOT to use it, so it falls short of a 5, but the usage context is unambiguous.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources