Visualizing Results: From Markdown Tables to MCP Apps

We have spent a lot of time discussing how AI can access data. We talk about connectors, APIs, MCP servers, databases and tools. But accessing the data is only half of the experience. The other half is how the result is presented to the user.

Ask an AI assistant for the ten most recent contacts in a CRM and it may return the correct ten records. That does not necessarily mean it has returned them in the most useful form. A paragraph is difficult to scan. Raw JSON is designed for machines, not people. Even a basic table can become frustrating when the user wants to search, sort, filter, open a record or take an action.

This is why visualizing results is becoming an important part of AI product design. The question is no longer only, “Can the model retrieve the answer?” It is also, “What is the best interface for understanding and using that answer?”

There are three main levels: native Markdown, generated HTML and MCP Apps.

1. Native tables: fast, simple and often enough

The simplest option is the table the AI assistant can create directly in its answer. Claude, ChatGPT and other assistants commonly produce these tables with Markdown. Markdown provides a lightweight way to define rows, columns, headings and links without building a separate interface.

This approach is immediate. It requires no front-end development, no hosting and no additional UI layer. It works particularly well for short comparisons, summaries and small datasets. If I ask for ten recent contacts, campaign performance by channel or the differences between three pricing plans, Markdown may be all I need.

Its limitations appear as soon as the user wants to explore the data. A Markdown table usually has no search field, filters, pagination, visual states or custom actions. It may become difficult to use on a small screen, and large datasets quickly produce long, unwieldy answers. The model can create a new table after another prompt, but every change becomes another conversational turn.

Markdown is therefore best understood as a representation of an answer. It is not a full application.

2. HTML representation: more control over the result

The next option is to ask the AI to represent the result as HTML. The data may be exactly the same, but HTML gives us much more control over layout, spacing, typography, responsive behaviour and basic interaction.

An HTML result can include a search field, sortable columns, tabs, cards, badges, charts and buttons.
CSS can make it match a brand rather than the default style of the chat host. JavaScript can add client-side filtering or calculations. For a report, a prototype or a self-contained analysis, this can be a major improvement over Markdown.

However, an HTML representation is not automatically connected to the underlying system. The assistant may generate a page from a snapshot of the data, but the page does not necessarily know how to refresh itself, retrieve the next page of results, update a contact or call another business tool. It may look like an application while still behaving like a generated document.

This distinction matters. HTML solves the presentation problem. It does not, by itself, solve the integration, permissions, state or action problem.

3. MCP Apps: when the result becomes an interface

The third option is an MCP App. Here, the result is not merely formatted. It is rendered through a purpose-built interface that is attached to an MCP tool and displayed directly inside the conversation.

The difference is visible, but it is also architectural. The interface can receive structured results from the tool, let the user search or sort them, request more data and call tools again when the user interacts. A contact list can open a record. A chart can change its date range. A campaign dashboard can drill down from a channel to an ad. A form can validate its fields and then submit an approved action.

The conversation remains the context, while the MCP App provides the controls. The model handles intent and reasoning. The interface handles direct manipulation, navigation and visual feedback.

The technology underneath: MCP Apps and SEP-1865

The technology behind this approach is the MCP Apps extension, originally proposed as SEP-1865 in November 2025. It was developed through the Model Context Protocol community with contributors from OpenAI, Anthropic and MCP-UI. On January 26, 2026, MCP Apps became the first official MCP extension and was described as ready for production.

The standard addresses a gap in the original Model Context Protocol. Traditional MCP tools can return text, images, resources and structured data. That is enough for the model to reason about the result, but it is not enough for every user experience. Dashboards, maps, forms, media players and multi-step workflows need a richer interface.

The MCP Apps pattern has three participants. The server defines the tools, returns data and exposes a UI resource. The host is the AI client in which the conversation takes place. The view is an HTML and JavaScript application rendered by the host inside a sandboxed iframe.

A tool connects to its interface through metadata, using _meta.ui.resourceUri. That value points to a UI resource with a ui:// URI. When the tool is called, a compatible host fetches the resource, renders it and passes the tool input and result to the view. The view and host communicate through JSON-RPC over postMessage. This allows the interface to receive updates, send messages and request additional tool calls without being given access to the host page itself.

