Observable Visual Studio, git remote + NCrunch.MCP.http

Usage is Visual Studio with the target repo open on Windows [on a specific branch]: concurrently an AI updates the same repo remotely (Linux). Git's pushed and a local-watcher|remote-script (securely) updates the Windows clone; thereby triggering Visual Studio's nCrunch integration. All of this is arranged. NCrunch "just works".

I expected nCrunch MCP http to connect just as the local [stdio?] would within VS|Rider IDE integration but the connection reports no active sessions.

Connecting to an nCrunch [http] instance via cmdline instantiation of NCrunch.MCP.exe (this is the root irritation) reports different test counts (more) and all passing (while VS's integration has multiple fails across multiple projects).

Am I missing something or is this intentional/constrained design? Not the local vs CI|remote difference, obviously. nCrunch facilitating a third leg convergence isn't new but an opaque headless divergence from the IDE isn't quite cutting the mustard.

FWIW nCrunch's speed and accessible visualization is worth more than ever under AI acceleration so, even if I'm a little late to the MCP effort, it's nonetheless welcome. Thx for holding fort vs bulk licencing. Appreciated.

Thanks for sharing this issue.

Having the MCP server just work out of the box was a problem, because IDEs are designed to be reasonably paranoid about the sorts of facilities that are offered to agents automatically. It is necessary to register the stdio NCrunch.MCP.exe installed under your VS path with the IDE before the server will work.

MCP server registration is not as clean as I'd like it to be. The IDEs are changing in this area by the week, and the constraints make it hard to streamline. If you're able to share more detailed information about how you've registered the MCP server with the IDE and specifically which version of VS you're using, I might be able to provide more detailed guidance. It's already likely to have changed since the last NCrunch build was published.

Avoid connecting the IDE to a standalone HTTP instance of NCrunch.MCP.exe. This will create a scenario where you have two separate NCrunch sessions operating on the same open solution, which will cause all manner of confusion. When working in the IDE, you must use stdio and let VS manage the lifecycle of the NCrunch.MCP.exe under your NCrunch VS plugin install path.