The life of a software developer during what seems like the unfolding singularity is definitely not boring at the moment.  Agentic AI tooling is having a big impact on the way we now write code, and v5.22 is focused on bringing NCrunch up to speed.

Agentic Software Development on the NCrunch Solution

I've been receiving a lot of requests from users that want their AI agents to be able to interact with NCrunch through an MCP server.  I've been doing more and more work with agents myself, and the feature gap is real.  Over the past few months, I've been experimenting with ways to enable AI integration with NCrunch by allowing the engine to be steered and queried from running agents both inside and outside the IDE.

It's been an interesting journey, involving a lot of excitement, confusion, and more than a little frustation fused with occasional moments of disbelief.  I'm amazed at what agents can do.  It's also so spectacular just how wrong they can go without the right guidance.

One of the first things that was clear to me with this project was that constraints were needed.  Frontier AI models are very well aligned and it seems we can trust their intentions, and hallucination seems to be less of a problem than it was two years ago.  Unfortunately, they suffer from a lack of domain knowledge and still seem to struggle somewhat with complex real-world scenarios.  So for me, the first stage of this project was almost entirely about infrastructure.

The vision was to build a constellation of Debian and Windows based VMs that could support the environment needed for an agent to perform operations not only on a single repository, but over a network containing a range of different services, such as a CI server, Git Repo, file server, NCrunch grid nodes, test environments, etc.  In every major software project I've worked on, infrastructure was always a big time sink, and I wanted to be able to automate as much of it as possible.

The eventual result is something that I feel strikes the right balance between paranoia and agentic madness.  An OpenClaw-based server hosts a range of different agents with different specialties (i.e. infrastructure management, NCrunch solution coding, conceptual design), with gated/firewalled access to critical systems that allows them to run scripts with human approval.  Agents have fairly broad read access and are able to draft their own changesets which must be reviewed before commit.  In this way, I can direct agents to fix infrastructure problems, troubleshoot bugs and add features without risking them manically installing external software or rewiring systems without authorisation.

The critical piece of all this, unsurprisingly, was NCrunch itself.  For a range of reasons, NCrunch itself is the only tool that can run its own tests, so without a working MCP server, it was often impossible for agents to verify their own work on the NCrunch codebase.  This led to a bizarre mash-up of human directed effort with unhinged agents optimistically churning out MCP scaffolding, only to result in hours of human-driven untangling.  The critical lesson: AI self-verification of work is extremely important.

Once the MCP server was operational in its most basic state (allowing agents to start sessions, run tests and read results), everything got easier.  It became possible to direct agents to extend the server themselves, adding functions as directed and designing signatures in ways they could easily operate.  I still needed to be quite involved around integration with the engine itself, particularly around threading constraints, but the rate of acceleration was quite remarkable.

I'm quite happy with the result.  It's probably of similar quality to what I could have eventually done on my own, but required much less effort and was built in a tighter timeframe than I expected.  I thought I would be releasing the MCP server in v5.23, but instead it's ready for v5.22!  It's still a bit experimental though.

IDE Integration

By popular request, NCrunch's MCP server has been designed to integrate with GitHub Copilot under Visual Studio and the JetBrains AI Assistant under Rider.  This fills the most obvious feature gap of allowing IDE-hosted agents to use NCrunch to run tests and query results without needing to rely on other tooling (i.e. dotnet test).

My preference was to set this up so that NCrunch's MCP server would auto register with the IDE hosted agent on startup or installation, so there'd be nothing you would need to enable to make use of it.  Reality eventually scuttled this plan in the following ways:

• Security considerations make it a bad idea.  The standing convention around agents is that they should be distrusted until proven otherwise, and giving them full power over NCrunch by default seems like a decision that a user should make deliberately.
• Auto registration is somewhat ropey.  At present there isn't a single API call that will do this and anything that stands a chance of doing it reliably involves a number of steps and decisions (i.e. should it be global or per solution? what should it run?) that a user should be involved in.  Broadly, it's complicated, and complicated things tend to break.
• There is massive change ongoing in this area.  Both Microsoft and JetBrains are investing a lot of time in building and extending these tools.  That makes it hard to rely on any integration point being future-proof.  It wouldn't be a good experience if auto-registration only resulted in failure and confusion as soon as the tooling was updated.

So for the time being, you'll need to set up NCrunch's MCP server manually using your chosen IDE.  This should be as simple as just pointing the IDE to NCrunch.MCP.exe and authorising the various functions you want to have available to your agent.

When running under the IDE, the MCP server behaves a bit differently to how it does in fully headless mode.  Under VS, it uses an environment variable to identify the running engine, which it then hooks up to.  Under Rider, it uses Win32 APIs to traverse the process tree to find a common ancestor (Rider64.exe).  It's important that your NCrunch engine is running when you let an agent try to steer it, otherwise you'll get complaints about timeouts.

See here for more details on how to set things up.

Headless Mode via Console Tool

When installed through the NCrunch console tool and run directly via the command line, NCrunch.MCP.exe enters detached/headless mode for use by fully autonomous agents such as OpenClaw and Hermes.  This is the mode I mostly use myself and it's the one that I'm personally the most excited about.

The headless MCP server acts as a front-end for what is able to be multiple NCrunch engine sessions.  It's possible for an agent to use the HTTP interface to start the engine for a specific solution, run tests, extract test coverage data, run builds, read results, etc.  Sessions can be left running, and they use all of NCrunch's file synchronisation systems.  This means that an agent (or human) can modify source code on disk and the session will automatically load the changes, run builds, apply impact detection logic and automatically run tests according to selected engine mode.

In a manner of speaking, this turns NCrunch from an IDE-integrated toolset into an agent facing IDE all on its own, though minus a lot of the features modern IDEs currently give us, like source navigation, find usages, and so on.

To enable headless mode, you'll need to specify the /http parameter with an address, listening port and secret.  See here for more details.

Regarding RDI

As of v5.22, RDI features are not yet surfaced to agents.  Sessions can have RDI enabled and will record data as usual, but there aren't any functions exposed for agents to read it.  I think that RDI has massive potential for agents because it will allow them to efficiently debug code without actually needing to use a debugger.  It's going to take some experimentation to get this right though, as RDI involves massive amounts of data that agents need to be able to efficiently sift through.

I do also expect it to be tricky to guide agents through working with RDI data.  The existing functions for running tests and querying results involved quite a bit of fine tuning to stop agents from trying to treat NCrunch like a static runner where they'd just target a specific test and wait for a result.  It's clear that the models are better tuned for static end-to-end testing than they are for working with a fully continuous tool, so I've found that careful documentation around the functions is very important.

Other Things in v5.22

NCrunch v5.22 isn't limited to just MCP work.  It's also a full maintenance release containing a range of fixes and performance improvements, along with support for JetBrains Rider 2026.2 (released today!).  See here for the full list of changes, or go download it now!