Ask a general-purpose model to plan a VMware-to-Nutanix migration and you get something plausible. Organized, confident, and right in the way a well-read generalist is right. It knows Nutanix Move exists. It knows you should test before cutover.
What it doesn’t have is the thing an experienced architect actually carries around, which is a specific and opinionated list of the ways this particular job goes wrong.
Here is an entry from the library I’m going to describe, filed under compliance failures:
The “we passed the audit but did not actually have the control” pattern. Goes wrong: the auditor verifies that the team has a “data classification policy”. The policy is a 4-page document in Confluence. The auditor reads the document, agrees that it covers the requirement, and signs off. Six months later an incident reveals that nobody in engineering has ever read the document and the actual data classification practice is whatever each team decided.
Prevent by: every documented control must have an operational metric that proves it is being followed. The metric is the control, not the document.
A model won’t volunteer that. Not because the reasoning is beyond it, but because nothing in your question invites it, and the failure mode only looks obvious after you have watched it happen. That gap — between what a model can reason about and what it will actually raise unprompted — is the whole reason to hand it a curated library instead of hoping.
So I put one behind an MCP server. It’s about 15KB, it runs on your machine, and connecting it takes one line.
What it is
@eevenson/architect-knowledge-mcp exposes a curated cloud-architecture knowledge library — currently 442 files — to any MCP-compatible client: Claude Desktop, Claude Code, Cursor, Cline, LM Studio, and the rest. The library breaks down as 280 provider files (AWS, Azure, GCP, Kubernetes, VMware, Nutanix and about forty others), 74 general, 47 patterns, 21 compliance, 11 failures, 9 frameworks.
Three tools: search_knowledge, list_categories, read_file. No API keys. No embedding model, no GPU, no database — retrieval is BM25, which I’ll come back to because it matters. It pulls the knowledge files from a public repo on first run, caches them locally, and starts instantly after that.
For Claude Code:
claude mcp add architect-knowledge -- npx @eevenson/architect-knowledge-mcp
For Claude Desktop, in claude_desktop_config.json:
{
"mcpServers": {
"architect-knowledge": {
"command": "npx",
"args": ["@eevenson/architect-knowledge-mcp"]
}
}
}
That’s the whole setup. There’s a heavier system built on the same library for full design workflows, but nothing here needs it.
What you actually get back
Worth showing rather than describing. Asking for a Nutanix migration checklist returns entries like this:
providers/nutanix/migration-tools.md — Nutanix Move
Limitations: - Does not support VMs with independent/persistent disks — must detach before migration - Does not support VMs with PCIe passthrough devices — must remove before migration - Does not support VMs with active snapshot chains — consolidate first - Does not support physical-mode RDMs — convert to virtual-mode or VMDK first - Does not migrate VMware-level constructs (resource pools, DRS rules, custom attributes)
That Limitations block is the part worth having. Every one of those lines is a migration that stops on cutover night. They’re findable — they’re in release notes and forum posts — but you have to already know to look, and a model summarizing “how do I use Nutanix Move” will happily describe the happy path.
The checklists carry priorities, and you can filter on them:
- [ ] [Critical] For Linux VMs, confirm the kernel includes VirtIO block (virtio_blk) and network (virtio_net) drivers — all supported Linux distributions ship these in-kernel, but custom kernels may not.
- [ ] [Critical] Is storage I/O latency monitored via Prism for 24-48 hours post-migration to confirm performance meets baseline (Stargate latency <5ms for SSD-backed workloads)?
- [ ] [Recommended] Is a parallel-run period defined (1-5 business days) before decommissioning source VMs?
The [Critical] / [Recommended] / [Optional] split does real work when you’re triaging. priority_filter: "critical" gets you the must-haves and nothing else, which is the difference between a checklist you use and a checklist you skim.
You can also scope a search to one area with file_filter — "aws", "compliance/hipaa", "failures". The failures category is the one I reach for most, because it’s organized by how things break rather than by product:
☐ Runbook that requires access the on-call does not have. Goes wrong: the runbook says “use the production database admin role to run this query”. The on-call does not have that role because it’s restricted to a different team. The incident extends while access is granted.
Happens because: runbook access requirements are documented when the runbook is written and never validated against the current access of the on-call rotation.
Prevent by: every runbook step is tagged with the access it requires; access is granted to the on-call rotation by role, not by individual; runbook tests verify the on-call can complete every step with their actual permissions.
Goes wrong, happens because, prevent by. That structure is most of the value — it’s a postmortem compressed into six lines, and it’s the shape that survives being pasted into a design review.
Where it falls down
Retrieval is BM25, which means lexical matching, and it shows. I asked for HIPAA encryption requirements filtered to critical items and got a solid hit on data classification — and then two files about hosted email products, which matched because they happen to contain the phrase “encryption at rest and in transit.” Neither has anything to do with HIPAA.
That’s the honest tradeoff for a package with no embedding model in it. BM25 is fast, it needs no GPU, the whole thing is 15KB, and it never gets the specific term wrong the way semantic search sometimes does. But it will hand you files that share vocabulary with your question and nothing else, so you have to read what comes back rather than trusting the ranking.
Two other things worth saying plainly. The library is opinionated by construction — it’s a curated set of positions, not a neutral survey, and where it disagrees with your vendor’s reference architecture you should find out why before assuming it’s right. And it’s a starting point for a conversation with the model, not an authority to hand a client. It gets you to the questions faster. It doesn’t answer them.
And if you go looking for something and it isn’t there, or it’s there and it’s wrong, open an issue. A gap you hit is worth more than a gap I guess at — Part 2 gets into why that’s the whole maintenance model.
What changes
The practical difference isn’t that the model knows more. It’s that the conversation starts somewhere useful.
Without it, “plan this migration” produces a reasonable outline that you then have to interrogate out of your own experience, which works fine if you have the experience and badly if you don’t. With it, the same question surfaces the persistent-disk limitation and the parallel-run window and the post-cutover latency baseline in the first response, and the work becomes deciding which of them apply to you.
That’s a smaller claim than the ones usually made about tools like this, and it’s the one I’d actually defend. A checklist doesn’t make you an architect. It does stop you from rediscovering, at two in the morning on cutover night, something a hundred people already learned.
That’s the consumption side — connect it, query it, read what comes back with your eyes open. In Part 2 → I get into the part this post skipped: what is actually in 442 files, who decides an item is Critical rather than Recommended, how a curated library keeps from rotting as providers ship, and why the failures category is organized by how things break instead of by product.