eda-agent

Overview Schema Source Related Servers Discussions Admin

pcb_calc_track_current_capacity

Calculate PCB track current capacity using IPC-2221, returning sustainable current at multiple temperature rises plus DC resistance and voltage drop when track length is supplied.

Instructions

IPC-2221 current-carrying capacity for a PCB track.

Pure math, no Altium hit -- safe to call without an attached session. Returns the current the track can sustain at each of several temperature rises (1, 5, 10, 20, 30 °C above ambient), plus DC resistance if a length is supplied.

Formula (IPC-2221, also IPC-2152's curve-fit predecessor): I = k × (ΔT)^0.44 × (h × w)^0.725 where h and w are in mils, ΔT in °C, and: k = 0.048 for external layers (top, bottom) k = 0.024 for internal layers (mid) Internal-layer derating is the dominant correction; running a signal that draws 5 A on TopLayer might be fine but on an inner plane the same width only handles ~3 A at the same ΔT because heat dissipates more slowly.

Copper thickness conversion: 1 oz/ft² ≈ 1.378 mils. So copper_oz=1.0 → h = 1.378 mils, copper_oz=2.0 → h = 2.756 mils.

Resistance: R = ρ × L / (h × w) with ρ = 6.7 × 10⁻⁷ Ω-mil (annealed copper, 25 °C). Multiply current × resistance to get voltage drop across the track.

Exposes the track-current math so the agent can apply it across an entire power net after pulling track widths from pcb_get_trace_lengths.

Args: width_mils: Track width in mils. copper_oz: Copper weight in oz/ft². Common values: 0.5 oz (HDI inner), 1.0 oz (standard), 2.0 oz (power planes), 3.0 oz (heavy-current). layer: "external" (top / bottom) or "internal" (mid / inner planes). Defaults to external. length_mils: If > 0, also returns DC resistance and voltage drop at each temperature rise.

Returns: Dict with: - width_mils, copper_oz, thickness_mils, layer - current_amps (dict, keys 1c, 5c, 10c, 20c, 30c) - resistance_mohm (only if length_mils > 0) - voltage_drop_mv (only if length_mils > 0, dict keyed same as current_amps)

Input Schema

Name	Required	Default
`layer`	No	external
`copper_oz`	No
`width_mils`	Yes
`length_mils`	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.4/5.0

Behavior5/5

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

No annotations exist, so the description carries the full burden and does so well: it declares no-session/no-side-effect behavior, explains internal-vs-external derating with a concrete 5 A vs 3 A example, and discloses conditional outputs (resistance/voltage drop only when length_mils > 0). This is the kind of context an agent needs to trust calling it in a batch loop.

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

Conciseness3/5

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

Front-loaded and sectioned (formula, derating rationale, unit conversion, Args, Returns), but it is long and partly redundant: an output schema already exists, so the verbose Returns block re-specifies what structured data provides, and the derating paragraph is explanatory padding for a pure-math call.

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

Completeness5/5

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

An agent has everything needed to call it correctly: units, defaults, allowed layer values, conditional-output trigger, the underlying formula, and how to chain it with pcb_get_trace_lengths for a net-wide check. Nothing material is missing for a stateless calculation tool.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate and it does fully: width_mils units, copper_oz with four named typical values (0.5/1.0/2.0/3.0 oz), layer with both permitted values and its default, and length_mils' threshold behavior at 0. It even supplies the oz→mil conversion so the agent can sanity-check inputs.

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

Purpose4/5

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

Opens with a specific verb+resource: 'IPC-2221 current-carrying capacity for a PCB track', and the formula and inputs make clear it maps width/copper/layer → current. It never names the inverse sibling `pcb_calc_trace_width_for_current` (or `pcb_calc_impedance`, `pcb_calc_thermal_vias`), so an agent must infer the direction difference from the formula alone.

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 a clear usage precondition ('Pure math, no Altium hit -- safe to call without an attached session') and a concrete workflow hook ('apply it across an entire power net after pulling track widths from pcb_get_trace_lengths'). It does not explicitly state when to prefer this over the width-for-current sibling, so the boundary is implied rather than stated.

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

Deploy Server