MCP Apps: bring analytics into the conversation

← All field guides

A product manager asks, “Where did our conversion rate fall last week?” A text answer can identify a change. A dashboard can expose the data. But the immediate task is smaller: compare periods, choose a segment, inspect the underlying counts, and decide what to investigate next.

An analytics widget delivered inside the conversation can serve that task directly. The user starts with a question, receives a small interactive view, and adjusts it without repeatedly translating every click into another prompt. The agent can then help interpret the selected slice.

What MCP Apps adds to a tool response

MCP Apps is an official extension to the Model Context Protocol, announced on 26 January 2026. It lets a tool declare an interactive interface that a supporting host can display within a conversation. Charts, tables, forms, and drill-down controls can accompany the answer. Source: official launch announcement.

The core pieces are a tool and a UI resource. Tool metadata points to a ui:// resource; the host loads the interface in a sandboxed iframe and delivers the tool’s data. The UI is an application you build and maintain—not necessarily a new chart that the model generates from scratch on every turn. Source: MCP Apps quickstart.

This requires an MCP Apps-capable host. Connecting an ordinary MCP server does not guarantee that a client will render widgets. Check the target client’s extension support, deployment rules, and available UI capabilities. Keep a useful text response for clients that cannot display the interface. Source: architecture and capability overview.

A worked example: investigate a conversion decline

The following is an illustrative product design, not a measured deployment. Consider a commerce team investigating checkout completion. Instead of opening a portal and reconstructing the question with dashboard filters, a user asks the agent to compare the latest complete week with the previous week.

1. The agent resolves the question. Confirm the business timezone, the definition of checkout completion, and whether “last week” means a calendar week or the previous seven days. Show those choices in the answer.
2. A server returns a bounded result. Query the approved metric service for checkout starts, completed checkouts, and the derived completion rate. Include both comparison periods and the data’s freshness timestamp.
3. The chat shows an interactive view. Present a trend chart, the current and previous rates, absolute counts, and filters for device and region. A visible denominator prevents a percentage from becoming an unexplained number.
4. The user explores. Selecting “mobile” requests the corresponding slice. Sorting already loaded rows stays local. Fetching a different segment goes back to the server with the user’s authorization.
5. The conversation continues with evidence. An “Explain this selection” action shares the selected filters, metric definition, comparison, and result reference with the agent. The agent can suggest checks; a correlated segment is not proof of a cause.

The advantage is continuity: the question, the visual evidence, and the next investigation stay together. A widget is particularly useful when a user knows what they want to understand but does not know which dashboard or filter combination will answer it.

Keep the analytics backend; change the delivery surface

1. User + agent chatQuestion, clarifications, and interpretation
2. MCP tool + UI resourceA bounded query and a reusable view
3. Authorized analytics serviceMetric definitions, access checks, and aggregation
4. Widget inside the hostChart, table, filters, and a result timestamp

User interactions return through the host to server tools; selected context can be shared back with the agent.

Separate the initial analysis from follow-up interaction. A model-facing tool such as open_conversion_analysis can accept a period, comparison, and approved dimensions. A more narrowly scoped tool can fetch the next page or refresh the selected slice.

The extension supports tools visible to the model, the app, or both. An app-only tool can handle UI interactions without adding another tool to the agent’s advertised tool list. Visibility does not replace server authorization. The linked specification is a living draft: pin and test the SDK and protocol revision you ship. Source: tool metadata and visibility specification.

A useful result contract should include the metric identifier and version, requested filters, period boundaries, timezone, values and denominators, freshness, and a query or snapshot reference. Distinguish a genuine zero from unavailable data. Those are application responsibilities, not facts the model should invent.

Make the widget and the agent agree

The SDK exposes methods such as callServerTool for server requests and updateModelContext for sharing context with the host. Design explicitly when to send a selection summary. Do not assume the agent automatically sees every local filter change, hover, or row selection. Source: App API reference.

For this example, share “mobile, India, completed weeks, metric v3, result 42” together with the relevant aggregates. Keep transient hover events local. Avoid sending entire detail tables merely to explain a trend, and do not assume that a field is hidden from the model simply because it is structured data.

Preserve the difference between the result originally discussed and a newly refreshed result. If the user returns later, show the original snapshot time and offer an explicit refresh. Persist saved investigations in your application when needed; chat history alone is not a reliable analytics state store.

Where this can reduce product work

• Less navigation to build. A focused widget may avoid a separate landing page, dashboard catalog, and filter-heavy navigation flow for a narrow use case.
• Fewer conversational round trips. Users can change a filter or inspect a row directly. Local interactions need not invoke the model; server queries and host behavior still determine latency.
• Reusable views. A reviewed trend-and-breakdown component can serve many questions against the same metric contract, instead of relying on fresh generated UI for each answer.
• A smaller first release. One decision-oriented view gives the team a concrete scope to evaluate before building a broad analytics workspace.

These are design hypotheses, not guaranteed savings. You still build the UI, queries, identity integration, permission enforcement, observability, and tests. Integration with multiple hosts can add compatibility work. Compare total effort and task outcomes against the dashboard your users would otherwise use.

Choose the surface around the job

The hybrid option is often practical: expose existing analytics through a small MCP App and retain a link to the full report. Sharing the metric service keeps the widget’s numbers consistent with the dashboard. An inline view should earn its place by reducing the steps to a decision.

Make the numbers trustworthy and the interface usable

Enforce tenant, row, and field access on every server request. A tenant identifier supplied by a model or browser is not evidence of permission. Keep credentials out of the widget, validate filter values, bound query cost, and record enough provenance to investigate disagreements.

MCP Apps uses sandboxed UI execution and host-mediated communication, but that is only part of the security design. Review resource dependencies and the allowed network policy for the target host. Treat chart labels and returned text as data, and keep authorization independent of instructions embedded in that data. Source: extension security model.

Build loading, empty, stale, partial, and error states. When filters change quickly, prevent a slower old response from overwriting the latest selection. Provide keyboard-accessible controls and a table or textual equivalent for the chart. Test narrow chat containers, large text, and both themes. Begin with read-only analytics; an action such as issuing refunds deserves its own permission and confirmation flow.

A practical first pilot

Choose a recurring question with a known correct answer and an existing trusted data source. Build one view with a trend, one breakdown, two filters, and an “Explain this selection” action. Keep the first integration to one explicitly supported host and provide a text fallback.

1. Establish a baseline: observe how users answer the question with the current dashboard.
2. Check correctness: reconcile totals, rates, time boundaries, access restrictions, and stale-data behavior against reference queries.
3. Measure the task: compare time to a correct answer, unnecessary prompts, query latency, model and backend cost, and failed investigations.
4. Test the handoff: verify that a follow-up question refers to the user’s actual selection, and that the full-report link preserves the same scope.
5. Decide from evidence: keep the widget if it improves the workflow; expand only when the next user need is clear.

The opportunity: deliver the smallest trustworthy analytics experience at the moment someone needs it. MCP Apps provides a way to place that experience in the conversation. Your metric definitions, product design, and evaluation determine whether it is better than opening a dashboard.

Sources and scope

Reviewed 5 November 2026. Protocol descriptions are based on the official sources below. The conversion example, architecture recommendations, decision table, and pilot plan are editorial guidance; no performance or cost improvement is claimed as a measured result.

• MCP maintainers: official extension launch and security model.
• MCP Apps: architecture, capabilities, and fallback behavior.
• Official quickstart: registering a tool and its UI resource.
• Living specification draft: resource metadata and tool visibility.
• App API: host communication and context updates.