Since MCP is itself an API protocol, we have to say no. I think what you're after is, "Will MCP interactions under the hood replace or supplant traditional GUI interactions where the human is expected to click several things on a website?"

To that, I would say it's possible. The problem is not with MCP existing or not existing. The underlying APIs that make every app possible on the backend are already there whether you wire them up to the front with a GUI or MCP.

The problem is that API calls almost never map directly to UI appearance. Typically, the app has to examine quite a bit of state to decide what API call should be sent, what parameters it should contain, and what should be done to the UI with its result.

Those connections are built by humans with a deep understanding of the underlying API. Often the UI and "user intent" side of the house is entirely separate from the API or "data provider" side and it takes some finesse to marry the two. MCP offers no help here and asking an LLM to guess which API should be called is likely to make things worse unless it's carefully corralled.

To me, this creates a serious moat for vertical applications that are tightly focused on one kind of RAG use case, whether they use MCP or not. If the app exhibits an "intuitive" understanding of the working data and adjusts the UI in a way that makes sense to the user, it adds value that's difficult for a competitor to copy -- and impossible for anyone outside the subject domain.

This explains the Cursor moat, which seems misunderstood. Cursor is the mostly tightly integrated and best example of a RAG application in any domain. It's no surprise that software development is the first industry to see a benefit from this concept. We write everything for ourselves first. But apps that implement this kind of "closed loop" RAG over a specific subject domain and data will replace the traditional kind that only have a GUI or CLI.

MCP will likely end up locked behind an enterprise contract in the way we see SSO treated today. So no, GUI continues

For internal reporting tools I think I’d start with mcp and only do a bespoke gui if I found dome specific use case that warranted it.

I’m less certain about it more broadly but I think there is a good chance anything that can be described as “csv with a frontend” makes more sense as mcp first.