Server State and Isolation (Important for Consultants)
MCP Engine stores server-side state (by default under ~/.mcp-engine/), including preferences, policy rules, tests, model change history, audit logs, and license state. This matters because multiple clients on the same machine share this state - and that can cause real problems if you're not aware of it.
What goes wrong in practice
Here are the concrete scenarios that catch people off guard:
- Cross-customer bleed - you finish an engagement with Customer A, then start working with Customer B on the same laptop. Your naming conventions, guardrails, policy rules, and test definitions from Customer A are still active. The assistant starts applying Customer A's conventions to Customer B's model.
- Claude Desktop vs Claude Code disagree - you activate a Pro license in Claude Desktop but Claude Code shows Free tier. They are pointing at different MCP Engine instances (different ports, different OS users, or different config paths). The fix: check
license file pathin both and make sure they point to the same server. - "Where did my export go?" - you asked the assistant to save test results to a file. It saved them on the machine running the MCP server. If that server runs in a container or on a remote host, the file is there, not on your laptop.
- Tests from a previous session still running - you defined regression tests for Model A. You switch to Model B but the old test definitions are still there because tests are stored per-server, not per-model.
How to keep things clean
If you work across multiple customers or environments:
- Use a separate OS user per customer/environment - each user gets its own
~/.mcp-engine/directory with completely isolated state. - Or configure separate storage directories - set
MCP_ENGINE_PREFERENCES_DIR,MCP_ENGINE_POLICIES_DIR,MCP_ENGINE_TESTS_DIRper environment. - Export and reset between engagements - export your preferences baseline, then reset preferences before starting with a new customer.