Error in linking Claude with MATLAB using MCP server

I tried to link my claude with MATLAB using the MCP server. However there is some issue in the connection. I am receing these error messges in claude:

Could not attach to MCP server MATLAB

MCP MATLAB: Server disconnected.

Unable to connect to extension server. Please try disabling and re-enabling the extension.

I downloaded the MCP server from github and added it to the extensions in claude. I tried both - mcpb version (matlab-mcp-core-server.mcpb) and the win64 application (matlab-mcp-core-server-win64) method to try adding the extension. Still some command or settings is blocking the process.

I have also attached the screenshots of the extensions and developer tabs of claude for reference.

Is there any other setting or procedure I am missing? What might be the error here...

[Szymon]

Same problem! Mathworks and Anthropic should do something about it.

[Yifan]

Similar problem found. Under the same setup, Claude desktop is the only application that fails to use Matlab MCP server. I believe the extension is correctly configured for Claude, and Claude recognizes it when trying to bridge Matlab software. But the server itself fails to request that, and Claude just waits for a response until timeout. This does not happen to any other agent after being tested, such as Codex or Opencode. It is a UNIQUE problem for Claude using Matlab MCP server. Waiting for a solution.

[Gareth]

Hi @Szymon, @Yifan,

In the v0.8 MCPB release we added an optional Log Folder directory setting. Could you try setting this to a short, existing folder path on your local machine that you know is writable?

This can help if the issue is related to filesystem access or path length. If the problem persists, that folder should contain log files which may help with further debugging. Additional support is available via GitHub here:

https://github.com/matlab/matlab-mcp-core-server?tab=readme-ov-file#contact-support

Thanks!

Answer 1

[Ritam]

Based on the details you’ve shared, it looks like the MCP Core Server is not successfully attaching to Claude, even though the extension itself has been added correctly. At this point, this does not appear to be a simple configuration issue on your end and may require review by the MCP Core Server team, especially given the repeated “Server disconnected” errors across both the ".mcpb" and "Win64" setups.

For setup‑related questions or connection troubleshooting, you can reach the MCP Core Server team directly using the “Have Questions?” button at the bottom of this page:

https://www.mathworks.com/products/matlab-mcp-core-server.html

If you believe this may be a bug or an unsupported interaction with Claude’s extension framework, it would be best to report it on the project’s GitHub repository with the error messages and screenshots you mentioned:

https://github.com/matlab/matlab-mcp-core-server/issues

That should help ensure the issue is reviewed by the developers who maintain the MCP server and can advise on whether additional settings, permissions, or current limitations are involved.

Answer 2

[Zoltan]

I hit this exact error on Windows and tracked down the root cause. It is not a MATLAB problem and it is not a config problem — the MCP server dies before it ever contacts MATLAB.

THE FIX

Add an explicit log folder argument pointing at a normal, writable folder with a normal (non-shortened) path:

--log-folder "C:\Users\<username>\Documents\matlab-mcp-logs"

In Claude Desktop, if you installed the .mcpb, this is the "Log Folder" field under Settings > Extensions > Configure. If you configured the .exe by hand in claude_desktop_config.json, add it to the args array:

"mcpServers": {

"matlab": {

"command": "C:\\path\\to\\matlab-mcp-server-windows-x64.exe",

"args": [

"--matlab-root", "C:\\Program Files\\MATLAB\\R2026a",

"--log-folder", "C:\\Users\\<username>\\Documents\\matlab-mcp-logs",

"--log-level", "info"

]

}

}

Then quit Claude completely from the system tray (closing the window is not enough) and restart. Gareth's suggestion above is correct — I can now explain why it works.

WHAT IS ACTUALLY HAPPENING

The MATLAB MCP Server runs as two processes: the server itself, and a small watchdog child whose job is to clean up MATLAB if the server dies. They communicate over a Unix-domain socket file that the server creates inside its log folder.

If you do not specify --log-folder, that folder defaults to the OS temp directory. When Claude Desktop launches the server, it does so via cmd.exe, and the temp path the server receives is the DOS 8.3 short form. Mine came through looking like this:

"log-dir":"C:\\Users\\USERNA~1.DOM\\AppData\\Local\\Temp\\matlab-mcp-server-<id>"

rather than the full C:\Users\<username>\AppData\Local\Temp\... The watchdog creates the socket there, the server tries to connect back to it, and Windows refuses:

{"level":"ERROR","msg":"Failed to connect to watchdog socket","error":"access denied for socket file"}

{"level":"INFO","msg":"Initiating application shutdown"}

{"level":"ERROR","msg":"Server failed with unexpected error","error":"access denied for socket file"}

The watchdog logs the same failure from its side on the way out:

{"level":"ERROR","msg":"Failed to stop server","error":"unlinkat ...\\watchdog-<id>.sock: The file cannot be accessed by the system."}

The whole thing is over in about 500 ms. From Claude's side all you see is the stdio pipe going dead:

[MATLAB] [info] Server started and connected successfully

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

Failed to initialize MCP Server. For details, see the MCP server log in your AI application.

[MATLAB] [info] Server transport closed unexpectedly

[MATLAB] [error] Server disconnected.

Note that "see the MCP server log in your AI application" is misleading — the log that actually contains the reason is the server's OWN log, in its log folder, which by default is the invisible temp directory that just failed. That is why this error is so hard to diagnose. If you want to see it for yourself before applying the fix, look in %TEMP% for folders named matlab-mcp-server-* and open server-*.log inside them. There will be one per failed launch.

HOW I CONFIRMED IT

- Ran the same .exe with the same arguments manually from PowerShell, driving a full MCP handshake over stdin. It worked every time: initialize succeeded, 5 tools and 2 resources registered, MATLAB launched normally. The only difference was that I had passed --log-folder pointing at an ordinary folder.

- Tried four argument variants (with and without --initialize-matlab-on-startup, with and without --matlab-root, session-mode=new with nodesktop). All four worked outside Claude. All four had failed under Claude.

- Ruled out the usual suspects: the executable is properly code-signed by MathWorks, Smart App Control was off, no mark-of-the-web block on the download, the JSON parsed cleanly, MATLAB was on PATH, and "matlab -batch" started headless and returned normally. None of these were the problem.

- After adding --log-folder, the launch from Claude produced a clean startup with no socket error, and the session folder contained connector.securePort, the TLS cert pair, an empty matlab_stderr.log, and no mcp_startup_error.txt.

Environment: Windows 11, Claude Desktop 1.34493.x (MSIX / Store-packaged build), matlab-mcp-server v0.12.0, MATLAB R2026a.

WHAT I AM NOT SURE ABOUT

I have not pinned down exactly which property of that default temp path breaks the socket. Candidates are the 8.3 short path form, filesystem virtualisation in the MSIX app container that Claude Desktop now ships as, or the ACLs on the temp directory as seen by the spawned process. What is certain is that the failure occurs only in the default temp folder when Claude launches the process, and that pointing --log-folder at a normal directory eliminates it.

SUGGESTIONS FOR MATHWORKS

1. Resolve the log/socket directory to its long path form before creating the socket, or fall back to another directory when the socket connect fails, rather than treating it as fatal.

2. Write "access denied for socket file" to stderr. Claude logs anything the server writes to stderr, so a single line there would have made this a five-minute fix instead of a multi-hour one. At present the only visible message points users at the wrong log file.

3. Consider defaulting the log folder to somewhere under the user profile rather than temp.

I have also opened this as a GitHub issue on matlab/matlab-mcp-server with the full logs.

Hope this saves someone else the afternoon.