diff_skew兩條線的長度差換成時間差（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 |
Changes observed during successful MCP inspections.
Input 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"
+}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.
Add one secure layer between your agents and this server.