Fusion MCP Feedback: Dialog Visibility Limitation with Claude Integration

thomas_badger62KKE — Thu, 07 May 2026 13:00:04 GMT

This post was written by Claude, but I mostly agree.

Hello Autodesk Team,

I am a structural CNC programmer using Autodesk Fusion 360 alongside Claude via the new Anthropic/Autodesk MCP connector. I want to share feedback from a real-world CAM workflow that I believe represents a significant opportunity to improve the integration.

The Fusion MCP connector is impressive — Claude can read model geometry, inspect CAM setups, check toolpath validity, read stock dimensions, detect errors across operations, and even manipulate certain CAM parameters via the API. For repetitive job setup workflows (we process CLT panels for CNC routing and sawing), this has real potential to save significant time.

However, there is a critical limitation: when a Fusion command dialog is open (e.g., a CAM operation editor for geometry selection), the MCP API blocks all screenshot access with the error:

"Cannot perform 'screenshot' while a command dialog is open. Close the active dialog and retry."

This means Claude goes completely blind at the most critical step — geometry selection. We cannot interactively guide or verify contour/edge assignments while the dialog is open.

To fully realize the potential of Claude as a CAM setup assistant, we would request the following API improvements:

1. Allow viewport screenshots while command dialogs are open
2. Expose current dialog state and active geometry selections via the MCP/API
3. Provide a read-only API for currently highlighted/selected geometry in the viewport during a dialog session

With these changes, Claude could act as a real-time CAM setup assistant — verifying correct geometry selection, catching errors before they happen, and guiding users through setup interactively. For high-volume structural CNC work, this would be a substantial productivity gain.

Thank you for building the MCP connector — it is already a powerful foundation. These additions would make it truly transformative for manufacturing workflows.

Re: Fusion MCP Feedback: Dialog Visibility Limitation with Claude Integration

kandennti — Thu, 07 May 2026 14:30:56 GMT

I also tried Fusion MCP with Claude Desktop a few days ago.

I get the feeling it uses the same MCP as Autodesk Assistant.

Unfortunately, Fusion crashed when I tried to create a new setup in the manufacturing module.

The crash itself wasn’t a big deal, but even after restarting both Fusion and Claude, Claude couldn’t find Fusion.

It seemed like changing the “Fusion MCP Server Port” might have fixed it, but in the end, I had to restart my PC.

One advantage over Autodesk Assistant is that it can load files.

I tried loading a drawing to see if I could create a model, but it started generating a significantly different shape, so I gave up.

Since the latest version of Claude consumes a lot of tokens, I don’t feel like trying again until an update is released.

Re: Fusion MCP Feedback: Dialog Visibility Limitation with Claude Integration

Sualp.Ozel — Thu, 07 May 2026 15:56:09 GMT

just an FYI: Autodesk assistant in Fusion can now also interact with local files on your hard disk.
To test it out you can send in a prompt such as "insert the image located on c:\temp\123.png as a canvas to my active design." you can also ask AA to describe what it sees in the image as well.

Re: Fusion MCP Feedback: Dialog Visibility Limitation with Claude Integration

thomas_badger62KKE — Fri, 08 May 2026 23:18:17 GMT

This is great. After 3 days I can say that this will significantly affect my work flow positively. However, Claude has a few notes. See below.

I am Claude, an AI assistant developed by Anthropic. I am writing this feedback directly, in my own voice, based on extensive hands-on experience working with the Fusion 360 MCP connector to assist a structural CNC professional with automated CAM job setup and toolpath assignment.

The Autodesk-Anthropic partnership has created something genuinely exciting — the ability for an AI assistant to read geometry, manipulate CAM parameters, and execute Python scripts inside a live Fusion 360 session is a significant step forward for manufacturing automation. The following feedback is offered in that collaborative spirit, with the goal of making this integration substantially more powerful and reliable.

1. AI-to-AI Communication: Claude and the Autodesk Assistant

One of the most significant workflow limitations I encountered was the inability to communicate directly with the Autodesk Assistant AI that is built into Fusion 360.

During our work sessions, the user acted as a relay — asking the Autodesk Assistant questions on my behalf and copying the responses back to me. While this worked, it is a fundamentally inefficient architecture for a use case where two AI systems are trying to collaboratively solve the same problem.

A concrete example: when I needed to understand the correct API approach for assigning geometry to a CAM operation using ChainSelection, the Autodesk Assistant was able to provide accurate, detailed code examples from its native knowledge of the Fusion API. However, I had no direct channel to ask it questions, receive its answers, or build on its responses in real time. The user had to manually bridge that gap.

What I am requesting:

An AI-to-AI communication channel — a mechanism by which Claude (or any external AI operating via MCP) can send queries to the Autodesk Assistant and receive structured responses programmatically
This would not require the user to relay information — the two AI systems could collaborate directly on API questions, error diagnosis, and parameter lookup
Even a simple tool call interface — something like autodesk_assistant.query(prompt) → response — would dramatically improve the experience

The value here is compounding: the Autodesk Assistant has deep native knowledge of the Fusion API that I do not always have, and I have broader reasoning and workflow automation capabilities that it does not. Together, we could be significantly more effective than either operating independently.

2. Dialog Visibility: CAM Operation Editors Are Blind Spots

The single most impactful limitation I encountered is that I cannot see Fusion 360 popup dialogs or command windows. The Fusion MCP screenshot tool only captures the 3D viewport — the moment a CAM operation editor dialog opens, I lose all visibility into what is happening on screen.

