Skip to main content
Glama
sheares

easyeda-mcp-fix

by sheares
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

project_import_file

Destructive

Import .epro, Altium, KiCad, EAGLE, PADS, or LTspice project files from a local path into EasyEDA Pro. Create a new project or replace an existing one; prior state is backed up automatically.

Instructions

Import a project file (.epro) from a local path into EasyEDA Pro. Can import into an existing project (replacing its contents) or create a new project. A new project is saved to the same team/workspace as the project open in the target window (on the desktop client, the local projects folder); open any project there first. Supports EasyEDA Pro, Altium, KiCad, EAGLE, PADS, and LTspice formats. When importing into an existing project (existingProjectUuid set), a backup of the prior project state is taken automatically and committed to a local git-tracked repo — the returned backup.sha references the pre-import state.

FAST-BATCH WORKFLOW: for making many changes at once, it is much faster to export the document or project (document_save_to_file / project_export_file), edit the raw source on disk, then re-upload (document_load_from_file / project_import_file) than to issue many small per-primitive MCP calls. Formats differ: on EasyEDA Pro 3, document_save_to_file returns {header}||{body} lines, while the .epro from project_export_file holds newline-delimited JSON arrays, which is what the src/lib editing library reads. Every destructive upload is auto-backed-up to a local git repo first — the response includes a backup SHA you can use to find the prior state if the edit goes wrong. Upload tools accept validate='off'|'warn'|'strict' (default 'strict') which runs the Zod schema on the new source — see document_validate for standalone validation.

Input Schema

NameRequiredDescriptionDefault
filePathYesAbsolute path to the .epro file to import
fileTypeNoSource format (default: EasyEDA Pro)
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.
newProjectNameNoDisplay name for a new project. If omitted, EasyEDA takes it from the file.
existingProjectUuidNoUUID of existing project to import into. If omitted, creates a new project.
newProjectOwnerTeamUuidNoTeam uuid to own a new project. If omitted, the open project's team is used.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.6.5

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description adds real value on top: automatic backup of the prior state into a local git-tracked repo with a returned backup.sha, plus the validate='off'|'warn'|'strict' behavior. It stops short of describing failure modes (what happens on a bad .epro or partial import).

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?

The core behavior and mode selection are front-loaded and efficient, but the large FAST-BATCH WORKFLOW paragraph mixes in details that belong to sibling tools (document_save_to_file output shapes, the src/lib editing library) rather than this tool's contract.

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

Completeness4/5

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

For a destructive, 6-parameter import with no output schema, the description covers modes, prerequisites, supported formats, backup semantics and the returned backup SHA, which is close to complete. The unresolved validate parameter and unstated error behavior keep it from a 5.

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 the parameters are already documented, but the prose adds meaning by tying existingProjectUuid to the backup-the-previous-state consequence and explaining defaulting behavior for newProjectName/newProjectOwnerTeamUuid. It also references a validate option that is not present in the schema, which creates minor ambiguity.

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 ('import a project file (.epro) from a local path into EasyEDA Pro') and immediately clarifies the two operating modes (replace existing project vs create new). It is clearly distinguishable from the sibling export/upload tools (project_export_file, document_load_from_file) without opening any 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?

Explicit when-to-use for both branches: setting existingProjectUuid imports-and-replaces, omitting it creates a new project, and it supplies the prerequisite 'open any project there first' so the new project lands in the right team/workspace. It also routes the agent to the faster batch alternative (export/edit/re-upload) and to document_validate for standalone checks.

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