For most of the history of digital products, we have worked with the same basic assumption: if people want to use your product, they have to come to you. They visit your website, open your application, log into your platform and learn their way around the interface you have designed for them. Even as products became more connected through APIs and integrations, the product itself remained the destination.

AI is starting to challenge that model in a way that I think is much more interesting than simply adding a chatbot to an existing product.

Over the past few years, we have already seen software become accessible through AI assistants. A user asks a question, the assistant calls an external tool or API, receives some data and translates that data into a response. That can be incredibly useful, particularly when the answer is simple, but from a product perspective something important gets lost along the way: a product that may have taken years to design and refine is suddenly reduced to whatever information can be squeezed into a conversational response.

MCP Apps offer a different direction. Instead of forcing every interaction through text, they make it possible for a product to bring an actual interactive interface into the conversation, which means that the dashboard, map, form, configuration tool or viewer that is best suited to the task can appear directly inside the AI client the user already has open.

To me, that is where MCP Apps become interesting, because they are not simply a better way of building AI integrations. They raise a much bigger question about where digital products might live in the future.

A quick refresher on MCP

The Model Context Protocol, or MCP, is an open standard that allows AI clients to communicate with external tools and data sources in a consistent way. Instead of building a completely different integration for every assistant, you can expose your product through an MCP server and allow clients that support the protocol to interact with it. The analogy that is often used is USB-C for AI, and although it simplifies some of the complexity underneath, I still think it is a useful way to understand the basic idea: rather than every product and every AI client inventing their own way of connecting, there is a shared protocol between them.

Until recently, those interactions were primarily about exchanging information. A server could return text, images or structured data, after which the AI client decided how to present that information to the user. MCP Apps extend that model by allowing a tool to point to a ui:// resource that the client can fetch and render as an interactive web interface inside a sandboxed environment.

Because that interface is built using standard web technology, it can behave much more like the digital products we are used to designing and building. You can use React, Vue, Svelte or plain JavaScript, let users interact with the interface directly, call tools on the MCP server from within it and update the view as new information comes back, without requiring the user to translate every interaction into another prompt.

The technical change is relatively straightforward to describe, but the product implications are considerably more interesting.

Not everything becomes better when you turn it into a conversation

One of the assumptions surrounding generative AI has been that interfaces will gradually disappear because users will simply tell software what they want. There is certainly some truth in that, because a conversational interface can remove an enormous amount of unnecessary navigation and complexity when the user's intent is clear.

If I want to know how many holiday days I have left, I probably do not need a dashboard with filters and navigation. I would rather ask the question and get the answer.

The situation changes when I want to understand sales performance across fifty regions, compare a number of locations on a map, configure an insurance policy with dozens of variables or work through a series of approvals. You can turn all of those interactions into conversations, but doing so often makes them slower and less intuitive, because the user has to repeatedly describe what they want to see, remember what was shown before and translate actions that would normally take one click into another instruction.

There is a reason we have spent decades developing visual interfaces. Some information is simply easier to understand when you can see it, and some actions are easier to perform when you can interact with them directly.

That is why I do not think the future is particularly well described as chat replacing UI. What seems much more likely, and much more useful, is an experience in which conversation and interface start working together, with the AI helping users express their intent and the product presenting the right interface whenever interacting visually becomes the better option.

MCP Apps provide a technical foundation for exactly that kind of experience.

Why not just send the user to your web app?

This is probably the most obvious question, because if an interaction needs a proper interface anyway, you could simply open the product the company has already built.

In many cases, that will still be the right answer. A standalone web application gives you complete control over the environment and remains much simpler when there is little value in connecting the interface directly to an AI conversation.

The difference becomes more apparent when the conversation itself contains context that is useful to the product.

Imagine asking your assistant to show you how European sales are performing this quarter. Instead of returning a long textual analysis or sending you to a dashboard in another tab, it could show you an interactive visualization directly in the conversation. You could explore the data visually and then ask the assistant to focus on enterprise customers, after which the interface updates accordingly. If you subsequently ask it to schedule a meeting with the account managers responsible for the regions with the largest decline, the assistant could potentially continue that workflow through the tools and accounts you have already connected.

