Fusion MCP Server disconnects immediately after initialize - Claude Desktop Windows

[ezouania]

OS: Windows
Claude Desktop: version May 23 2026
Fusion 360: dernière version

Problème : Le serveur MCP Fusion se connecte, reçoit le message
"initialize" de Claude Desktop, puis se déconnecte immédiatement
avec "Server transport closed unexpectedly".

Log typique :
- Server started and connected successfully
- Message from client: initialize (protocolVersion: 2025-11-25)
- Server transport closed unexpectedly
- Server disconnected

Testé : pare-feu désactivé, Node.js v24, redémarrages multiples.
Le problème persiste systématiquement.

[prakharphysics2]

Same issue here, Windows, confirmed via netstat that Fusion is actually listening on 127.0.0.1:27182 — so it's not a firewall/port problem on my end. Log:

[info] Initializing server...

[info] Using built-in Node.js for MCP server: Autodesk Fusion

[info] Server started and connected successfully

[info] Message from client: method="initialize" id=0 params

[info] Server transport closed

[info] Server transport closed unexpectedly, this is likely due to the process exiting early.

[error] Server disconnected.

Tried: full Fusion restart, toggling the extension off/on, checked Scripts and Add-ins for a related add-in (nothing there). Same crash-after-initialize pattern every time, consistently.

[lauri_barnhart]

Hello @ezouania and @prakharphysics.

Thank you for posting your question in the community. Just checking in to see if the issue still exists or if you found a solution to the problem. If you found a solution, please update us here on how it was resolved. If you still need assistance, please provide an update also.

Regards,

[prakharphysics2]

##- First of all I want to say thanks to you for reaching out. The problem
is now resolved.

Was able to figures out the exact cause. It was actually fusion picking a
fresh ephemeral port on every launch rather than honoring 27182. It was all
clear by observing that 127.. URL in the screenshot in API section.

Resolved through Opus 5. Opus 5 is amazing.-##

[rachumnoam1Z7UGD]

I have the same problem. Fusion 2705.1.30, Claude desktop app 2.42304.2, Windows 11 Home 26H2 (build 26300.9711).

The Autodesk Fusion extension in Claude Desktop exits about half a second after the initialize message. The log shows “Era probe verdict: legacy (sibling did not complete the exchange)” on every launch, followed by “Server transport closed unexpectedly.”

In my case the port isn’t the cause. The port box and the link in Preferences > General > API both show 27182, and http://127.0.0.1:27182/mcp responds in a browser while Fusion is running. I also changed the port to 27183 and restarted Fusion, with the same result. Restarting both apps and reinstalling the extension didn’t help either.

Is there a known fix, or a Fusion and Claude Desktop version combination that is supposed to work?

[prakharphysics2]

##- it's the Problem. But first restarting both apps. Then this time make
sure you choose right MCP port cuz everytime they change MCP port on
restart in my case. Once you see the Right MCP on fusion then disconnect
claude MCP and close claude and report it again.
Now this time enter the correct one. I did these things and at last mine is
working now.

It's glitch from Autodesk basically and they aren't fixing it. I don't know
why and make the entire connection process smooth-##

[ehrenwo1]

I’m seeing the same issue and found the cause on my machine.

Environment: Fusion 2705.1.30, Claude Desktop 3.1623.0 (Microsoft Store), Windows 11 Pro 26H2 (26300.9711), MCP server on port 27182.

Findings:

• Fusion listens correctly on 127.0.0.1:27182 (Fusion360.exe), and a raw initialize POST sent in a single TCP write returns a clean response (HTTP 200, Content-Length: 226).
• Node.js-based clients fail on Claude’s real initialize request with: HTTPParserError: Response does not match the HTTP/1.1 protocol (Invalid character in chunk size). This affects the official extension, mcp-remote (undici) and Node’s built-in http module. The rejected payload is a valid initialize result, so the response appears to be labelled as chunked while the body is sent unchunked.
• Hypothesis: the response framing depends on how the request arrives (e.g. headers and body in separate TCP segments).