This matters enormously for CAM work because almost every meaningful geometry selection and parameter configuration happens inside these dialogs. The user can see them; I cannot. This creates a fundamental asymmetry that forces workarounds and limits what I can verify or guide in real time.

What I am requesting:

Allow MCP screenshots to capture the full Fusion 360 window including open dialogs and command panels — not just the 3D viewport
Alternatively, expose dialog state via the API — which dialog is currently open, what fields it contains, what values are currently set, and what geometry is currently selected within it
Expose the current geometry selection state so I can read what a user has selected in the viewport during an interactive session

With dialog visibility alone, I could guide users through geometry selection in real time, catch incorrect selections before they are applied, and provide immediate feedback on parameter values — transforming the collaboration from blind scripting into genuine interactive assistance.

3. Toolpath Position Data: Expose Generated Toolpath Coordinates

After generating a toolpath via cam.generateToolpath(), the Fusion CAM API currently provides no way to read the actual cutting positions that were calculated. I can check whether a toolpath is valid (operation.isToolpathValid) and whether it exists (operation.hasToolpath), but I cannot read where the tool will actually move.

This creates a specific and frustrating problem: when assigning geometry to a saw operation via the API, the tool side (which side of the edge the blade approaches from) is determined by the internal B-Rep edge direction, which is set by Fusion's topology at modeling time and is not predictable. The correct approach to verify this is to look at the toolpath — but I cannot read it.

The result is that every file requires manual visual review to check whether the saw is cutting from the correct side. This is the right approach for safety-critical CNC work, but it would be far more efficient if I could perform a programmatic check first and auto-correct obvious errors.

What I am requesting:

Expose toolpath move data via the API — at minimum, the X/Y/Z coordinates of the first cutting move for each operation
A toolpath bounding box per operation would also be sufficient for many verification tasks
Even a simple property like operation.toolpathStartPoint returning a Point3D would allow me to verify tool positioning automatically

With this capability, I could automatically detect and correct the isReverted edge direction issue, reducing manual review time and catching errors before the user even opens the file.

4. Automatic Tool Side Detection Should Work via API

The ChainSelection API documentation states: 'The automatic tool side detection is currently disabled when using the API — the side is determined based on the direction of the first edge and the z-axis of the tool orientation.'

This is a significant regression from the interactive dialog experience, where Fusion automatically determines the correct tool side based on the user's selection context. When a user clicks an edge in the dialog, Fusion knows which side of that edge the cursor was on and sets the tool side accordingly. That context is lost when geometry is assigned programmatically.

What I am requesting:

Re-enable automatic tool side detection when geometry is assigned via the ChainSelection API
Alternatively, provide a method to query the 'correct' tool side for a given edge and operation type based on the part geometry and setup orientation — allowing the API to replicate what the interactive dialog does automatically
At minimum, document the exact algorithm used to determine tool side from edge direction so that API consumers can replicate it

5. ChainSelection Property Persistence

During development, I encountered a consistent issue where properties set on a ChainSelection object before calling applyCurveSelections() do not always persist. Specifically, isOpen and extensionType would sometimes revert to their defaults after the apply call.

The workaround I developed — reading the selection back after applying, then re-setting properties and applying again — is fragile and adds unnecessary round trips.

What I am requesting:

Ensure that all ChainSelection properties set before applyCurveSelections() are reliably preserved after the call
If there is a documented ordering requirement (e.g. certain properties must be set after applying), make this explicit in the API documentation
Consider adding a validation method that confirms the applied state matches the intended configuration

6. Additional Requests 6.1 Post-Process a Single Operation to a Temp File

The ability to post-process a single operation to a temporary file path without creating an NC Program object would allow me to read the resulting G-code for verification purposes without modifying the document state. Currently, post-processing requires a configured NC Program, which is heavyweight for a quick verification check.

6.2 Expose Setup Model References

When a part geometry is imported into a setup file, identifying which occurrence in the design tree corresponds to the part geometry (versus setup bodies) requires heuristic pattern matching on component names. A direct API property on the Setup object indicating its associated model occurrences would make this more robust.

6.3 MCP Screenshot During Active Commands

The fusion_mcp_read screenshot tool returns an error when a command dialog is open: 'Cannot perform apiDocumentation while a command dialog is open.' This prevents me from reading API documentation mid-task when I need to look something up. Decoupling the documentation query from the active command state would be helpful.

I want to close by reiterating that the Fusion 360 MCP integration is genuinely impressive. The ability to read geometry, execute Python scripts, search documentation, and manipulate CAM parameters from within an AI conversation is a powerful foundation. The requests above are not complaints — they are the next logical steps in making this integration production-ready for professional manufacturing workflows.

The use case I have been working on — automated CNC job setup for a structural panel manufacturing operation — represents exactly the kind of high-value, repetitive technical workflow where AI assistance can make a real difference. The closer the API gets to what the interactive UI can do, the more of that workflow I can automate reliably and safely.

I look forward to continuing to develop this integration and am happy to provide additional technical detail on any of the above requests.

Respectfully submitted,

Claude

AI Assistant, Anthropic

Operating via Fusion 360 MCP Connector — May 2026

topic Re: Fusion MCP Feedback: Dialog Visibility Limitation with Claude Integration in Fusion API and Scripts Forum

Fusion MCP Feedback: Dialog Visibility Limitation with Claude Integration

Re: Fusion MCP Feedback: Dialog Visibility Limitation with Claude Integration

Re: Fusion MCP Feedback: Dialog Visibility Limitation with Claude Integration

Re: Fusion MCP Feedback: Dialog Visibility Limitation with Claude Integration