MCP Apps: extend your product experience into ChatGPT and Claude

Your product used to have an address

For most software companies, the product has always had a clear boundary: the website, the web app, or an app on a phone. You can advertise elsewhere, rank in Google, send emails and build integrations, but the actual product experience lives on a surface you control. That is where customers interact with your interface, your design and, ultimately, your brand.

AI assistants have started to change that. With MCP, ChatGPT and Claude can already interact with products without the customer opening the underlying web app. They can search a catalogue, retrieve an order, check availability or trigger an action directly from a conversation.

The problem is that most of the product disappears along the way. Your systems provide the data and perform the work, but the assistant owns the experience. The result is translated into a ChatGPT or Claude response, and your interface, interaction design and visual identity stay behind on your website.

MCP Apps changes that. It allows developers to render interactive user interfaces directly inside AI assistants. Instead of returning only data or text, an MCP server can return an interface built by your team and let the customer use it without leaving the conversation.

Think about a car configurator. Asking an assistant to describe every trim, finish and options package in text is possible, but it is not a particularly good way to choose a car. An MCP App could show the configurator itself inside the conversation, with the product imagery, the controls and the visual identity of the company that built it. The same applies to choosing a seat on a flight, comparing software plans or exploring a dashboard. These are experiences where an interface is simply better than another paragraph of generated text.

That is what makes MCP Apps interesting beyond the technical side of MCP. Your product experience no longer has to end at your own website. Parts of it can extend into ChatGPT, Claude and other assistants while remaining recognisably yours.

For brands building web applications, that creates a new kind of surface. ChatGPT and Claude are not only places where people can ask questions about your product. They can become places where people actually use it.

What are MCP Apps?

MCP Apps is an extension to the Model Context Protocol that allows MCP servers to provide interactive user interfaces alongside their tools.

The idea is straightforward. An MCP server already gives an assistant access to capabilities outside the model. A travel platform might expose hotels and bookings, a financial services provider might expose account balances and transaction history, a SaaS product might expose reports, projects or account settings. Traditionally the assistant calls one of those tools, receives structured data and turns it into a response.

With MCP Apps, the server can also provide an interface. That interface can be a small, purpose-built experience or a piece of an existing web application, and it runs inside the conversation with the controls, imagery, typography and interactions needed to complete the task.

The distinction matters. MCP made it possible to bring your product's capabilities into an assistant. MCP Apps makes it possible to bring part of the product experience with them.

MCP Apps builds on work that was already happening around interactive interfaces for assistants. OpenAI introduced its Apps SDK for building apps inside ChatGPT, while MCP-UI developed an open approach for bringing interactive interfaces to MCP. MCP Apps brings the concept into the Model Context Protocol itself.

Support is already appearing across several MCP hosts, including ChatGPT, Claude, Goose and VS Code. Teams can build around a shared protocol instead of treating every assistant as an entirely separate frontend project.

How MCP Apps work

From the customer's perspective, very little needs to change.

Imagine someone asks an assistant to change the delivery date of an order. The assistant can use MCP to retrieve that order from the company's systems, just as it could before. The difference is in what comes back. Instead of turning the available delivery dates into a list of text, the MCP server can tell the assistant that an interface belongs with the result, and the assistant renders that interface directly in the conversation, already populated with the relevant order and dates.

The customer can then interact with it. They might select a new date, change an option or confirm the update using controls built specifically for that task, and the interface communicates those actions back through MCP while the assistant stays aware of what is happening.

That last part is important. An MCP App is not simply a website embedded in a chat window. The interface and the assistant share context, so when the customer changes something in the interface, the assistant understands what happened and continues the conversation from there. That combination is where MCP Apps become more useful than embedding another web page.

There are technical requirements around how these interfaces are registered, rendered and secured. We cover those in our MCP Apps documentation rather than duplicating the implementation details here.

From MCP tools to product experiences

Some things are simply better shown than described.

Search is a good example. Ask an assistant for three hotels and text might be enough. Ask it to help you choose between twenty hotels based on location, room type, dates and price, and you quickly start rebuilding filters and comparisons through conversation.

