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.
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.
