eda_pcb_math_polygon_trace_image

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

No annotations are present, so the description carries the burden; it discloses that the call is preview-only, caches image pixels server-side, cannot rely on browser Image/canvas APIs, and returns undefined for empty traces. However, the width/height semantics are internally contradictory — one remark says original natural size, while the returns section says trace-bbox normalized to a 300px base — which weakens the transparency.

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 long and dense, but it is structured around signature, remarks, version, and returns, with almost every sentence carrying operational value. Minor extras like the ADD since EDA v5 line and repeated no-placement clarification keep it from a 5, but it is well front-loaded with purpose and workflow.

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?

Given that there is no output schema, the description does a good job covering return fields, the undefined edge case, the caching/lifecycle behavior, and the placement handoff. The contradictory width/height explanation and the unexplained tuning parameters are the main remaining gaps.

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?

The schema only exposes an args array and windowId, so the description adds real value by listing the actual options and types and explaining the imageBlob lifecycle. Individual tuning parameters such as tolerance, simplify, smoothness, despeckle, and antiphase still lack definitions, units, or ranges, but the names and context provide reasonable guidance.

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 specific action — '将图片描摹为矢量路径（SVG path），并导出预览图' — and explicitly differentiates this tool from placement tools by calling it a pure preview interface that does not trigger any placement operation. It also names the separate placement interface, distinguishing it clearly from siblings like eda_pcb_image_tool_start_place_vector_image.

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 concrete workflow guidance: first call must pass imageBlob, subsequent drag interactions pass only parameters, and placement is handled separately by eda.pcb_ImageTool.startPlaceVectorImage. It does not enumerate exclusions or compare with other image-processing siblings, but the context is clear and actionable.

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