Each time an agent changes an existing package version, the nCrunch build fails. It's cache is probably out-of-date. The MCP server should provide a way for the agent to trigger a restore or a full build with restore.
For now the only solution is to stop and recreate a new nCrunch session.
Centralized package management creates a blind spot for NCrunch's project file sync, because it puts critical load-time details outside the project file. The MCP server normally restores packages when it loads projects from disk, so changes to package references directly inside project files should trigger the restore. When it's outside the project file, the mechanisms to track it are less reliable.
This was generally considered an edge case. How often do you change package versions?
The build below includes changes that should force projects to restore and reload when directory.build.props or directory.packages.props files are updated on disk. I'm hopeful that this will solve the problem for you. It also contains a number of other improvements to the MCP server, including RDI support.
I'm working in a quite large solution with several application components those days, and package upgrade is often needed for various reasons (new library, new library version, vulnerabilities in existing libraries...). In terms of frequency, I would say once per day. But when performing a package upgrade, inconsistencies can sometimes occur. In this case version changes back and forth can be needed, and this is when re-creating an nCrunch session is required (which can be long).