There are many good points, but unfortunately the title ("fad") and the conclusion seem unwarranted, become a distraction and diminish the value of the article.

The security issue has been discussed many times in the past year.

Agree on the "one process per server" thing -- seems smart and convenient but gets worse when the number of MCPs and coding agents go up, especially when combined with the following point.

Lifetime is a real issue, and I am glad that someone talks about it. You probably won't worry the overhead for git, GitHub or Playwright MCP servers, where they are likely wrappers for some bash commands or rest APIs or everything is fast to launch. However, lifetime is still an issue, when you have multiple coding agents or sessions.

It gets worse for certain applications, especially heavy desktop apps (Imagine an MCP server for Lightroom classical) -- due to their application model, in order to evaluate a command, you'll have to load half of the application to do that. You'd think you only want to launch this once. But likely not. Each coding agent session will launch its own instance. Maybe this won't happen if the MCP server works extra hard to share processes and manage lifetimes on its own, but it totally depends on the third party provider, and the behavior could vary wildly.

Would a user want to deal with all these issues? If they are not careful, they'll easy launch 15 processes consuming 1G of memory for two coding agents, one of which does not actually use any of those servers, and one is simply sitting idle because the user hasn't started vibe coding yet.

(If this doesn't seem an issue to you, probably just because you haven't run into it first hand yet )

I think there has got to be a better way to do this.