Skip to main content
Glama

MagicON RF Design Engines

Run thermal analysis

run_thermal_analysis
Read-only

Run a full PCB thermal analysis: via array Rth, junction-to-ambient stack, Kennedy spreading, Coffin-Manson barrel stress, Timoshenko warpage, and resin-flow estimation. Mirrors POST /api/stackups/{id}/thermal-analysis. Call with no arguments once a design exists: the server takes power_w from the designed chain's dissipated power and defaults ambient_c to 25 C. The result carries recommendations (thermal vias, copper, plating) — answer adjustment questions from those entries. If the user states a heatsink or airframe spreader, pass heatsink (θcs, θsa and mount, all three as stated — never guessed); Tj is then computed through it instead of still-air convection.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
heatsinkNoOptional user-STATED heatsink (or drone airframe spreader) the part is mounted to. ALL THREE properties are required together and NONE is ever defaulted — if the user has not stated one, ask; a partial object is rejected naming the missing field. When given it REPLACES still-air convection; the result echoes it with source 'user_supplied' and a heat_path.
delta_t_cNoThermal-cycling ΔT in °C for Coffin-Manson fatigue analysis (e.g. 100 °C from −40 to +60 °C operating swing).
via_configNoOptional thermal via array. ALL SEVEN properties are required together — a partial object is rejected — and plating_thickness_mm must be < via_diameter_mm / 2.
layer_countNoTotal copper layer count (even number, typically 2–32). Used to scale per-layer thermal contributions.
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.
pour_area_mm2NoTotal copper-pour spreader area in mm² on the heat-sink side; larger pours reduce the spreading-Rth term.
analysis_inputNoOptional once a design exists. {power_w, ambient_c} are BOTH optional: the server fills power_w from the designed chain's dissipated power and defaults ambient_c to 25 C. Omit this entirely to run thermal on the current design.
board_width_mmNoOverall PCB width in mm (warpage / CTE inputs).
stackup_layersNoOptional per-layer thermal contributions.
board_length_mmNoOverall PCB length in mm — used for Timoshenko warpage and CTE-mismatch curvature estimates.
source_area_mm2NoHeat source footprint area in mm² — typically the IC die or package pad footprint. Used for Kennedy spreading resistance.
theta_jc_c_per_wNoDevice junction-to-case thermal resistance in °C/W (datasheet R_θJC). Optional — the server derives it from the designed chain's PA record when available.
copper_thickness_mmNoPlane/pour copper thickness in mm (e.g. 0.035 for 1 oz, 0.070 for 2 oz). Drives the lateral spreading conductance.
effective_cte_z_ppmNoEffective z-axis CTE in ppm/°C — input to Coffin-Manson barrel-stress life estimation. Typical 40–70 ppm/°C for FR4.
copper_coverage_top_pctNoFractional copper coverage on the top side (0–100 %). Used for warpage symmetry and effective-CTE calculations.
copper_coverage_bottom_pctNoFractional copper coverage on the bottom side (0–100 %). Asymmetry vs. top drives warpage predictions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, it discloses server-side defaults (power_w from the designed chain, ambient_c = 25 C), the precedence rule that a supplied heatsink REPLACES still-air convection, the source labelling ('user_supplied') and heat_path echoed in results, and the contents of the result's `recommendations`. This is meaningful behavioral context the annotations cannot convey, and nothing contradicts readOnlyHint.

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

Conciseness4/5

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

The description is front-loaded with what the analysis computes, then progressively narrows to invocation defaults and the heatsink conditional. It is dense but every clause carries operational information for a 16-parameter tool; only the model-name enumeration in the first sentence is arguably list-like padding.

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

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 carries the burden of describing returns, and it does so partially by naming `recommendations`, the echoed source and heat_path. Given 16 optional parameters and nested objects, it is adequately complete for correct invocation, though it does not sketch the overall result shape (e.g. Tj, Rth values) that an agent would need to interpret output.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3; the description nonetheless adds decision-level meaning, notably that all three `heatsink` fields must be user-stated together and never guessed, and that omitting `analysis_input` runs against the current design. It stops short of explaining how the remaining physical inputs (delta_t_c, via_config geometry) interact, but it clearly exceeds the schema baseline.

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

Purpose5/5

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

The description names a specific verb+resource ("Run a full PCB thermal analysis") and enumerates the exact physical models computed (via array Rth, Kennedy spreading, Coffin-Manson, Timoshenko warpage), which cleanly separates it from siblings like run_pdn_analysis or run_compliance_analysis. It also anchors the tool to a concrete backend route, removing ambiguity about scope.

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

Usage Guidelines5/5

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

It states the primary invocation path ("Call with no arguments once a design exists") and the conditional path ("If the user states a heatsink or airframe spreader, pass `heatsink`"), including the rule that values must be user-stated and never inferred. The trigger for answering follow-up questions from `recommendations` is also explicit, so an agent knows when and how to reuse this tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources