At one point, I had installed the MSIX version of Claude. Then later, installed the zipped version of Claude. When I launched Claude, the Cdata MCP server connected, then immediately disconnected. The failure trace pointed to an unescaped unicode character. I checked the .json and .prp file and there were no errors.
I killed all the Claude tasks, uninstalled Claude and re-installed just the zipped version of Claude. This worked. The MCP launched and I was able to query the excel spreadsheet.
I’m not sure MSIX installs are going to change the instructions for users experimenting with Cdata connectors. Thank you!
Interesting find! It seems the issue may be related to how the MSIX and ZIP versions handle application paths or environment settings. Reinstalling the ZIP version was a useful workaround. It would be worth checking whether the MCP server configuration references the correct Claude installation path, especially when switching between installation types. Thanks for sharing this, as it could help others troubleshooting similar connection issues.
MSIX apps often run with virtualized file/registry views and a different working directory, so a child MCP process may see different paths or environment than under the ZIP build. I’d compare the exact command, args, cwd and environment used for cdata-jdbc-mcp-server in both installs, and test launching that server manually with the same config. The unicode error may be secondary—for example a path or output-encoding difference—so also check the config for a BOM or non-ASCII characters and whether the MSIX build is passing a package-virtualized path.
This website stores cookies on your computer. These cookies are used to collect information about how you interact with our website and allow us to remember you. We use this information in order to improve and customize your browsing experience and for analytics and metrics about our visitors both on this website and other media.
Review section III of our Privacy Policy for more information on cookies.
To opt out of “sale” or “sharing” of non-cookie data, visit our Privacy Rights Request Form.