Skip to main content
Glama
sheares

easyeda-mcp-fix

by sheares
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

pcb_export_to_file

Export PCB designs in formats such as Gerber, ODB++, 3D STEP, or PDF directly to a local file path, avoiding large Base64 payloads in the MCP response.

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 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.
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 declare only the safety profile (readOnly=false, destructive=false, idempotent=false); the description adds substantial behavior beyond them: the Base64-avoidance rationale, the exact return shape {saved, size, originalName, format}, the non-obvious default that omitting `layers` exports all enabled inner copper unlike EasyEDA's raw default, and a caution that options keys cannot override routing fields. No contradiction with annotations.

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 and the DRC prerequisite before the format detail, and the return shape is stated compactly. It is long and repeats the 'see pcb_export' pointer twice, but nearly every sentence carries distinct information, so the length is largely earned.

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 6-param export tool with no output schema and a free-form options bag, the description supplies everything needed: prerequisites, return shape, per-format option contracts, default-selection behavior, and a routing caution. Nothing material is missing for correct invocation.

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?

Schema coverage is 100% for named params, but the most complex parameter (`options`) is an empty additionalProperties object in the schema, so the description is the sole source of its semantics. It documents per-format option shapes for gerber, odbplus, pick_and_place, 3d, bom, and dxf, specifies unit values as literal strings, and states default behavior — far beyond what the schema conveys.

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+destination ('Export the PCB design ... directly to a local file path') and explicitly distinguishes itself from the sibling pcb_export by naming the condition that selects it (large outputs). An agent can route between the two tools 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 explicit when-to-use ('preferred over pcb_export when the output is large — gerber/odbplus zips, 3d STEP, pdf') and a hard precondition ('BEFORE generating any fabrication output: run pcb_run_drc (and sch_run_drc) and resolve all violations', plus 'Clearance DRC alone is not sufficient'). Alternatives and exclusions are both named.

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