I believe most of the apps out there will soon turn into MCP servers.
If I was a product manager at any software company right now, I’d be scared by the tectonic shift our world is experiencing. For years we designed software for humans, while AI agents are rapidly becoming the real users. UIs craftfully refined over time to search for restaurants, book train tickets, buy t-shirts and manage customer support tickets may soon look flawed. LLM-powered agents are not supposed to interact with GUIs, and sitting at a desk watching the cursor clicking and scrolling on its own feels like looking at the steering wheel drifting in autonomous cars: inadequate.
Luckily, the world is full of people like me who hate to mow the lawn with nail scissors, which led to David and Justin coming up with MCP. Thanks to their work there is now a standard way to let the model get the context it needs to actually do stuff. As humans are efficient machines, once experienced the feeling of booking a train ticket just by asking it to an AI assistant, I doubt anyone will ever go back to scrolling, clicking and trudging through complex interfaces. That means every train ticket booking app should soon be an MCP server, and so do almost all the other categories of software products.
However, turning a product into an MCP server is slightly more nuanced than what people think. Jeremiah from FastMCP greatly highlighted that in his latest blog post. Simply wrapping REST APIs into MCP servers is not enough, in fact an API designed for a human will likely poison the Agent. That emphasizes the need for well designed MCP servers, which opens up to something we at What About You are discussing a lot lately: Agent Experience (AX).
Essentially, AX represents a focused application of UX principles, where the user is the Agent. Crafting an effective UX includes multiple activities, starting with drawing a user story, curating each step and backing it with proper authorizations. So users who should not be able to book a train ticket would never see the booking ticket button in the UI either. That specific UX best-practice should obviously be inherited by AX as well, but it feels like we’re all underestimating it. As an internal joke we often say that instead of Agent Experience we should call it Synthetic User Experience, as right now it definitely SUX.
Some of the critiques I’m reading about MCP can be categorised under mediocre AX. Tool execution without proper authorizations and overwhelming the agent with too many similar tools among them. Does it sound logical to list the booking tool to the Agent before the Agent has even searched for trains? No, it does not. That would only lead to unnecessary token consumption and context overload. Then why do MCP server designers keep doing this? We believe these are merely issues rooted in the nascent nature of the protocol, and we see a significant opportunity in helping builders with proper MCP Server authorizations. To achieve this we recently integrated with FastMCP and contributed to its middleware capabilities. It’s now possible to easily define custom authorization rules on the Eunomia server and enforce them by just adding a line of code to any FastMCP server.
If you’re thinking about building an application, or if you’re a product manager at any software company, bear in mind that Agents will be your main users before you can even realise what is going on. Design your app so this won’t be a problem, but an opportunity!