At no point does the user have to decide which application to open, reconstruct the context or start the workflow again somewhere else. The conversation establishes the intent, while the interface provides the most appropriate way to explore or act on it.

For the right type of product, that combination can remove a surprising amount of friction.

The bigger shift may be distribution

The interactive possibilities of MCP Apps are what make them immediately tangible, but I suspect their longer-term impact may have more to do with distribution than with interface design.

For years, one of the central challenges of building a digital product has been getting users to come to it. Companies invest heavily in search, advertising, content, app stores, email, notifications and integrations because the product only becomes valuable once the user arrives at the website or opens the application.

AI assistants could start changing that relationship, because products no longer necessarily have to wait for users to find them. If someone is already working inside an assistant and asks a question that your product is particularly well equipped to answer, your product could become available at exactly that moment.

What makes MCP Apps especially interesting in that context is that your product does not have to disappear behind the assistant. Instead of supplying data that is turned into a generic paragraph, you can potentially show an experience with your own interface, interaction patterns, expertise and visual identity, while still benefiting from the context in which the user discovered it.

For product teams, that creates a question I think is worth considering now, even if MCP Apps are still relatively early: what happens when your homepage is no longer the most important entry point into your product?

We have become used to thinking about products as destinations, but they may increasingly behave as capabilities that can surface wherever the user happens to be working. If AI assistants become an important layer through which people interact with software, being available inside that layer could eventually become as normal as exposing an API, supporting mobile or integrating with the tools your customers already use.

That does not mean every SaaS product should immediately be rebuilt inside an AI assistant, but it does mean that distribution through AI clients deserves to be thought about as a product decision rather than simply an integration feature.

An MCP App still has to earn its interface

As with almost every new technology, there is a risk that the excitement around MCP Apps leads teams to build them simply because they can. We have seen the same pattern with mobile apps, chatbots, voice interfaces and, more recently, generative AI features that were added to products without solving a particularly meaningful problem.

Not every interaction needs an interface, just as not every interaction needs to become a conversation.

The interesting cases sit somewhere in between. Complex datasets often benefit from visual exploration, configuration becomes much easier when users can see and manipulate multiple options at once, maps are inherently spatial, rich media is better viewed than described, and multi-step workflows such as approvals often need visible state and clear actions. In those situations, an interactive component can make the AI experience substantially better than a sequence of prompts and responses.

If the user asks a straightforward question and the best answer consists of three sentences, however, returning three sentences is still the better product decision.

For me, that distinction is important because the opportunity is not to squeeze an entire existing SaaS application into Claude, ChatGPT, Copilot or whichever client the user prefers. The more interesting challenge is identifying which moments in your product genuinely become better when they can appear inside a conversation, and then designing those moments specifically for that context.

We are still learning what good looks like

It is also worth being realistic about where the technology is today. Support differs between clients, developer tooling is still evolving and an experience that works beautifully in one environment may need to fall back to something much simpler elsewhere. An embedded product also operates inside an environment it does not control, which introduces constraints around performance, security, interaction patterns and visual identity that teams building traditional web applications do not encounter in quite the same way.

In other words, being present inside an assistant does not automatically make a product experience better. If the interface is slow, confusing or unnecessary, embedding it closer to the user will only make those weaknesses more visible.

At the same time, I think those constraints are precisely what make this an interesting moment to start experimenting. The protocol itself is only one part of the challenge, and probably not the hardest one. The more difficult questions are about deciding which interactions deserve a UI, designing for clients that do not all behave in exactly the same way, creating graceful fallbacks when the interface cannot be rendered and making sure your product still feels recognisably yours when it is living inside someone else's environment.

Those are not merely integration questions. They sit at the intersection of product strategy, design and engineering, which is also why I expect the teams experimenting with this now to develop a useful head start as the ecosystem matures.

Because ultimately, the most interesting idea behind MCP Apps is not that we can put richer interfaces inside chat. It is that the relationship between users and digital products may be changing from “go to the product when you need something” to “let the right part of the product come to you when you need it.”

And if that shift continues, we may have to rethink much more than the interface.

Wondering what this shift could mean for your product, or whether an MCP App could create a genuinely better experience for your users? At Hatch, we help teams explore where emerging technology creates real product value, and turn that opportunity into a product that works in practice. Let's talk!