Skip to main content
Glama
sheares

easyeda-mcp-fix

by sheares
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

document_load_from_file

Destructive

Load EasyEDA document source from a local file into the active document to replace contents for fast bulk edits, with automatic backup.

Instructions

Load document source from a local file and push it into the currently active document. Reads the file from disk and calls setDocumentSource to replace the document contents. The file must contain valid EasyEDA document source (same format as document_get_source / document_save_to_file). WARNING: This replaces the entire document. A backup of the prior state is taken automatically (after validation passes) and committed to a local git-tracked repo — the returned backup.sha references the pre-edit state. Validation runs for schematic and PCB documents (documentType 1 and 3); other types skip with a status.

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
documentYesTarget document UUID — auto-switches to this document before executing. Get UUIDs from list_instances or editor_get_open_tabs.
filePathYesAbsolute path to read the document source from
validateNoSchema validation mode for schematic uploads: 'off' skips entirely, 'warn' aborts only on malformed known tags or JSON parse errors, 'strict' (default) also aborts on any unknown-tag line.
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.6/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, but the description adds substantial context beyond them: the entire document is replaced, a backup is taken automatically only after validation passes, it is committed to a local git-tracked repo, and backup.sha references the pre-edit state. It also discloses that validation runs only for documentType 1 and 3 while others skip with a status.

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 purpose followed by a clearly labeled WARNING and FAST-BATCH WORKFLOW section, so the agent can scan for the relevant part. Slightly redundant: the auto-backup/git-repo point is stated twice, and the format-difference note is dense, but overall the length is justified.

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 destructive upload tool with no output schema, the description covers the full burden: safety/backup semantics, the returned backup.sha field, validation modes and their scope, format compatibility, and the bulk-edit workflow with siblings. Nothing an agent needs to call it safely is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so all four parameters (including the validate enum and instance_id) are already documented in the schema. The description reinforces validate behavior and the format expectations, but adds little param-level detail beyond the schema; baseline 3 is appropriate.

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 ('Load document source from a local file... push it into the currently active document') and explicitly links it to setDocumentSource. It distinguishes itself from document_set_source (which presumably takes inline source), document_save_to_file, and project_import_file, so an agent can route without opening schemas.

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 guidance via the FAST-BATCH WORKFLOW block, naming the alternatives (document_save_to_file / project_export_file to export, project_import_file as the project-level analogue) and the tradeoff (many small per-primitive MCP calls vs. bulk upload). It also points to document_validate for standalone validation.

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