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. Changed1 schema field changed
    • addedInput schema / properties / user_request / maxLength
      Added value: +4000
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations: discloses that power_w is taken from the designed chain's dissipated power, ambient_c defaults to 25 C, the result carries `recommendations` to answer adjustment questions, a supplied heatsink REPLACES still-air convection and is echoed with source 'user_supplied' and a heat_path, and results are labelled caller-asserted if user_request is omitted.

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?

Dense but front-loaded: purpose first, then invocation defaults, then heatsink handling. Some enumeration of models and overlap with schema text costs a little, but essentially every sentence carries actionable information.

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?

For a 16-param, zero-required, no-output-schema tool, the description covers the critical behaviors (defaults, heatsink replacement semantics, recommendations output). It does not explain the shape of the returned result beyond `recommendations`/`heat_path`, but nothing needed to invoke it correctly is missing.

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 coverage is 100% (baseline 3), but the description adds real semantic value: heatsink θcs/θsa/mount must be 'all three as stated — never guessed', user_request should be the user's verbatim words to prove figures were stated not inferred, and analysis_input is optional once a design exists.

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+resource ('Run a full PCB thermal analysis') and enumerates the exact physics models computed (via array Rth, Kennedy spreading, Coffin-Manson, Timoshenko warpage, resin flow), which clearly separates it from siblings like run_pdn_analysis or run_stackup_solver.

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?

Gives clear invocation context: 'Call with no arguments once a design exists', explains server-side defaults, and tells the agent when to supply `heatsink` (only when the user states one). It lacks an explicit when-not/alternative routing against sibling analyses, but the operating conditions are well defined.

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