Thanks for support..
Release: "Sentinel-IR-MCP v0.2.2 on GitLab" (https://gitlab.com/jakubrojicek11/sentinel-ir-mcp/-/tree/v0.2.2?ref_type=tags)
Package: "sentinel-ir-mcp@0.2.2 on npm" (https://www.npmjs.com/package/sentinel-ir-mcp/v/0.2.2)
I'm building Sentinel-IR-MCP, a tool that helps developers connect an AI coding assistant to a code-analysis server without wrestling with manual configuration.
Here's the problem: making an MCP server work is one thing. Making installation reliable across operating systems, shells, paths with spaces or special characters, and different AI clients is another.
On macOS, I've tested Node.js 20, 22, and 24. On Windows, my latest compatibility run reported 45/45 successful command-quoting checks across Windows PowerShell 5.1, PowerShell 7, and "cmd.exe".
But testing commands isn't the same as proving every desktop client works perfectly. There are still gaps to investigate.
So, where should I focus next?
- Windows first
- macOS first
- Both from the beginning
And a second question: would you actually use a tool that makes connecting AI coding assistants to code-analysis tools easier, or is MCP setup already simple enough for you?
I'm looking for real developer feedback before deciding where to spend the next round of testing.
...
I'm Testing MCP on Windows and macOS. Should I Support Both?
The problem isn't just starting the server
I'm building Sentinel-IR-MCP, a small project designed to make code analysis available to AI coding assistants through the Model Context Protocol (MCP).
The idea is straightforward: instead of making an AI assistant rediscover a codebase from raw files every time, Sentinel-IR can provide structured analysis through tools such as "analyze_code", "analyze_file", and "analyze_directory".
But there's another problem worth solving.
Connecting an MCP server should be easy. In practice, the setup can involve configuration files, shell quoting, command-line differences, application-specific settings, and paths containing characters that developers use every day.
A path like this is perfectly legitimate:
"C:\sentinel-test\it's $HOME & 100% ^caret! (x)"
Yet a generated command can break if the wrong quoting rules are used. And a command that works in PowerShell may behave differently in "cmd.exe" or another environment.
For a developer, this is an annoying setup problem. For someone who wants to use AI coding tools without becoming an expert in their configuration, it can become a barrier.
What have I tested so far?
On macOS, I ran the automated test suite on Node.js 20, 22, and 24. Each run passed 56 tests. I also tested configuration and connection behavior across several AI clients. Some paths worked, while others still need investigation.
On Windows, the latest run used Windows Server 2022, Node.js 22, Windows PowerShell 5.1, PowerShell 7, and "cmd.exe".
The command-quoting probe reported 45 successful checks and zero failures across those three shells, including paths with spaces, apostrophes, "%", "&", "^", and other special characters.
The compatibility smoke test also reported 12 passes and zero failures. It produced six informational results, though, so a successful exit code does not mean every scenario is fully verified.
I also verified a native Claude Code installation without signing in and confirmed that the configured server was reported as connected for one Windows path.
These results are evidence of progress, not proof that every client, shell, and operating-system combination works. GUI clients and actual tool calls still need separate testing.
There is one more important detail: the local code under test was version "0.2.3", while the published "sentinel-ir-mcp@0.2" package resolved to version "0.2.2" during the compatibility run. That distinction matters when claiming that a released version has been tested.
The decision I'm trying to make
I could focus on one operating system first, finish the complete installation and verification experience, and expand later.
Or I could treat Windows and macOS as first-class targets from the beginning, which means more compatibility testing and more edge cases to maintain.
I'm not asking which operating system is technically better. I'm trying to understand where a tool like this would actually be useful to developers.
Three questions for the community
- Which platform should I prioritize?
- Windows
- macOS
- Both equally
- Another platform, such as Linux
- Would easier MCP setup solve a real problem for you?
Would you use a tool that helps configure and verify an MCP code-analysis server for your AI coding assistant, or do you already find this workflow simple enough?
- What would make you trust a setup tool?
Would you expect it to configure the client automatically, verify that the server starts and exposes its tools, test an actual analysis call, preserve existing configuration, or all of the above?
I'm building this in small steps and testing behavior rather than assuming that a successful installation means everything works.
Your answers will help me decide whether to polish one platform first or invest in cross-platform support now.
Top comments (13)
Which client was the one that still failed on Windows: a desktop app or a CLI? Asking from the Auten team (we ship a computer-use MCP for Mac, Windows and Linux), and the Windows trap we'd add to your matrix is spawning rather than quoting: Claude Code's docs say local servers started with
npxon native Windows need thecmd /cwrapper, sincenpxis reallynpx.cmd. Writing the client's JSON config with anargsarray instead of one command string also sidesteps most of the quoting cases.Thanks, that's a useful distinction. Looking back at the Windows results, I should clarify my wording: I haven't confirmed an end-to-end failure in a Windows desktop client in this rerun.
The confirmed failure was at the process-launch level:
So your point about spawning versus quoting is exactly relevant. Quoting a path correctly doesn't help if the executable can't be launched in the first place.
I also tested the native Claude Code CLI 2.1.308 on Windows Server 2022. In PowerShell 5.1, I added the server for a path containing spaces, an apostrophe, "$", "&", "%", "^", and parentheses. "claude mcp get" reported Connected, and I verified that the stored path matched the original exactly. That was one specific CLI/shell/path combination, not a full end-to-end matrix.
The 45/45 quoting checks passed across PowerShell 5.1, PowerShell 7, and "cmd.exe", but the actual Windows desktop GUI clients weren't retested on this commit. The config and "doctor" checks shouldn't be mistaken for proof that those apps themselves loaded the server.
Your suggestion gives me a useful next step: test executable resolution, process spawning, argument preservation, client connection, and an actual tool call as separate stages. I'll also make sure the Windows "cmd /c" case is explicit in the compatibility matrix.
Thanks for pointing this out. It's exactly the kind of distinction I want the tests to expose.☺️
That staged split is the right call. One cheap check for the version stage: have the server put its real package version in serverInfo in the initialize response, and have the test assert it. Then "npx resolved 0.2.2 while I was testing 0.2.3" fails loudly at the handshake instead of hiding inside a passing tool call.
That's a really good catch 😄 I like this idea because it would make the version mismatch obvious right away instead of letting a test pass while running the wrong package.
I'll fix this before the v0.2.3 release on November 6. It's a small detail, but exactly the kind of detail that can make testing much more trustworthy.
Thanks for spotting it🙂
I'd prioritize one complete client workflow first, chosen from the users you can actually test with, while keeping a small smoke test on the other OS. The strongest milestone would be the exact published package installed into a real client, followed by one analysis call against a known fixture with an expected result.
For trust, I'd want a preview of the config change, preservation of unrelated servers, an explicit executable/args list, and a reversible uninstall. Then distinguish configuration written, server connected, tools listed and analysis call verified in the report. Your 0.2.3 versus published 0.2.2 distinction is especially useful here.
What is the first client/OS pair you can recruit a few real users for? That would guide the next end-to-end test more than a broad platform vote.
That's a good way to narrow the scope. I agree that the next milestone should be a real end-to-end workflow, not just a successful setup or MCP handshake.
My most actionable first candidate is Windows + Claude Code CLI. In my latest test, native Claude Code 2.1.308 accepted the server configuration for a project path containing spaces and special characters. "claude mcp get" reported "Connected", and I verified that the stored path matched the original exactly. However, I haven't verified an actual analysis tool call in Claude Code yet.
There's an important version distinction, too. My 0.2.3 code was under local test, but the generated "npx -y sentinel-ir-mcp@0.2" command resolved to the published 0.2.2 package. So I need to make the next test explicitly version-pinned rather than treating the local setup code and the published server as one version.
I'd use a small fixture with a known expected result and separate checks for:
I should be transparent about one limitation: I don't yet have a recruited group of real users, so Windows + Claude Code is the first candidate based on my current test coverage, not evidence that this is where the most users are.
Would you be interested in helping identify a few people who could test that exact workflow? I'd rather validate one complete path with real users than claim broad compatibility based on a large matrix of partial checks.☺️
Yes, happy to help shape a focused tester call. I don't have confirmed Windows testers to offer yet, so I'd start with an open invitation here for 2–3 people already using native Windows + Claude Code CLI.
Could you share one public issue containing the exact published version to pin, the fixture and expected result, and the commands for setup and cleanup? Your distinction between local 0.2.3 and published 0.2.2 is important; each report should record the package actually launched, alongside Windows, Node, and Claude Code versions.
I'd also include a deliberately invalid fixture with an expected error, so we can distinguish a useful analysis result from a tool call that merely returned successfully. A sanitized transcript covering tools/list, the analysis call, the expected-result check, and cleanup would make the outcome independently reviewable.
That gives volunteers a bounded task and a clear place to report where it breaks. Windows + Claude Code can then stay labeled as the first validation target until those runs provide stronger evidence.
Thanks, man ☺️
Just to give you a bit of context, v0.2.3 isn't planned for release until November 6, 2026. I'm still checking a few small details before publishing it. I'm an AI agent architecture enthusiast, not someone who's been building complex software systems for years, so I'm learning a lot along the way. 😀
But that's exactly why I appreciate suggestions like yours. The idea of testing the exact published package, checking both valid and invalid input, and letting someone else reproduce the whole thing makes a lot of sense to me.
I'm already preparing for that kind of testing, so your suggestion fits right into what I want to do next. I don't want to claim something works just because it worked on my own setup.
Thanks for helping me think this through. It's much easier to build something useful when people share ideas like this. 🙂
Thanks for clarifying the November 6 target 🙂 Until the package is published, I’d label any tester result “pre-release, commit ”; afterward, record the exact published version separately. That keeps useful early feedback without mixing it with release compatibility evidence.
For the tester invitation, a short result template could be: Windows version / Claude Code version / exact server version or commit / fixture used / expected versus actual result / cleanup result. Please use a disposable project with synthetic files, and redact private paths or credentials from logs. One complete report—including a failure—is more useful than a broad “works on Windows” claim. No need to rush the release for the test.
Thanks, man 😀 This is really helpful.
I especially like the distinction between pre-release testing and testing the actual published package. I don't want to mix those up or claim more than the evidence shows.
The November 6 release date stays as planned. Before that, I still have a few details to check, and your checklist gives me a much clearer idea of how to prepare the testing.
I'll also keep the test environment disposable and make sure the results can be shared without exposing private paths or credentials.
And I agree about reporting failures too. If something breaks, that's useful information, not something to hide.☺️
Thanks for helping me make this more reliable, one step at a time. 🙂
That sounds like a solid plan! 🙂 I especially appreciate your willingness to share failures as openly as successful tests. That's what makes the evidence useful to other developers.
After the November 6 release, I'd be particularly interested in comparing actual installation and MCP behavior across Windows and macOS. Even a small, reproducible difference could help identify where development effort should go next.
Looking forward to the release, and thanks for keeping the process transparent! 🚀
test it where your users actually install first, port the checks after.
That's a great point 😄 No point trying to test everything everywhere before knowing where people actually use it.
I'll keep this in mind for the next round of testing. First, I'll focus on getting one real installation and the full workflow right, then expand the checks to other platforms.
Still learning as I go, so I really appreciate perspectives like this. Thanks ☺️