This design is also meant to degrade gracefully. The underlying tool should remain useful without the custom component. If a host cannot render MCP Apps, it can still use the tool’s text or structured result. The enhanced interface is an additional layer, not a replacement for a well-designed tool response.

Can I implement an MCP App myself?

Yes. If you already have an MCP server that exposes your data and operations, you can add a UI resource and associate selected tools with it. The interface can be written with ordinary HTML, CSS and JavaScript, or with a framework such as React. The official MCP Apps package provides the bridge between the interface and the host.

The technical work is only one part of implementation. You must also design authentication and authorization correctly, validate every tool call on the server, request only the permissions you need and keep secrets out of tool metadata and results. The UI runs in a sandboxed iframe and its network access is controlled through a Content Security Policy. Write actions should be explicit, scoped and confirmed when they are consequential.

You also need to separate three ideas that are frequently mixed together: building an app, connecting it privately and distributing it publicly. A host may support MCP Apps while still applying plan, workspace, administrator or rollout restrictions to custom connectors. A developer may be able to test an MCP server privately without having an unrestricted route to publish it to every user. Public distribution can introduce additional review, branding, privacy, security and platform-policy requirements.

Current MCP documentation lists Claude web and desktop among the clients supporting MCP Apps. Therefore, it would be inaccurate to say simply that Claude has not opened the technology to everyone. The safer statement is that availability of a specific connector or app may still depend on the product surface, account, workspace policy and distribution route. Before launching, check the current terms, connector rules and submission requirements of each host you intend to support.

Can I use somebody else’s visual interface with my data?

Potentially, but not automatically.

The promise of MCP Apps is portability across compatible hosts, not unrestricted interchangeability between every dataset and every third-party interface. A UI is normally associated with one or more tools and expects a particular result structure. An Ahrefs visualization, for example, can only visualize GrowthOS data if the relevant tool is designed to accept that data, both systems expose a compatible schema, or the host can route an explicitly supported action between the connected capabilities.

This creates an interesting new possibility. A company may specialise in the data while another specialises in the interface. GrowthOS might retrieve and structure the information, while a connected visualization tool presents it, provided the integration contract, permissions and schemas support that flow. But connecting both tools does not guarantee that the host can pour the result of one into the UI of the other. That behaviour must be supported deliberately.

The reusable asset is not just the visual design. It is the combination of the UI, its expected data contract, the available actions and the permissions surrounding those actions.

How to create your own MCP App

Assuming you already have an MCP server for your data, the practical process is straightforward. Choose the tool result that deserves a visual interface. Define the structured data the UI will receive. Build the HTML interface. Register it as a ui:// resource. Reference that resource from the tool’s _meta.ui.resourceUri. Then test the plain result and the enhanced result separately, including authentication, error states, loading, empty results, permissions and mobile layout.

You can use the following prompt with a coding agent to produce a first implementation:

I already have a working MCP server that exposes my data and tools.

Create an MCP App interface for the following tool:

Tool name: [TOOL_NAME]
Tool purpose: [WHAT_THE_TOOL_DOES]
Tool input schema: [PASTE_INPUT_SCHEMA]
Tool result example: [PASTE_A_REDACTED_STRUCTURED_RESULT]

The interface should help the user: [DESCRIBE_THE_USER_GOAL].

Build the UI using [HTML/CSS/JavaScript or React]. Register it as an MCP Apps UI resource using a ui:// URI and connect the tool to it using _meta.ui.resourceUri. Use the current @modelcontextprotocol/ext-apps package and the standard ui/* JSON-RPC bridge. Do not rely on host-specific APIs unless a required capability is not covered by the MCP Apps standard.

Requirements:

1. Render the tool's structuredContent in a clear, responsive interface.
2. Include [SEARCH, SORTING, FILTERS, PAGINATION, CHARTS OR OTHER CONTROLS].
3. Let the interface call [LIST THE MCP TOOLS IT MAY CALL] when the user interacts.
4. Keep the original tool useful in hosts that do not render MCP Apps by returning a concise text summary and structured data.
5. Add loading, empty, partial-data and error states.
6. Respect the host theme, locale, timezone and available display mode.
7. Use a sandbox-compatible implementation and declare the minimum CSP domains required.
8. Never expose secrets, access tokens or unnecessary personal data to the UI.
9. Validate authorization and all inputs on the MCP server. Require confirmation before consequential write actions.
10. Provide the complete server registration code, UI code, build commands, directory structure and local testing instructions using MCP Inspector.

First inspect the existing MCP server structure and reuse its language, SDK, authentication and deployment conventions. Then explain the proposed data contract before writing code. Do not invent tools, fields or permissions that are not present in the server.

The quality of the result will depend heavily on the information supplied in the prompt. A real tool schema, a redacted result example and a precise description of the user interaction are more valuable than a long visual description.

The real shift: from answers to usable outcomes

Native tables, HTML and MCP Apps are not competing answers to the same problem. They are different levels of interface commitment.

Use Markdown when the result is small, temporary and mainly intended to be read. Use HTML when presentation, branding or lightweight client-side exploration matters. Use an MCP App when the user needs to interact with live data, preserve state, navigate a workflow or take actions through connected tools.

The most important principle is not to choose the most advanced option by default. It is to match the interface to what the user needs to do next. Sometimes the correct answer is six rows in a table. Sometimes it is a searchable report. Sometimes the result should become a small application inside the conversation.

AI systems are learning to retrieve and reason over more of our data. Their next usability challenge is to stop treating every result as text.

Do we need approval for our MCP App?

Not simply because it uses MCP. There is no central MCP authority that approves every server or app. The answer depends on where and how you want people to use it.

If you are connecting the MCP App privately for development, for your own account or inside an organization, you usually do not need a public marketplace review. You still need the user or workspace administrator to permit the connector, and you must comply with the host’s terms, security requirements, privacy rules and authentication policies. If you want the app to be publicly discoverable and installable, the host may require a formal submission and review.

ChatGPT

You can develop and test an MCP-backed app privately without first passing public directory review. To publish it for general discovery in ChatGPT and Codex, however, OpenAI requires submission through its plugin publishing process. The review covers the MCP server and any optional UI, and public publishers must complete individual or business identity verification. The app must also satisfy OpenAI’s requirements for authentication, privacy, security, tool behaviour, UI and metadata.

In short, private testing does not mean public approval, while publication in the public directory does.

Claude

Claude allows users to add remote MCP servers as custom connectors. Anthropic’s current documentation says custom connectors are available across Free, Pro, Max, Team and Enterprise plans, although Free accounts are limited to one. A privately added connector does not need to become a reviewed directory listing first.

There are still approval layers. The user must approve the connector and its requested tool access. Team and Enterprise administrators can restrict connectors, require approval for tool calls or block them. A connector offered through Anthropic’s public directory is a reviewed connector, so public distribution should be treated as a separate path from adding a private URL.

Gemini

Here we need to be precise about what “Gemini” means. The Gemini API supports tools and function calling, and Google products such as Gemini CLI can work with MCP servers. That does not automatically mean that every Gemini consumer interface will render an MCP Apps ui:// component or offer a public marketplace where the app can be submitted.

If we build our own application using the Gemini API, we control the host and can connect our MCP server without asking Google to approve the MCP App itself. We are still responsible for Google’s API terms, data handling and safety requirements. Additional Google verification may apply if the application uses OAuth, sensitive or restricted Google scopes, or another Google distribution channel. Before promising the same embedded visual experience in the Gemini app, we should verify that the exact Gemini host supports the MCP Apps extension, not merely MCP tool calls.

Perplexity

Perplexity currently documents the ability to connect a user-supplied remote MCP server to its Agent API. Its documentation does not establish a public MCP App directory or support for rendering MCP Apps interfaces inside the Perplexity consumer product. Therefore, we should not assume that our ui:// interface will appear there simply because the MCP tools can be called.

There is also an important execution difference: Perplexity’s Agent API documentation says MCP tool calls currently run automatically and that MCP approval pause-and-resume flows are not supported. That makes strict allowlists, read-only tools and server-side authorization especially important. This is tool execution support, not evidence of public app approval or UI support.

The safest launch sequence is to build the MCP server and UI against the open standard, keep a strong text and structured-data fallback, test each target host separately, and only then follow the public submission process of any host in which we want directory distribution. “Works with MCP” does not necessarily mean “renders MCP Apps,” and “can be connected privately” does not mean “approved for public distribution.”