easyeda-mcp-fix

Overview Schema Source Related Servers Discussions Admin

pcb_create_pad

Create a standalone pad on a PCB with configurable shape, hole, layer, and position in mil coordinates for SMD or through-hole designs.

Instructions

Create a standalone pad on the PCB. pad (the shape) is required; sizes and hole dimensions are in mil. Coordinates are PCB canvas coordinates in mil (1 mil = 0.001 inch), relative to the canvas origin: +X = rightward, +Y = upward. Lengths (widths, diameters) are also in mil. Use pcb_canvas_origin to read/set the origin offset and pcb_convert_coordinates to convert between canvas and data coordinates. Shapes: ['ELLIPSE'|'OVAL'|'NGON', width, height], ['RECT', width, height, cornerRadius], or ['POLYGON', source] where source is [{x, y}, ...] or a raw L-mode source array. Holes: ['ROUND', diameter] or ['SLOT', width, height]; null or omitted for an SMD pad. Examples:

SMD pad: layer 1, padNumber "1", pad ['ELLIPSE', 60, 60], hole null.
Through-hole pad: layer 12 (Multi), padNumber "1", pad ['ELLIPSE', 80, 80], hole ['ROUND', 35], metallization true.

Input Schema

Name	Required	Description
`x`	Yes	X coordinate
`y`	Yes	Y coordinate
`net`	No	Net name
`pad`	Yes	Pad shape: ['ELLIPSE'\|'OVAL'\|'NGON', width, height], ['RECT', width, height, cornerRadius] or ['POLYGON', source]. Mil.
`hole`	No	Drill hole: ['ROUND', diameter] or ['SLOT', width, height] in mil; null or omitted for an SMD pad
`layer`	Yes	Layer name (e.g. "TopLayer", "BottomLayer", "Inner1".."Inner30", "Multi") or numeric EPCB_LayerId (1=Top, 2=Bottom, 12=Multi). Names are converted to the numeric id EasyEDA requires.
`document`	Yes	Target document UUID — auto-switches to this document before executing. Get UUIDs from list_instances or editor_get_open_tabs.
`rotation`	No	Rotation angle in degrees
`padNumber`	Yes	Pad number/name
`holeOffsetX`	No	Hole X offset from the pad centre (mil)
`holeOffsetY`	No	Hole Y offset from the pad centre (mil)
`instance_id`	No	Target EasyEDA instance ID (8-char hex). Required when multiple instances are connected. Omit when only one instance is connected (auto-selected). Use list_instances to see connected instances.
`holeRotation`	No	Hole rotation in degrees
`metallization`	No	Whether the hole is plated (true for a normal through-hole pad)

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.6.9Oct 19, 2026

addedInput schema / properties / hole

Added value: +{
+  "anyOf": [
+    {
+      "anyOf": [
+        {
+          "additionalItems": false,
+          "items": [
+            {
+              "const": "ROUND",
+              "type": "string"
+            },
+            {
+              "type": "number"
+            }
+          ],
+          "maxItems": 2,
+          "minItems": 2,
+          "type": "array"
+        },
+        {
+          "additionalItems": false,
+          "items": [
+            {
+              "const": "SLOT",
+              "type": "string"
+            },
+            {
+              "type": "number"
+            },
+            {
+              "type": "number"
+            }
+          ],
+          "maxItems": 3,
+          "minItems": 3,
+          "type": "array"
+        }
+      ]
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Drill hole: ['ROUND', diameter] or ['SLOT', width, height] in mil; null or omitted for an SMD pad"
+}

addedInput schema / properties / holeOffsetX

Added value: +{
+  "description": "Hole X offset from the pad centre (mil)",
+  "type": "number"
+}

addedInput schema / properties / holeOffsetY

Added value: +{
+  "description": "Hole Y offset from the pad centre (mil)",
+  "type": "number"
+}

addedInput schema / properties / holeRotation

Added value: +{
+  "description": "Hole rotation in degrees",
+  "type": "number"
+}

addedInput schema / properties / metallization

Added value: +{
+  "description": "Whether the hole is plated (true for a normal through-hole pad)",
+  "type": "boolean"
+}

addedInput schema / properties / pad

Added value: +{
+  "anyOf": [
+    {
+      "additionalItems": false,
+      "items": [
+        {
+          "enum": [
+            "ELLIPSE",
+            "OVAL",
+            "NGON"
+          ],
+          "type": "string"
+        },
+        {
+          "type": "number"
+        },
+        {
+          "type": "number"
+        }
+      ],
+      "maxItems": 3,
+      "minItems": 3,
+      "type": "array"
+    },
+    {
+      "additionalItems": false,
+      "items": [
+        {
+          "const": "RECT",
+          "type": "string"
+        },
+        {
+          "type": "number"
+        },
+        {
+          "type": "number"
+        },
+        {
+          "type": "number"
+        }
+      ],
+      "maxItems": 4,
+      "minItems": 4,
+      "type": "array"
+    },
+    {
+      "additionalItems": false,
+      "items": [
+        {
+          "const": "POLYGON",
+          "type": "string"
+        },
+        {
+          "items": {},
+          "type": "array"
+        }
+      ],
+      "maxItems": 2,
+      "minItems": 2,
+      "type": "array"
+    }
+  ],
+  "description": "Pad shape: ['ELLIPSE'|'OVAL'|'NGON', width, height], ['RECT', width, height, cornerRadius] or ['POLYGON', source]. Mil."
+}

changedInput schema / required

Previous value: -[
-  "layer",
-  "padNumber",
-  "x",
-  "y",
-  "document"
-]New value: +[
+  "layer",
+  "padNumber",
+  "x",
+  "y",
+  "pad",
+  "document"
+]

First observedv1.6.5Oct 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations declare this is a non-readonly, non-destructive, non-idempotent write. The description adds real behavioral context the annotations don't: all lengths are in mil, coordinates are relative to the canvas origin with defined axes, hole null means an SMD pad, and metallization controls plating. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and required-param note, then organized into coordinates, shapes, holes, and examples. Slightly verbose in repeating the mil unit, but every section carries usable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter creation tool with no output schema, the description covers the hard parts (shape/hole grammars, units, coordinate frame, document context) and points at helpers. It does not touch net, rotation, or hole offsets, but those are documented in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description goes further by spelling out the exact shape and hole array grammars, the mil unit, the SMD-vs-through-hole distinction, and two concrete worked examples — meaning well beyond the terse schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb (Create) plus resource (standalone pad on the PCB). The word 'standalone' distinguishes it from pad-bearing primitives and siblings like pcb_create_via or pcb_create_region, so an agent can select it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the coordinate convention (canvas mil, +X right/+Y up) and routes the agent to pcb_canvas_origin and pcb_convert_coordinates for related work, plus worked examples. However it never states when to use this vs alternatives such as pcb_create_via or how pads relate to footprints/components, so selection guidance 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.

Deploy Server

pcb_create_pad

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools