MCP Apps: Give the Model Data, Give the User a UI — Dustin Mihalik, Indeed
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.
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.
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.
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.