Skip to main content
Glama
sheares

easyeda-mcp-fix

by sheares
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

pcb_create_region

Create a design rule region (keepout/constraint area) on a PCB to restrict components, wires, pours, or inner layers. Specify layer, polygon, and rule types.

Instructions

Create a design rule region (keepout/constraint area) on the PCB. The result is read back from the board, and notApplied lists any requested value EasyEDA did not keep (EasyEDA Pro 3.2.206 keeps the rule types but not regionName or lineWidth). 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.

Input Schema

NameRequiredDescriptionDefault
layerYesLayer 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.
polygonYesEither an ergonomic point array [{x, y}, ...] (minimum 3 points; the ring is closed automatically and converted to L-mode), or a raw EasyEDA L-mode source array [x1, y1, "L", x2, y2, ..., x1, y1] — coordinates of the first point, then the "L" token, then the remaining points (closed: last point repeats the first)
documentYesTarget document UUID — auto-switches to this document before executing. Get UUIDs from list_instances or editor_get_open_tabs.
ruleTypeNoRule type(s) for the region: "no_components" (2), "no_wires" (5), "no_fills" (6), "no_pours" (7), "no_inner_layers" (8), "follow_region_rule" (9), or the numbers. Names are converted to the numeric values EasyEDA requires; a string stored as-is makes EasyEDA save an empty rule.
lineWidthNoOutline width
regionNameNoName for the region
instance_idNoTarget 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.6.9
    • changedInput schema / properties / ruleType / description
      Previous value: -"Rule type(s) for the region"New value: +"Rule type(s) for the region: \"no_components\" (2), \"no_wires\" (5), \"no_fills\" (6), \"no_pours\" (7), \"no_inner_layers\" (8), \"follow_region_rule\" (9), or the numbers. Names are converted to the numeric values EasyEDA requires; a string stored as-is makes EasyEDA save an empty rule."
    • changedInput schema / properties / ruleType / items / type
      Previous value: -"string"New value: +[
+  "string",
+  "number"
+]
  2. First observedv1.6.5

TDQS

A4.3/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=false), and the description goes well beyond them by disclosing that the result is read back from the board and that notApplied reports values EasyEDA silently dropped, with a concrete version-specific example (rule types kept, regionName/lineWidth not). That partial-application behavior is exactly the kind of non-obvious trait an agent needs before relying on the call.

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?

Purpose is front-loaded in the first sentence, followed by return/notApplied behavior, coordinate semantics, and related-tool pointers. Four sentences with no filler; the cross-tool pointers are borderline but justified because the coordinate frame is otherwise ambiguous.

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?

There is no output schema, and the description partially compensates by describing the read-back result and the notApplied field, plus the coordinate frame for the 7-parameter, mutation-style call. It does not explain what happens on overlap with an existing region or confirm the exact return shape, leaving a small gap.

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 adds meaning the schema lacks: coordinates are PCB canvas coordinates in mil (1 mil = 0.001 inch), relative to the canvas origin, with +X rightward and +Y upward, and widths/diameters likewise in mil. It also points to pcb_canvas_origin and pcb_convert_coordinates for coordinate conversion, which helps interpret the layer/polygon inputs.

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?

States a specific verb and resource — 'Create a design rule region (keepout/constraint area) on the PCB' — with the parenthetical immediately disambiguating it from related primitives like pours and fills. An agent can tell this apart from pcb_create_pour, pcb_create_fill, and pcb_manage_rule_config 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?

The description gives coordinate-system context and routes the agent to pcb_canvas_origin and pcb_convert_coordinates for origin handling, which is useful 'how' guidance. However, it never states when to prefer this tool over pcb_create_fill/pcb_create_pour or pcb_manage_rule_config, nor any preconditions. Usage is implied rather than defined.

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

Deploy Server

Other Tools