Skip to main content
Glama
sheares

easyeda-mcp-fix

by sheares
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

pcb_manage_rule_config

Destructive

Manage DRC rule configurations in EasyEDA without risking preference corruption. Retrieve, save, apply, rename, delete, or set default rule sets for PCB design.

Instructions

Manage DRC rule configurations. Actions:

  • get_current_name: get current active config name

  • get_by_name: get config by name (configurationName)

  • get_all: get all configs (includeSystem optional)

  • save: save config under a name (ruleConfiguration, configurationName; allowOverwrite optional)

  • overwrite_current: apply a config to the open board (ruleConfiguration); the document is backed up first

  • rename: rename config (originalName, newName)

  • delete: delete config (configurationName)

  • get_default_name: get default config name

  • set_default: set as default (configurationName) Only pass a configuration EasyEDA returned: take pcb_get_design_rules().config (the {config, name} result is also accepted) and edit it in place. A hand-built or malformed configuration is rejected before it reaches EasyEDA, because a failed save can corrupt EasyEDA's rule-config preference and hang Design Rules in every project; if that happens the error says so and gives the repair steps. Warning (upstream EDA bug, pro-api-sdk issue #34): saved rule changes read back correctly but do NOT affect pour reflow until the PCB document is closed and reopened. Reopen the document before rebuilding pours.

Input Schema

NameRequiredDescriptionDefault
actionYesAction to perform
newNameNoNew name (for rename)
documentYesTarget document UUID — auto-switches to this document before executing. Get UUIDs from list_instances or editor_get_open_tabs.
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.
originalNameNoCurrent name (for rename)
includeSystemNoInclude system configs (for get_all)
allowOverwriteNoAllow overwrite (for save)
configurationNameNoConfig name
ruleConfigurationNoRule config object EasyEDA returned (for save, overwrite_current)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.6.9
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "get_current_name",
-  "get_by_name",
-  "get_all",
-  "save",
-  "rename",
-  "delete",
-  "get_default_name",
-  "set_default"
-]New value: +[
+  "get_current_name",
+  "get_by_name",
+  "get_all",
+  "save",
+  "overwrite_current",
+  "rename",
+  "delete",
+  "get_default_name",
+  "set_default"
+]
    • changedInput schema / properties / ruleConfiguration / description
      Previous value: -"Rule config object (for save)"New value: +"Rule config object EasyEDA returned (for save, overwrite_current)"
  2. First observedv1.6.5

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only give the generic destructive/idempotent hints, while the description adds concrete behavior: overwrite_current backs up the document first, malformed configs are rejected pre-flight, and a failed save can corrupt EasyEDA's rule-config preference and hang Design Rules in every project. It also discloses an upstream bug (pro-api-sdk #34) requiring document reopen before pour reflow, plus what the error message contains.

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 action list an agent needs first, followed by prerequisites and the bug warning; each sentence carries non-redundant information. The bug paragraph is long but justified given the corruption risk.

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

Completeness5/5

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

For a nine-parameter, multi-action destructive tool with no output schema, the description covers action selection, input provenance, side effects (backup), failure modes, and the post-save reopen requirement. Nothing an agent needs to invoke it safely is missing.

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

Parameters3/5

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

Schema description coverage is 100% and the schema already tags parameters with their target action ('New name (for rename)', 'Include system configs (for get_all)'), so the action-to-parameter mapping in the description adds little beyond what structured data already provides. Baseline 3 is appropriate.

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+resource ('Manage DRC rule configurations') and then enumerates all nine actions with their parameters, so an agent can tell it apart from read-only siblings like pcb_get_design_rules and from pcb_manage_net_rules. The scope is unambiguous.

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

Usage Guidelines4/5

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

The per-action breakdown effectively maps intent to action, and it gives a hard prerequisite: only pass a config EasyEDA returned via pcb_get_design_rules().config rather than hand-building one. It does not explicitly route the agent against sibling rule managers (net rules, net classes), so it falls short of the full 'alternatives' bar.

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