Skip to main content
Glama
sheares

easyeda-mcp-fix

by sheares

pcb_export_to_file

Export PCB designs in Gerber, ODB++, 3D STEP, or PDF directly to a local file path, avoiding large Base64 data in MCP responses.

Instructions

Export the PCB design in various formats directly to a local file path — preferred over pcb_export when the output is large (gerber/odbplus zips, 3d STEP, pdf), since it avoids shipping the bytes back through the MCP response as Base64.

BEFORE generating any fabrication output: run pcb_run_drc (and sch_run_drc) and resolve all violations. Clearance DRC alone is not sufficient — include connectivity/No-Connection checks; see pcb_export for why.

Returns { saved: path, size, originalName, format }.

Formats: same as pcb_export. See pcb_export for option shapes.

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 every layer in use that is a copper (signal or plane), silkscreen, solder-mask or paste-mask layer, plus the board outline. Layers that are in use but hidden in the editor are still included; unused layers and assembly/document layers are not — 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

NameRequiredDescriptionDefault
formatYesExport format
optionsNoFormat-specific options passed through to the underlying EasyEDA call.
documentYesTarget document UUID — auto-switches to this document before executing. Get UUIDs from list_instances or editor_get_open_tabs.
filePathYesAbsolute path to write the exported file to
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 only declare readOnlyHint=false and destructiveHint=false; the description goes well beyond by naming the exact return shape, disclosing the layer-selection default behavior (including hidden-but-used layers, excluding unused/assembly layers, unlike EasyEDA's raw default), and warning that option keys cannot override document/instance_id routing. This is rich behavioral context not present in structured 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?

Front-loaded with the routing decision, precondition, and return shape before the dense format table, so the important content comes first. It is long, and 'See pcb_export for option shapes' followed by the full shapes is slightly redundant, but the length is largely justified by the format complexity.

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?

Despite no output schema, the description specifies the return object fields, preconditions, default behaviors, and the routing-field precedence caveat. For a multi-format export tool with a nested options object, nothing essential for correct invocation is missing.

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?

Although schema coverage is 100%, the schema's options object is empty and untyped, so the description carries the real semantics: per-format option shapes, the literal unit strings "mm"/"inch"/"mil", and default layer behavior for gerber/odbplus. It adds substantial meaning beyond what the schema exposes.

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 (export the PCB design to a local file path) and immediately distinguishes itself from the sibling pcb_export by the file-path vs. Base64-response difference. An agent can pick this over pcb_export 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?

Explicitly states when to prefer this over pcb_export (large outputs: gerber/odbplus zips, 3d STEP, pdf), gives a mandatory precondition workflow (run pcb_run_drc and sch_run_drc, include connectivity checks), and notes options can be omitted for defaults. When-to-use, when-not, and alternatives are all covered.

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