eda-agent

Overview Schema Source Related Servers Discussions Admin

pcb_calc_thermal_vias

Size a thermal-via field under a power pad by solving the required via count for a target thermal resistance or scoring an existing layout.

Instructions

Size a thermal-via field under a power pad (Fourier conduction).

The thermal calcs answer "what junction-to-ambient resistance does the part need" (required_theta_ja); this answers "how many vias get the heat into the board". A plated via is a copper tube of axial resistance R = L / (k * A); vias conduct in parallel (R_array = R/N). Give a target -- target_k_per_w directly, or power_w with a delta_t_c budget (target = dT/P) -- to solve the count, or an explicit via_count to score a layout. Pure math, no Altium. Models the via field's conduction bottleneck and assumes good copper spreading on the pad and the receiving plane (a thin-copper spreading term is left to a field solver).

Args: drill_mm: Finished via drill diameter. board_thickness_mm: Conduction length -- top layer to the heat- The EasyEDA and KiCad builds spell this length_mm; either is accepted. length_mm: Alias for board_thickness_mm. spreading plane (full thickness for a bottom plane). plating_um: Barrel plating thickness (default 25 = 1 oz). filled_copper: True for a copper-filled via (full-circle copper), False for an unfilled / resin-filled barrel (annulus only). k_cu: Copper thermal conductivity, W/(m.K) (default 385). power_w: Dissipation, for the target (with delta_t_c) and the realized temperature rise. delta_t_c: Allowed rise across the via field. target_k_per_w: Explicit target array resistance. via_count: Score this exact count instead of solving one.

Returns: {"ok": True, "via_count", "single_via_k_per_w", "array_k_per_w", "target_k_per_w", "temp_rise_c", "barrel_area_mm2", "summary"}.

Input Schema

Name	Required	Description	Default
`k_cu`	No
`power_w`	No
`drill_mm`	Yes
`delta_t_c`	No
`length_mm`	No
`via_count`	No
`plating_um`	No
`filled_copper`	No
`target_k_per_w`	No
`board_thickness_mm`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 29, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden and does well by stating it is pure math with no Altium interaction, explaining the parallel-resistance model, and disclosing assumptions about copper spreading. It does not explicitly cover validation behavior or error cases when the target inputs are insufficient, so it is strong but not complete.

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 long but justified by the 10-parameter, zero-schema-description context, and it is front-loaded with purpose and usage before details. The Args block is useful, but the malformed conduction-length text and some redundant return-value detail reduce structure quality.

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?

Given no annotations, 10 parameters, 0% schema coverage, and an output schema, the description is substantially complete: it explains the physical model, target modes, parameters, assumptions, and return fields. The main gap is the garbled board_thickness_mm/length_mm explanation, which slightly undermines otherwise strong completeness.

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 0%, so the description must compensate, and it largely does by explaining each parameter's meaning, units, defaults, aliases, and modes. However, the board_thickness_mm and length_mm explanations are garbled or split awkwardly, leaving the conduction-length description less clear than the other parameters.

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 opens with a specific action and resource: sizing a thermal-via field under a power pad using Fourier conduction. It clearly distinguishes this calculation from the thermal junction-to-ambient calculation and from placement-oriented via sibling tools by stating that this answers how many vias get heat into the board. An agent can identify the tool's role without opening the schema.

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?

It gives clear usage context: use this to solve via count from a target resistance or from power and delta-T, or to score an explicit via_count. It also distinguishes the calculation from the related thermal calculation. It does not name specific sibling alternatives such as via placement tools or state exclusions, so it falls short of a full 5.

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

Deploy Server