The author began by questioning whether MCP or CLI was cheaper, but discovered it was the wrong question. The true question became what architectural elements would survive in practice. Initial analysis revealed MCP had significantly lower token costs per call than raw CLI, but schema overhead for a large monolith was astronomical. The key insight was wasteful schema injection, which could be solved by a gateway filtering schemas by actual usage.The author learned that MCP servers, unlike plugins, possess lifecycle independence and can recover their own state. This realization led to the understanding that a server survives client termination, whereas a plugin inherits its parent's mortality. Containerization emerged as a cost-effective solution for environment-specific setups, offering a single image deployable across various clients without per-target configuration.A lengthy pull request lifecycle highlighted the importance of a decision tree for architectural choices, leading to the realization that an MCP server's survival is independent of its client. The original 93-tool monolith, per-WSL install scripts, and a specific git-push MCP tool were discarded. The author concluded that architectural decisions must be made early, and failures should be learned from quickly.The revised strategy prioritizes MCP for structure with typed schemas and CLI for low-overhead execution. Focused servers with a limited number of tools are preferred for independent deployability. Containers are now the default deployment method, providing a consistent stack across clients. The surviving architecture includes an MCP gateway for lifecycle management, a CLI bridge for execution, and multiple focused MCP servers.