PCB calculators: trace impedance, crosstalk, diff skew, crystal load cap, Vout tolerance, inrush.
Scored across 6 tools
Each tool targets a distinct circuit analysis: crosstalk, diff_skew, impedance, inrush_current, output_voltage_tolerance, and xtal_load_cap. There is no overlap in purpose, and an agent can easily select the correct tool based on the physical quantity to compute.
All names are lowercase noun phrases, using underscores for multi-word terms (diff_skew, inrush_current, output_voltage_tolerance, xtal_load_cap) and single words for the rest (crosstalk, impedance). The pattern is predictable and consistent throughout.
Six tools is a well-scoped set for a circuit analysis lab, with each tool covering a distinct and useful calculation. No tool feels redundant or out of place.
The server covers several signal-integrity, power-integrity, and component calculations, but notable gaps remain for a general 'Circuit Sim Lab', such as transient/AC simulation, noise, thermal, or S-parameter analysis. An agent expecting full simulation capabilities would find the surface incomplete.
兩條耦合線的串音：偶／奇模阻抗用 2D 電場數值解，再算近端串音係數 kb、飽和比例、遠端串音係數。只回傳解析式的部分（不含工具頁的 ngspice 時域波形）。
| Name | Required | Description | Default |
|---|---|---|---|
| h | No | 微帶線：線到參考層的介質厚度（kind=ms）（mm） | |
| s | No | 差動對的線間距（單線 single 模式不用）（mm） | |
| t | No | 銅厚（35 µm＝1 oz）（mm） | |
| w | No | 線寬（mm） | |
| er | No | 板材介電常數 εr（帶狀線上下用同一個） | |
| ha | No | 帶狀線：線頂到上參考層（kind=sl）（mm） | |
| hb | No | 帶狀線：線底到下參考層（kind=sl）（mm） | |
| tr | No | 攻擊線的上升時間（10–90%）（ps） | |
| len | No | 並行長度（mm） | |
| kind | No | ms＝微帶線（外層）、sl＝帶狀線（內層，上下都有參考層） | ms |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It usefully scopes the output ('only returns the analytical part, excluding the ngspice time-domain waveform from the tool page'), which prevents the agent from expecting waveform data, but for a stateless calculator it omits any note on prerequisites or the exact form/units of the returned quantities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with the computation front-loaded and the output-scope caveat last. No filler is present, though the middle clause listing three outputs makes the sentence dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description steps in by naming the returned quantities (kb, saturation ratio, far-end coefficient) and excluding the ngspice waveform, which is the key missing context. A 10-parameter tool with 0 required params is otherwise well covered by the schema, so only minor gaps (return format/units) remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% across all 10 parameters, so units, ranges, and defaults (h, s, w, t, er, ha, hb, tr, len, kind) are already fully documented in the schema. The description mentions no parameter syntax or constraints beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific computation: crosstalk between two coupled lines, even/odd mode impedance via 2D field solve, plus near-end coefficient kb, saturation ratio, and far-end coefficient. This is clearly distinct from the sibling set (impedance, diff_skew, inrush_current, etc.), none of which compute crosstalk, so an agent can route here without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use statement, no prerequisites, and no mention of alternative tools such as impedance or diff_skew. The description implies a signal-integrity calculation context through its outputs, but gives the agent nothing to decide between this and neighboring calculators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
兩條線的長度差換成時間差（ps），對照介面的上限：USB3／PCIe 用業界經驗值 5 mil（非規範原文，出處見適用範圍）；DisplayPort／HDMI 沒有預設，請用 lim 填晶片廠或規範給的值。
| Name | Required | Description | Default |
|---|---|---|---|
| ee | No | 有效介電常數 εeff | |
| ln | No | N 線長度（mm） | |
| lp | No | P 線長度（mm） | |
| lim | No | 對內長度差上限（ps）。0 或不帶＝用介面預設（USB3／PCIe 業界經驗值 5 mil）；DP／HDMI 沒有預設，請填晶片廠或規範給的值，沒帶時 limit_ps 回 null（ps） | |
| rate | No | 資料速率（UI＝1000÷速率 ps）（Gbps） | |
| iface | No | 介面：none／usb3／pcie／dp／hdmi | none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It helpfully discloses that the 5 mil figure is an industry rule of thumb and not spec text, and that limit_ps returns null when no default exists — real transparency gains. However, it says nothing about output fields, edge cases (equal lengths), or error behavior for a pure computation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the core operation (length diff → time diff) before the limit/default detail. Efficient, though the semicolon-chained clauses make it slightly harder to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter, all-optional calculator with no output schema, the description covers the essential operation, the interface-default logic, and the null-limit case. It does not explain how ee (Dk) and rate feed the computation or what the full result set contains, but the schema documents each input and the core behavior is adequately conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 largely restates what the lim parameter description already says about defaults and the null case, adding only the caveat that the 5 mil value is non-normative — marginal added meaning over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete transformation (length difference between two traces → time skew in ps) plus a comparison against an interface limit, which is unambiguous and clearly distinct from computational siblings like crosstalk or impedance. It stops short of explicitly naming alternatives, so it lands at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives conditional guidance on lim: USB3/PCIe fall back to the industry rule-of-thumb 5 mil, while DP/HDMI have no default and require a vendor/spec value. That is useful usage context, but there is no when-to-use-this-vs-another-tool guidance and no prerequisites, so it is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
用 2D 電場數值解算微帶線或帶狀線的差動阻抗（Zdiff、Zcomm、奇／偶模）或單端阻抗（Z0），含銅厚。回傳附適用範圍。
| Name | Required | Description | Default |
|---|---|---|---|
| h | No | 微帶線：線到參考層的介質厚度（kind=ms）（mm） | |
| s | No | 差動對的線間距（單線 single 模式不用）（mm） | |
| t | No | 銅厚（35 µm＝1 oz）（mm） | |
| w | No | 線寬（mm） | |
| er | No | 板材介電常數 εr（帶狀線上下用同一個） | |
| ha | No | 帶狀線：線頂到上參考層（kind=sl）（mm） | |
| hb | No | 帶狀線：線底到下參考層（kind=sl）（mm） | |
| kind | No | ms＝微帶線（外層）、sl＝帶狀線（內層，上下都有參考層） | ms |
| mode | No | diff＝差動對、single＝單線 | diff |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the method (2D electric-field solver), that copper thickness is accounted for, and that results come with an applicability range, which is genuine behavioral context; but it omits accuracy caveats, unit conventions, or failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences front-loaded with the method and the computed quantities, followed by a short note on the return. No filler; each clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description helpfully notes that the return carries an applicability range, and the well-documented schema covers geometry and mode selection. For a pure computation tool this is nearly complete, lacking only accuracy/assumption caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all nine parameters including their roles for ms/sl and diff/single. The description adds nothing parameter-specific beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (numerically solving) and resource (differential/single-ended impedance of microstrip or stripline), plus the exact outputs Zdiff/Zcomm/odd-even/Z0. It clearly distinguishes itself in substance from siblings like crosstalk and diff_skew, though it does not name those siblings explicitly to route the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: compute impedance for a chosen line kind (kind) and mode (mode), which the description enumerates. However, there is no explicit guidance on when to reach for this tool versus siblings such as crosstalk or diff_skew, nor any prerequisites or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
負載開關控速上升時的充電電流、峰值電流、能量與脈衝 I²t（mode=slew），或電容直接接電源時的串聯 R-L-C 步階電流（mode=direct）。
| Name | Required | Description | Default |
|---|---|---|---|
| ct | No | CT 腳電容（ctsel≠none 時用）（pF） | |
| lh | No | 線路電感（direct）（nH） | |
| rl | No | 負載電阻（0＝不接）（Ω） | |
| rs | No | 線路＋電源內阻（direct）（mΩ） | |
| tr | No | 輸出上升時間（10–90%，ctsel=none 時用）（µs） | |
| esr | No | 電容 ESR（direct）（mΩ） | |
| vin | No | 輸入電壓（V） | |
| cout | No | 輸出電容（µF） | |
| mode | No | slew＝負載開關控速、direct＝直接接電容 | slew |
| ctsel | No | 用 CT 腳電容決定上升時間：none／t918／t965 | none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the output quantities per branch: charging current, peak current, energy and pulse I²t for slew; series R-L-C step current for direct. It says nothing about units, sign conventions, or any failure/limit behavior, so the disclosure is partial rather than rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no preamble, front-loading the slew case before the direct case and using the mode values as anchors. It is dense with parentheticals but each clause carries information; no filler sentences to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Ten parameters with defaults and no output schema, so the description must at least tell the agent what comes back — which it does at a high level. It omits the conditional parameter interactions (ctsel≠none uses ct, ct=220 requires tr) beyond what the schema already notes, so it is adequate but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all ten parameters, including the ct/ctsel and tr conditionality. The description adds only the high-level slew/direct semantics, duplicating the mode parameter's own schema description rather than extending it. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the computed resource (inrush current metrics) and splits it into two clearly-scoped operating regimes (mode=slew vs mode=direct), which no sibling covers. It stops short of an explicit verb like "計算/compute" — it reads as a noun list of outputs rather than "this tool calculates X" — but an agent can still identify the tool unambiguously against crosstalk, impedance, xtal_load_cap, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical mappings (slew＝負載開關控速, direct＝電容直接接電源) effectively tell the agent which mode corresponds to which physical scenario, which is real usage context. However, there is no explicit when-to-use/when-not framing for the tool itself and no exclusion of cases (e.g. what to do when ct is not used), leaving selection guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
回授電阻分壓的輸出電壓：最壞情況（每項取上下限的所有組合）、RSS 統計；可選蒙地卡羅超規比例。
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | 蒙地卡羅次數 | |
| dt | No | 溫差（°C） | |
| r1 | No | 上電阻 R1（kΩ） | |
| r2 | No | 下電阻 R2（kΩ） | |
| tc | No | 電阻溫漂（ppm/°C） | |
| tr | No | 電阻公差 ±（%） | |
| ifb | No | 回授腳偏壓電流（典型）（nA） | |
| dist | No | 蒙地卡羅的誤差分布 | normal |
| tifb | No | 回授腳偏壓電流（最大偏離）（nA） | |
| tref | No | VREF 精度 ±（%） | |
| vmax | No | 允許的輸出上限（V） | |
| vmin | No | 允許的輸出下限（V） | |
| vref | No | 參考電壓 VREF（V） | |
| track | No | 1＝兩顆電阻溫漂同向（互相抵消） | |
| monte_carlo | No | true＝多跑蒙地卡羅（固定亂數種子，可重現） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the analytical methods performed (worst-case, RSS, Monte Carlo) and its optional nature, but says nothing about defaults, computational cost, or the reproducibility note that only appears in the schema. Useful but thin for a 15-parameter computation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense sentence that front-loads the core concept (feedback divider output voltage) before listing the analysis modes. Nothing is redundant, though the terseness leaves little room for routing or output context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, no annotations, and no output schema, the description should explain more about what results come back (worst-case limits, RSS sigma, Monte Carlo out-of-spec fraction). It gestures at the outputs but does not fully stand in for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all 15 parameters are documented inline (R1/R2, VREF, temp drift, bias current, etc.), so the schema does the heavy lifting. The description adds no parameter semantics beyond what the schema already provides, which is the expected baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the concrete resource and computation: output voltage tolerance of a feedback resistor divider, plus the three analysis methods (worst-case over all limit combinations, RSS, optional Monte Carlo out-of-spec ratio). This clearly separates it from siblings like impedance or inrush_current. The computing verb is only implied, but the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use statement or routing to alternatives; usage is inferred from the analytical modes mentioned. For a self-contained engineering calculator whose siblings are unrelated analyses, the implied context is adequate, but nothing tells the agent when this tool is preferred over a different tolerance approach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
外掛電容 C1、C2 與雜散電容算出實際負載電容 CL、頻率偏移 ppm、振盪增益餘裕、驅動功率，並給出剛好對上規格 CL 的電容值。
| Name | Required | Description | Default |
|---|---|---|---|
| f | No | 晶振頻率（MHz） | |
| c0 | No | 並聯電容 C0（pF） | |
| c1 | No | 外掛電容 C1。2026-10-12 起預設 26 pF（原 30 pF），配合 cs 預設 5 pF 讓 CL＝18 pF（pF） | |
| c2 | No | 外掛電容 C2。2026-10-12 起預設 26 pF（原 30 pF），配合 cs 預設 5 pF 讓 CL＝18 pF（pF） | |
| cm | No | 動態電容 Cm（fF） | |
| cs | No | 雜散電容（腳位＋走線）。2026-10-12 起預設 5 pF（原 3 pF），出處 ST AN2867／TI SLLA122（pF） | |
| gm | No | 晶片振盪器跨導 gm（mA/V） | |
| cls | No | 晶振規格的負載電容 CL（pF） | |
| esr | No | 等效串聯電阻 ESR（最大值）（Ω） | |
| vpp | No | C1 那端的峰對峰電壓（算驅動功率用）（V） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the burden. It enumerates the computed outputs (a useful stand-in for the missing output schema) but never states that the tool is a pure, side-effect-free calculation, nor any assumptions or model limitations (e.g. which formulas/sources are used). Mutation risk is low for a calculator, but the disclosure is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the inputs (external caps, stray capacitance) and then lists the resulting quantities. No filler, though the run-on enumeration of four outputs makes it slightly harder to scan than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter, no-annotation, no-output-schema calculator, the description usefully covers the return values and the input concept. However it omits usage context, assumptions, and the fact that all parameters are optional with sensible defaults — gaps an agent would otherwise have to discover from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with per-parameter units, ranges and even default-change notes in the schema itself, so the schema does the heavy lifting. The description only gestures at C1, C2 and stray capacitance conceptually and adds no syntax or modeling detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (算出) and enumerates the concrete quantities produced: actual load capacitance CL, frequency offset in ppm, oscillation gain margin, drive power, and the cap values matching the spec CL. This is clearly distinguishable from generic EE calculators, though it never names any sibling tool (crosstalk, impedance, etc.) to sharpen the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what is computed but nothing about when to reach for this tool versus the sibling calculators, nor what prerequisites (e.g. knowing the crystal's spec CL or gm) are needed. An agent must infer the scenario from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
diff_skew1 field changedInput schema / properties / limAdded value: +{
+ "default": 0,
+ "description": "對內長度差上限（ps）。0 或不帶＝用介面預設（USB3／PCIe 業界經驗值 5 mil）；DP／HDMI 沒有預設，請填晶片廠或規範給的值，沒帶時 limit_ps 回 null（ps）",
+ "maximum": 1000,
+ "minimum": 0,
+ "type": "number"
+}xtal_load_cap3 fields changedInput schema / properties / c1 / defaultPrevious value: -30New value: +26Input schema / properties / c2 / defaultPrevious value: -30New value: +26Input schema / properties / cs / defaultPrevious value: -3New value: +5xtal_load_cap3 fields changedInput schema / properties / c1 / descriptionPrevious value: -"外掛電容 C1（pF）"New value: +"外掛電容 C1。2026-10-12 起預設 26 pF（原 30 pF），配合 cs 預設 5 pF 讓 CL＝18 pF（pF）"Input schema / properties / c2 / descriptionPrevious value: -"外掛電容 C2（pF）"New value: +"外掛電容 C2。2026-10-12 起預設 26 pF（原 30 pF），配合 cs 預設 5 pF 讓 CL＝18 pF（pF）"Input schema / properties / cs / descriptionPrevious value: -"雜散電容（腳位＋走線）（pF）"New value: +"雜散電容（腳位＋走線）。2026-10-12 起預設 5 pF（原 3 pF），出處 ST AN2867／TI SLLA122（pF）"crosstalkdiff_skewimpedanceinrush_currentoutput_voltage_tolerancextal_load_cap88 free engineering calculators: RF link budgets, LoRa/Meshtastic, PCB, solar, homelab. Keyless.
NEC 2023 electrical calculators: wire size, ampacity, voltage drop, conduit fill, box fill, load.
5,400+ manufacturing calculators plus live U.S. tariff, PMI, cost-index, wage, and forecast data.
Free VAT, card fee, loan, mortgage, margin, ROI and break-even calculators plus IBAN/SWIFT checks
Add one secure layer between your agents and this server.
