architecture

The convenience of MCP comes with a price, stemming from two architectural attributes of an MCP-driven application. MCP creates incoherent toolsets and separate runtimes.
Since tools are drawn from arbitrary sources, they are not aware of what other tools are available to the agent. Their instructions can't account for the rest of the toolbox.
The second issue stems from different toolsets having their own runtimes.

The solution is to write tests for features in such a way that they are independent of the code. I like to use the neural network test for this: Can you re-use the test suite if your entire software is replaced with an opaque neural network?

Pure test do little-to-no IO, they are independent of timings and environment. Less pure tests do more of the impure things. Purity is correlated with performance, repeatability and stability. Test purity is non-binary, but it is mostly discrete. Threads, time, file-system, network, processes are the notches to think about.

Don’t think about tests in terms of opposition between unit and integration, whatever that means. Instead,
Think in terms of test’s purity and extent.
Purity corresponds to the amount of generalized IO the test is doing and is correlated with desirable metrics, namely performance and resilience.
Extent corresponds to the amount of code the test exercises. Extent somewhat correlates with impurity, but generally does not directly affect performance.

Architecture the software to keep as much as possible sans io. Let the caller do input and output, and let the callee do compute. It doesn’t matter if the callee is large and complex. Even if it is the whole compiler, testing is fast and easy as long as no IO is involved.

Ruthlessly optimize purity, moving one step down on the ladder of impurity gives huge impact.
Generally, just let the tests have their natural extent. Extent isn’t worth optimizing by itself, but it can tell you something about your application’s architecture.

give Sol a grid with a "randomized" obstacle to navigate.
Tell it to use a hashmap solution for formulating pathing.
As soon as it runs into its first pathfinding problem (It will) it will start writing edge-case solutions, rather than fixing the core hashmap.

My solution to this problem is making the tests data driven. Instead of every test interacting with the API directly, I like to define a single check function which calls the API.

You cannot write a spec that survives that environment unless you deeply understand the architecture, the integration boundaries, the edge cases, the failure modes, and the invariants that must never break. The spec is not a prompt anymore. The spec is the product thinking made explicit.