Skip to main content
Glama
sheares

easyeda-mcp-fix

by sheares

sch_swap_supplier_part

Destructive

Bulk-swap supplier metadata on schematic components matching a filter for drop-in replacements; dry-run first, then export BOM to confirm integrity.

Instructions

Bulk-swap supplier metadata on schematic components matching a filter. WARNING (field-confirmed): this swaps supplier METADATA only. The canvas symbol and its label stay those of the OLD part. Use this ONLY when the replacement is a true drop-in with identical schematic symbol and PCB footprint (e.g. same 100nF 0603 cap in a different reel). For any part with a different symbol, footprint, or pin count, delete the component and re-add it instead — otherwise the schematic and BOM will disagree with the canvas symbol/label. Uses the same bug-1 metadata guard as sch_modify_component: unspecified fields (otherProperty, uniqueId, position, symbol, etc.) are preserved via a snapshot-and-merge round trip, so a swap that only touches supplierId doesn't wipe the rest of the BOM row. Non-dry-run swaps snapshot first: the active document (or, with allSchematicPages, the whole project) is committed to the local backup repo before any write, and the response includes the backup SHA. Note the multi-page walk is not atomic — if a page fails to open mid-walk the swap aborts with earlier pages already written; use the backup SHA to recover. Typical uses: rotate to a cheaper LCSC alt (match: {supplierId: "C25804"}, replace: {supplierId: "C17414", manufacturerId: "..."}), or bulk-tag a designator prefix (match: {designator: "R*"}, replace: {manufacturer: "YAGEO"}). match: filter fields with the same semantics as read-tool filter — exact string, ["a","b"] OR-array, or "prefix*" glob. Any component field is accepted (designator, supplierId, manufacturerId, manufacturer, ...). Matching runs against RESOLVED values: fields stored as ={...} template expressions are resolved from the netlist before the filter applies, matching what sch_get_all_components shows. If the netlist cannot be fetched, matching falls back to raw stored values. replace: at least one of supplierId, manufacturerId, manufacturer, supplier. dryRun: if true, returns the matches with before/after but does NOT modify (and takes no backup). Recommended for the first pass. allSchematicPages: walk every schematic page instead of only the active one; original page is restored. Returns { dryRun, swappedCount, swapped:[{primitiveId, designator, page, before, after}], backup? }. Always re-run sch_export_bom afterward to confirm BOM integrity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
matchYesFilter fields to match components on (exact, OR array, or "prefix*" glob).
dryRunNoIf true, return matches with before/after but do not modify. Recommended for first pass.
refreshNoIf true, bypass the netlist cache when resolving ={...} templates for matching. Use after editing the schematic directly in the EasyEDA UI.
replaceYesSupplier metadata to overwrite on matched components. At least one field required.
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.
allSchematicPagesNoWalk all schematic pages (defaults to active page only)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.6.5

TDQS

A4.8/5.0
Behavior5/5

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

Despite annotations already declaring destructiveHint=true and idempotentHint=false, the description adds critical context they cannot convey: the swap touches metadata only while the canvas symbol/label stay the OLD part, the bug-1 snapshot-and-merge preservation behaviour, the pre-write backup commit with a returned SHA, and the non-atomic multi-page walk that can leave earlier pages written. This is exactly the material an agent needs before invoking a destructive tool.

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-loads the critical metadata-only warning before mechanics, and each paragraph carries non-redundant information. It is long for a tool description and has a little overlap between the match-semantics sentence and the earlier filter reference, but the length is justified by the destructive, multi-parameter nature of the operation.

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?

Covers the full lifecycle for a complex, destructive tool: warnings, preservation semantics, backup/recovery via SHA, dry-run workflow, page-walking caveat, and even the return shape ({dryRun, swappedCount, swapped, backup?}) plus a verification follow-up, so nothing an agent needs to call it correctly is missing.

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 description coverage is 100%, so baseline is 3, but the description adds real meaning: match accepts exact strings, OR-arrays and 'prefix*' globs against any component field, matching runs against netlist-resolved values with fallback to raw stored values, and replace requires at least one of the four supplier fields. It leaves document, instance_id and refresh entirely to the schema, which keeps it short of a 5.

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 and scope: 'Bulk-swap supplier metadata on schematic components matching a filter.' It also explicitly distinguishes itself from sch_modify_component by naming that sibling and sharing its metadata guard, so the agent can tell these apart without opening either schema.

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

Usage Guidelines5/5

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

Gives both when-to-use ('true drop-in with identical schematic symbol and PCB footprint') and when-not-to-use ('For any part with a different symbol, footprint, or pin count, delete the component and re-add it instead'), names the concrete alternative workflow, and recommends dryRun for the first pass with a follow-up sch_export_bom call.

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