Skip to main content
Glama
sheares

easyeda-mcp-fix

by sheares
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

pcb_export

Read-onlyIdempotent

Export PCB designs to gerber, BOM, pick-and-place, 3D, PDF, netlist, and other fabrication formats as Base64 data, with optional sub-formats and layer options.

Instructions

Export the PCB design in various formats. Returns { fileName, data (Base64), size }.

BEFORE generating any fabrication output (gerber, odbplus, drill, pick_and_place): run pcb_run_drc (and sch_run_drc) and resolve all violations. Clearance DRC alone is not sufficient — this fork exists partly because API-drawn tracks passed clearance DRC while being electrically dead to their SMD pads; only a No-Connection/connectivity check surfaced it. Include connectivity checks in the DRC run before shipping.

Formats: dsn (for FreeRouting), gerber (manufacturing), bom (bill of materials), pick_and_place (assembly), 3d (STEP/OBJ), pdf, netlist, dxf, altium, pads, odbplus (ODB++ archive with stackup+nets), ipc_d_356 (netlist test format), flying_probe, test_point, autoroute_json, autolayout_json. Use fileType for sub-formats: "xlsx"/"csv" (bom, pick_and_place, test_point), "step"/"obj" (3d).

WARNING: response is Base64 in the MCP reply — for large outputs (gerber zips, 3d STEP) prefer pcb_export_to_file which writes straight to disk.

Most formats accept extra options forwarded as-is to the underlying EasyEDA getXxxFile call. Common ones (unit values are the literal strings "mm" / "inch" / "mil"): gerber: { unit: "mm" | "inch", colorSilkscreen, digitalFormat: {integerNumber, decimalNumber}, other: {metallicDrillingInformation, nonMetallicDrillingInformation, drillTable, flyingProbeTestingFile}, layers: [{layerId, isMirror}], objects: [...] } odbplus: { unit: "inch", otherData: {metallizedDrilledHoles, nonMetallizedDrilledHoles, drillTable, flyingProbeTestFile}, layers: [{layerId, mirror}], objects: [{objectName}] } pick_and_place:{ unit: "mm" | "mil" } 3d: { element: [...], modelMode: "Outfit" | "Parts", autoGenerateModels } bom: { template, filterOptions, statistics, property, columns } dxf: { layers: [{layerId, mirror}], objects: [...] } Omit options to get sensible defaults. For gerber and odbplus, omitting layers exports all enabled copper (Top, Bottom, and any Inner1..InnerN that are enabled) plus the standard silk/mask/paste/outline aux layers — unlike EasyEDA's raw default which silently drops inner copper even on 4L+ boards.

CAUTION: options keys cannot override the top-level document/instance_id routing fields — those always take precedence to prevent accidental cross-document export.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatYesExport format
optionsNoFormat-specific options passed through to the underlying EasyEDA call. See tool description for shape per format.
documentYesTarget document UUID — auto-switches to this document before executing. Get UUIDs from list_instances or editor_get_open_tabs.
fileNameNoOutput file name
fileTypeNoSub-format (e.g. "xlsx"/"csv" for bom, "step"/"obj" for 3d)
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. First observedv1.6.5

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive), but the description adds substantial behavior beyond them: the exact return shape, the Base64-in-reply caveat, the fact that omitted `layers` exports all enabled copper including inner layers (contrasting EasyEDA's raw default), and the CAUTION that options keys cannot override routing fields.

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?

Long, but front-loaded with purpose and return shape, then organized into clear labeled sections (formats, WARNING, per-format options, CAUTION). The per-format option reference is dense but justified because the schema cannot express it; slightly heavy, keeping it from a 5.

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?

No output schema exists, yet the description states the return shape ({ fileName, data, size }). For a 16-format export tool with a free-form options object, it covers defaults, sub-formats, the disk-write alternative, and the DRC prerequisite — everything needed to call it correctly.

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

Parameters5/5

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

The schema documents the top-level params but leaves `options` as an empty free-form object (additionalProperties only), so the description carries the burden of documenting per-format option shapes (gerber, odbplus, pick_and_place, 3d, bom, dxf), unit value literals, and fileType sub-format values. This is meaning well beyond the schema.

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?

Opens with a specific verb+resource ("Export the PCB design") and immediately scopes the output formats. It also implicitly distinguishes itself from the sibling pcb_export_to_file by noting that this one returns Base64 in the reply while the sibling writes to disk.

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?

Explicitly states prerequisites before fabrication output (run pcb_run_drc and sch_run_drc, resolve all violations, include connectivity checks) and names the alternative (pcb_export_to_file) with the condition that selects it (large gerber/3d outputs). Format-by-format guidance is given inline, so the agent knows which value to pick for which goal.

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