Workaround: a small stdio bridge that sends each request in a single write and parses the response itself works reliably for me (initialize, tool calls and screenshots). I’m currently testing an install script for it on a second machine and will share it here afterwards.

@lauri_barnhart – could this be forwarded to the Fusion MCP team? The response framing in the MCP server seems to be the root cause.

[ehrenwo1]

@prakharphysics2 – thanks, that’s a useful point. It looks like there are two different causes behind the same symptom (“Server transport closed unexpectedly” right after initialize), and they need different fixes:

Case A – port mismatch (your case, post #6):
Fusion is listening on a different port than the one configured in the Claude extension, so the extension can’t reach the server and exits. The fix is to use the port that Fusion actually shows (Preferences > General > API) in the extension settings. Since the port apparently changes on some systems when Fusion restarts, this may have to be repeated – the underlying issue is on the Fusion side.

Case B – port is correct, but the connection still drops (my case, and probably @rachumnoam1Z7UGD’s in post #5):
Fusion listens on the configured port and answers, but the response to Claude’s initialize request is malformed (labelled as chunked, sent unchunked). Node.js-based clients reject it with “Invalid character in chunk size”. Changing the port doesn’t help here (see my post #7).

How to tell which case you have – with Fusion running and a design open, in PowerShell:

Test-NetConnection 127.0.0.1 -Port 27182

(replace 27182 with the port configured in the Claude extension)

• TcpTestSucceeded : False → Case A. Check which port Fusion uses:
  Get-NetTCPConnection -State Listen -OwningProcess (Get-Process Fusion360).Id | Select-Object LocalAddress, LocalPort
• TcpTestSucceeded : True, but the extension still disconnects → Case B. The workaround from my post #7 applies; I’ll share the install script here once my second-machine test is done.

[ehrenwo1]

As announced in post #7, here is the install script for the workaround. I have now tested it on a second machine, where it ran without errors on the first attempt (Fusion 2705.1.30, Claude Desktop 3.1623.0, Windows 11 Pro 26H2).

This only helps with Case B from my post #8: Fusion answers on the configured port, but the extension still disconnects. If you have Case A (port mismatch), you don't need it - just use the correct port.

Attached files:

1. README.md - please read this carefully BEFORE running the script.
It explains the problem and the workaround, the prerequisites, what the script does step by step, what it can and cannot do, every file it creates or changes (with full paths), how to undo everything (rollback), and how to tell Case A from Case B.

2. fusion-mcp-install.ps1 - the install script (Windows PowerShell 5.1, Windows only).
It installs Node.js if needed, sets up a small bridge called "fusion-direct" (plain Node.js, no dependencies) in %USERPROFILE%\fusion-mcp-bridge and registers it in the Claude Desktop configuration (a backup is made first). Every step is checked afterwards; if something fails, the script retries, cleans up or pauses and tells you what to do. At the end it checks that Claude actually connects to Fusion. You can safely run it again; completed steps are skipped. If Fusion is restarted while Claude keeps running, the bridge reconnects by itself.

Run it from a normal (non-administrator) PowerShell window, with Fusion running and a design open:

Unblock-File "$env:USERPROFILE\Downloads\fusion-mcp-install.ps1"
powershell -NoProfile -ExecutionPolicy Bypass -File "$env:USERPROFILE\Downloads\fusion-mcp-install.ps1"

Please note:
- This is an unofficial workaround, provided as-is and without warranty. Review the script before you run it; the bridge and helper are embedded as readable text.
- Antivirus software may flag the script (behaviour detection). The README explains what to do.
- If you report the underlying issue to Autodesk, attach the log file setup-log-*.txt from %USERPROFILE%\fusion-mcp-bridge.
- Once Autodesk fixes the response framing in the MCP server, remove the workaround (rollback in the README) and use the official extension again.

@lauri_barnhart - this may also help the Fusion team reproduce the issue: the bridge works because it sends each request in a single TCP write and tolerates the mislabelled chunked response.