Calculates the bounding-box height of a polygon from its source-array coordinates in your active EasyEDA Pro window. Returns the numeric height for layout and math operations.
pcb_MathPolygon.calculateBBoxHeight(complexPolygon: TPCB_PolygonSourceArray | Array) -> number 计算多边形源数组的 BBox 高度
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | 按官方签名顺序排列的JSON参数数组 | |
| windowId | No | 目标EDA窗口ID；省略时使用当前活动窗口 |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are none, so the description carries the burden. It reveals the function signature and that it returns a number, but does not explain units (likely PCB units or mm/mm?), edge cases (empty arrays, malformed polygons), whether it mutates anything (read-only likely), or error behavior. Since no annotations exist, this is a significant gap.
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?
The description is short and front-loaded with the signature. However, it includes a bilingual signature line with no prose explanation, which is terse but not fully self-explanatory. It earns no extra credit for organization as it is just one line plus a minimal Chinese phrase.
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 computation tool with no output schema and no annotations, the description is thin. An agent does not know what the returned number represents in real units, whether it operates on the active document, or how to construct a valid TPCB_PolygonSourceArray. Sibling tools like calculate_width demonstrate that more context is possible.
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% for the args array and windowId, but the args items are unspecified ({}). The description lists the parameter type in the signature, which adds some meaning over the empty items schema. However, it does not explain the structure of TPCB_PolygonSourceArray or how multiple polygons are aggregated. Baseline 3 because the schema covers the outer parameters but the inner arg type is left undefined.
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 the function signature and states in Chinese that it computes the BBox height of a polygon source array. The verb 'calculate' and resource 'BBox height' are clear. It does not explicitly distinguish from siblings like calculate_width or calculate_height, but the name and phrasing make the distinction obvious.
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?
No guidance on when to use this vs. the sibling height/width/bbox tools. The description does not state whether the input is a single polygon or an array of polygons, though the signature shows both. No exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.