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

## Executive summary

This talk details the architectural challenges of building Model-Composable Platform (MCP) applications for large language models (LLMs) like Claude and ChatGPT. The core thesis is that for a UI widget to function effectively, it must be treated as a data layer, not just a visual display. The speaker outlines three critical rules for developers: all displayed information must be provided as data to the model; the tool description must explicitly state that a UI exists; and, most importantly, data processing must be strictly separated from UI rendering to maintain model context and reasoning capability.

## Key takeaways

- Data-First Design Principle: When building MCP apps, developers must focus on defining the data the model needs to process before considering the UI. The UI should be viewed as a side effect or result of the model exploring the underlying data.
- Rule 1: Show the Model Everything: Any information displayed to the user via the UI must also be provided as structured data to the model. Failing to do so creates a 'black box' that prevents the model from answering follow-up questions about the displayed content.
- Rule 2: Declare the UI in the Description: The tool description must explicitly state that a UI exists. Otherwise, the model will attempt to narrate the results underneath the widget, leading to redundant and confusing output.
- Rule 3: Separate Data Processing from UI Rendering: This rule supersedes the others. The architecture must split the job into two distinct tools: one for pure data retrieval (e.g., `search_jobs`) and a separate, dedicated tool for rendering the results (e.g., `render_jobs`). This allows the model to perform complex data exploration without being limited by the UI's single call.

## Technical details

- MCP Apps Architecture: MCP apps allow developers to integrate external web content (like job search results) into chat environments (Claude, ChatGPT) using dedicated SDKs, enabling features like embedded 'apply' buttons and detail modals without forcing the user to leave the conversation.
- Context Management: To track user interactions (e.g., clicking 'View Details'), the application must use methods like `update_model_context` to pass interaction events back to the model, ensuring the model remains aware of the current state.
- Tool Separation Mechanism: The recommended pattern involves creating a primary data tool (e.g., `search_jobs`) that returns raw data, and a secondary rendering tool (e.g., `render_jobs`) that accepts a list of IDs and handles the display logic. This separation is key to allowing the model to perform multi-step reasoning.

## Practical implications

- When designing APIs for LLM integration, treat the API contract as a state machine, not just a data endpoint.
- Implement a two-tiered tool structure: one for data retrieval/filtering, and one for presentation/rendering.
- Ensure that all user interactions that change the application state (e.g., filtering, clicking) are explicitly passed back to the model's context.

## Topics

AI Platform Development, Large Language Models (LLMs), Tool Calling, API Design, Build Engineering, State Management, MCP Apps

Source: https://www.youtube.com/watch?v=lbaXnx0KLA8