crosstalk兩條耦合線的串音：偶／奇模阻抗用 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 |
Changes observed during successful MCP inspections.
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.
Add one secure layer between your agents and this server.