# MCP Apps: Give the Model Data, Give the User a UI — Dustin Mihalik, Indeed

Source: [AI Engineer](https://www.youtube.com/watch?v=lbaXnx0KLA8)  
Feed7 permalink: https://feed7.dev/p/mcp-apps-give-the-model-data-give-the-user-a-ui-dustin-mihalik-indeed-1gi9v8k  
Published: 2026-09-09T15:30:08.000Z  
Trust: Source Linked (source_linked)

## Why Included

An MCP widget can reduce an agent’s useful work if rendering and retrieval share one tool. Keep data exploration separate, then render only the results the model selects.

## Source Summary

Indeed found that text-only MCP could run **10–15 searches**, filter the results, and build a useful answer, while a UI-enabled search tool was often called once. Widgets must return both **structured content and a resource URI**, with user interactions sent back through model context.

## Practical Implication

Split data operations from presentation. Let the agent call small search tools repeatedly, choose the relevant records, and then pass their IDs or data to a dedicated render tool; keep UI state visible to the model.

## Agent-Ready Context

Indeed found that text-only MCP could run **10–15 searches**, filter the results, and build a useful answer, while a UI-enabled search tool was often called once. Widgets must return both **structured content and a resource URI**, with user interactions sent back through model context.

Split data operations from presentation. Let the agent call small search tools repeatedly, choose the relevant records, and then pass their IDs or data to a dedicated render tool; keep UI state visible to the model.

Tool descriptions can steer what appears in prose versus the widget, but this remains a coordination problem. A polished component does not guarantee that the model will explore enough data before rendering.

## Connected Context

Feed7 judgment across 732 accumulated Signals:

This adds an interface-quality tradeoff to MCP context engineering: a polished widget may reduce repeated retrieval and filtering, so presentation can inadvertently narrow the evidence the model explores. Separating small data tools from a dedicated renderer preserves iterative selection while making UI state part of model context. It deepens the case for MCP Apps but warns that interactivity alone does not ensure adequate retrieval.

- [MCP Apps: Extending the Frontier — Ido Salomon & Liad Yosef](https://feed7.dev/p/mcp-apps-extending-the-frontier-ido-salomon-liad-yosef-1gtlsr9) — It turns the candidate’s general MCP Apps architecture into an implementation pattern—separate retrieval from rendering—and identifies premature rendering as a new coordination failure mode.
- [AI on Your Lakehouse: Context Comes in Shapes, Not Queries — Zach Blumenfeld, Neo4j](https://feed7.dev/p/ai-on-your-lakehouse-context-comes-in-shapes-not-queries-zach-blumenfeld-0r4s9u5) — Both stress that answer quality depends on exposing useful structure before presentation; graph-shaped retrieval can broaden the records available, while the render split helps prevent the UI call from ending exploration too early.
- [Latest MCP spec now supported in mcp-handler](https://feed7.dev/p/latest-mcp-spec-now-supported-in-mcp-handler-1kkt3s0) — The server migration requirements are a prerequisite concern for deploying the structured-content and resource-based MCP App pattern on the newer protocol stack.

## Context Map

- Layer: context
- Domains: data
- Topics: mcp, context-engineering, tool-use

## Uncertainty

- Tool descriptions can steer what appears in prose versus the widget, but this remains a coordination problem. A polished component does not guarantee that the model will explore enough data before rendering.

## Agent Instruction

Use this item as source-backed context. Do not invent claims beyond the linked source. If this item conflicts with another source, call out the conflict.