Electronics API + MCP: modal dialogs block scripts, no undo for Electron.run edits

[aske.carstensen]

i Fusion Team,

I use the Fusion MCP connector with Claude Desktop to edit electronics schematics (Fusion 2705.1.25, Windows). Reading through adsk.electron works well. Since the electronics API is read-only, every edit goes through app.executeTextCommand('Electron.run ...'). That works, but five things make it fragile:

1. Modal dialogs block everything. An error raised by an Electron.run command, for example a NETROUTE syntax error, opens a modal dialog. Every following script is refused with "Cannot perform 'script' while a command dialog is open" until a person closes it. SET CONFIRM NO does not suppress these error dialogs. Request: for API-initiated commands, return the error to executeTextCommand as a string or exception instead of showing a dialog.

2. A selection window can hang Fusion. ADD with a wildcard that matches several devices opens the library browser inside the script, and Fusion's main thread waits until someone cancels it. Request: never open selection UI for API-initiated commands, fail with an error instead.

3. No undo for Electron.run edits. They don't appear on Fusion's undo stack, and UNDO through Electron.run has no effect. One wrong wire means manual cleanup. Request: put these edits on the undo stack, ideally one entry per script. Should Schematic.beginDesignChange / endDesignChange cover this?

4. Hidden armed state. After some commands (ADD, or DELETE without a trailing semicolon) writes are refused while activeCommand reports Electron::Group and nothing is visible on screen. Calling ui.terminateActiveCommand() at the end of each script prevents it, and saving clears it. Request: make activeCommand reflect an armed EAGLE tool.

5. No screenshots of electronics editors. The MCP screenshot call returns "No active graphics view available" when a schematic or PCB is active, so an agent cannot check its own layout work visually. Request: support MCP screenshots of the 2D schematic and PCB canvas, or an image export of a sheet or region (PNG or SVG) through Schematic.exportManager.

Is write support for the electronics API on the roadmap, and is there a recommended way to drive Electron.run safely until then?

best regards
Aske

[nnovotney]

to edit electronics schematics

Why aren't you using the editor? It should have most needed things available. 

What exactly are you trying to do--something other than fusion electronics design?

[jorge_garcia · Accepted solution]

Hi @aske.carstensen ,

I hope you're doing well. The write API is actually planned to be released in the very near term, I have shared this thread with the devs working on the API to make sure these concerns get addressed as soon as possible.

If there is some other workaround right now, those devs would know.

Let me know if there's anything else I can do for you.

Best Regards,

[JohnLauer_Adom]

Hi Aske, disclosure: I run Adom. We make a free, MIT-licensed Fusion add-in and local bridge that lets an AI drive Fusion Electronics end to end, and over the last five months we have hit your whole list.

Jorge's news is good: when Autodesk's electronics write API lands, we will build on it, and on Autodesk's MCP servers, because native support makes all of this simpler. But to your closing question, yes, you can drive Electron.run safely today. Here is how, point by point:

1. Modal dialogs. Before each command we read every open Fusion dialog through Windows UI Automation (title, text, buttons), answer the ones we recognise, cancel unknown ones in the background, and hand the text back to the agent instead of hanging. One warning: Fusion's floating Browser panel is also titled "Fusion360", and closing it can close Fusion, so only close windows that are plainly dialogs.
2. The library browser from ADD. The same path cancels it. We have a short demo of exactly this: a script runs ADD, the picker blocks it, the bridge reads the dialog and cancels it in the background, and the script carries on. Better still, we never need ADD: we write parts as EAGLE source and open it with Document.newDesignFromLocal, which raises no dialog.

1. Undo. Nothing native for Electron.run edits yet, so we save checkpoints before each batch.
2. The armed state. Your terminateActiveCommand workaround matches ours.
3. Screenshots of the 2D editors. We capture the Fusion window itself, which works on schematics and boards, even with Fusion in the background. Every Fusion frame in our demos is captured that way.

Putting it together, here is our demo of one prompt writing electronics end to end: it opens a parts library, writes a schematic, places the parts on a 2D board and checks the 3D board, with no dialogs and no hands on the mouse.

One more wall you will hit once you write designs, not on your list: parts need 3D models, and attaching STEP models to a multi-part library is where we spent the most time. Three traps: a raw STEP bound by urn shows "Thumbnail download failed" (only an .f3d renders); the 3D package generator's FINISH opens modals no script can close; and the generator loads the first package of the open library, so every chip lands on part one's footprint. What works, in this order: one library per part, start the generator on it, import the STEP, Save As an .f3d instead of FINISH, build the urn from the cloud lineage id, then write every urn into the merged library in one pass. Our demo of that, six parts bound and checked:

The source is public, with a contributing guide if you want to send fixes back: wiki.adom.inc/adom/fusion-bridge. Happy to compare notes, and thanks Jorge for passing these to the API team.

[jorge_garcia]

Hi @JohnLauer_Adom ,

I hope you're doing well. Thanks for sharing this, I had never heard of your bridge. It looks excellent and I look forward to what you will do once the full API is out.

Best Regards,