Small correction on the protocol claim, because your config-level advice is right for a subtler reason than stated. You write "There is no notion of a tool requiring confirmation, no read-only mode, no scoping," but MCP has had tool annotations since the 2025-03-26 spec revision: readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The catch, and it validates your approach, is that the spec marks them as untrusted hints unless the server itself is trusted, and clients are not required to enforce them. So a read-only flag exists on paper and your two-config separation is still the only enforcement that actually binds. Worth annotating your tools anyway, since some clients do surface destructiveHint in confirmation UIs. Lesson four matched my experience exactly: trimming payloads to what the model reasons over improves answers, not just cost, because the model was reading past those fields and paying attention-tax for the privilege.