The same problem appears across software. A chart is easier to understand as a chart. A seat map works better when you can see the seats. A colour picker should probably remain a colour picker. A calendar is often faster than discussing dates one at a time.

Before MCP Apps, connecting those products to an assistant often meant reducing a visual product experience to text. Now the interface can follow the capability. A retailer can show products using its own imagery and controls. An analytics product can render the chart instead of asking the model to describe it. A project management tool can show a board or timeline when that is the better way to understand the information.

The assistant still handles the conversation around the task, and the product handles the part it was designed to do visually. Good conversational interfaces are excellent at understanding vague requests. Good graphical interfaces are excellent at presenting choices, relationships and state. MCP Apps lets products use both.

What MCP Apps mean for brands

Your interface can now exist outside your own application, which is easy to overlook when the focus is on the technology.

Until now, integrations usually meant giving another product access to your data or functionality, and the experience around that functionality belonged to whoever built the integration. If your hotel inventory appeared in an assistant, the assistant decided how those hotels were presented. If your analytics platform returned a result, the assistant decided how to explain it. MCP Apps gives some of that presentation layer back to the company providing the product. Your product imagery remains your product imagery. Your controls behave the way your customers recognise. Your typography, colours and visual hierarchy travel with the functionality they belong to.

This does not mean reproducing your entire website inside ChatGPT, which would miss the point. The more interesting opportunity is to identify the parts of your product that matter at a specific moment and make those available when the assistant needs them. A retailer does not need to embed its entire ecommerce site. Product comparison, configuration and checkout would do. A SaaS company might expose the chart, editor or approval screen that fits the task at hand.

These become small extensions of the product rather than miniature copies of the website, and because they appear inside the conversation, the customer does not have to switch context to use them.

There is a wider shift underneath that. The starting point used to be navigation, and with an assistant it is intent. Someone says what they want to accomplish, and the assistant decides which capabilities can help them get there. MCP already gave products a way to make those capabilities available, and MCP Apps adds the missing visual layer. Your website can remain the full expression of the product while smaller pieces of its interface appear wherever customers are already working or asking questions.

Not every web application needs a ChatGPT version. The change is that the boundary around a web application has become less rigid. Your product can start on your domain without having to end there.

Your brand travels, the environment is not yours

You control the interface you build. You do not control the environment around it.

ChatGPT still looks and behaves like ChatGPT. Claude still looks and behaves like Claude. The host decides when an MCP App is shown, how it is contained and which rules it has to follow.

That matters for brands. An MCP App is an extension of your experience into another environment, not a replacement for your own web application. Your website remains the place where you control the complete experience, from navigation to account management and everything around it.

There are technical boundaries too. The interface runs in a restricted frame and cannot assume the same access it would have running directly on your own domain. Persistent state, authentication and communication with external services all need to be designed around the rules of the host and the MCP Apps specification. Those restrictions are intentional. An assistant needs to be able to render third-party interfaces without giving every app unrestricted access to the environment around it.

For product teams, the practical consequence is simple. Design the app for the environment it runs in rather than trying to squeeze your existing website into a smaller window. The best MCP Apps will feel recognisably like the product behind them while still feeling natural inside the assistant.

How to get started with MCP Apps

The best place to start is not your homepage. Look at what people actually come to your product to do, and find a task that already works through MCP, or could work through MCP, but becomes awkward when everything has to be translated into text. That is usually where an interface adds the most value.

For an ecommerce platform that might be comparing or configuring products. For analytics software, exploring a chart. For an internal application, reviewing and approving something.

Keep the first version small. Build the interface for that task, make it available through your MCP server, and see how it feels when the conversation and the product start working together.

If your team already runs an MCP server, MCP Apps is an extension of what you have rather than a separate platform to build and maintain. If you are starting from scratch, our MCP Apps documentation covers the technical implementation.

The question is not whether every part of a web application belongs inside an assistant. Most of it probably does not. It is which parts of your product become more useful when they can appear exactly where the conversation is already happening.