Skip to main content
Glama
sheares

easyeda-mcp-fix

by sheares
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

document_set_source

Destructive

Replace the entire source code of the active document. Overwrites all content, so retrieve the current source first; a backup is taken automatically.

Instructions

Replace the source code of the currently active document. Accepts the full document source as a string (same format returned by document_get_source). Returns { success, backup: { sha, path }, validation: {...} } on success, or throws if validation aborts the upload or the pre-edit backup could not be written. WARNING: This replaces the entire document. Always get the current source first, modify it, then set it back. A backup of the prior state is taken automatically before the replacement (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
sourceYesThe complete document source code to set
documentYesTarget document UUID — auto-switches to this document before executing. Get UUIDs from list_instances or editor_get_open_tabs.
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.8/5.0
Behavior5/5

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

Annotations already flag destructive=true, but the description adds substantial context: the automatic git-backed backup and its SHA, the fact that the entire document is replaced, that validation runs only for documentType 1 and 3, and that the call throws if validation aborts or the backup fails. This goes well beyond the safety hints.

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 core operation and a WARNING, followed by return/validation details and a batch workflow. However, the backup/git-repo/backup-SHA point is repeated near the end, adding mild redundancy in an otherwise dense and well-ordered description.

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 shape ({ success, backup: { sha, path }, validation }) and error/throw behavior, plus the validation applicability by document type. For a destructive mutation tool this is complete enough for correct invocation.

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 coverage is 100%, so baseline is 3. The description still adds value by noting the source format matches document_get_source's return, describing validate modes as running a Zod schema with 'strict' as default, and referencing list_instances/editor_get_open_tabs for UUIDs, which enriches the parameters beyond the schema text.

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 ('Replace the source code of the currently active document') and clarifies it accepts the full source string in the same format returned by document_get_source. An agent can immediately distinguish it from document_get_source and document_load_from_file.

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 covers when to use it (edit the current source, then set it back), when not to (many small changes should use export/edit/re-upload or per-primitive calls instead), and routes to siblings (document_validate for standalone validation, document_save_to_file/project_export_file for batch workflows). Nothing is left to inference.

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