Talk by Dustin Mihalik (Indeed) on lessons learned building MCP (Model Context Protocol) apps for Claude, ChatGPT, and Indeed's job seeker agent. Covers why a UI is worth adding despite chat hosts resisting outbound links, and presents three rules for MCP app design: (1) everything shown to the user must also reach the model as data, (2) tool descriptions must mention that a UI exists, and (3) data processing must be separated from UI rendering, e.g., a plain search tool plus a render widget taking a list of ids. Also addresses pushing user interactions back through update model context, and closes on data-first design, small composable tools, and letting the render tool carry the model's reasoning. Includes chaptered timestamps. # Video Identity Observations: MCP Apps Talk — Dustin Mihalik, Indeed ## Speaker Self-Identification - **Speaker:** Dustin Mihalik (transcribed as "Macholic"), an engineer at Indeed. > "I'm Dustin Macholic. Uh I work at Indeed. Uh we're the number one job site in the world." - **Team/role claim:** Works on Indeed's **AI platform** team, specifically: > "I do like AI guardrails and and gateways and compliance stuff." ## Explicit Claims About the Work Being Shown - The talk covers **"practical MCP apps"** and **"lessons from the trenches"** from building MCP and MCP apps for multiple environments: > "...what did we learn in building MCP and MCP apps for Claude chat chat GPT and our own internal uh uh career scout, which is our uh agent that we have for job seekers." - Vendor relationships are cited as the origin of the project: > "occasionally uh my team gets cool projects to work on because we have relationships with the vendors. Uh MCP apps is one of those." ## Intended Audience - **Developers and engineers** already familiar with MCP concepts — the speaker frames this as a follow-up to an introductory talk: > "They gave a great introduction uh to MCP apps. This is a little bit of a lessons from the trenches." - Audience members considering building MCP apps themselves: > "if you're thinking about hey, I want to build an MCP app or I want to take my website, I want to put it in ChatGPT or Claude..." - The talk assumes technical familiarity (tool descriptions, structured content, API design, evals). ## Claimed/Demonstrated Scope ### Demonstrated domain expertise - Concrete engineering lessons presented as numbered **rules**: 1. Return data to the model for anything shown in the UI: > "anything that you show to the user also needs to be provided as data to the model." 2. Update tool descriptions to reflect UI rendering: > "results were automatically displayed to the user as UI components." 3. **Separate data processing from UI rendering** — explicitly attributed: > "this particular wording I stole uh from OpenAI uh Apps SDK documentation." - References the **MCP spec**, **MCP apps spec**, `update_model_context` method, and OpenAI Apps SDK documentation — grounding claims in specific technical sources. ### Organizational context claimed - Indeed is positioned as a major MCP adopter, building agents for job seekers ("Career Scout") and integrating with Claude, ChatGPT, and internal tools. - Scale-of-effort claim: > "it took us a ridiculous number of hours and evals to make sure that like Claude would consistently link to things." ## Presentation Style (Observable) - **Conference talk format** with slides/screenshots: > "I have a lot of screenshots of job searches." - Casual, first-person, experience-driven delivery with caveats about currency of material: > "this is out of date cuz there's no Sonic 5 here yet, but uh this is screenshot from 2 days ago." - Interactive close inviting hallway questions rather than a booth: > "I don't have a booth that I'm going to hang out in, but I'll I'll hang out in the hall if anyone has any questions. And I am either my last name or my first initial last name on most social media platforms." ## Notes for Channel Synthesis - This video demonstrates a channel/publisher featuring **practitioner conference talks** from named industry engineers (title format: topic — speaker, company). - No explicit channel self-description appears in the transcript itself; identity evidence is limited to the talk's speaker, format, and assumed technical audience. - No private motivations were stated; all observations above trace to quoted transcript passages. # Delivery Observation: MCP Apps Talk — Dustin Mihalik (Indeed) ## Tone & Overall Manner - **Conversational, self-deprecating, informal.** Opens with an apology about his voice: *"I have to apologize for my voice. I'm recovering from a cold."* - **Practitioner tone rather than polished keynote style** — explicitly frames the talk as *"a lessons from the trenches"* rather than introductory material. - Honest admission of running short: *"I'm a few minutes few minutes fast."* ## Verbal Fillers & Disfluencies (Highly Frequent) - **Heavy use of "uh" and "um"** throughout, often clustered: *"Uh we're the number one job site in the world. Uh I have to apologize..."* - **Immediate self-corrections and word repetition:** - *"this is this is the chat-based interface"* - *"it gives you it gives you some UI"* - *"I don't give I don't give the I don't I don't give Claude uh my easy problems"* - Notable stumble on his own framing: the title says **Mihalik** but he says *"I'm Dustin Macholic"* — possible mis-transcription; noted as uncertainty. ## Recurring Vocabulary & Phrases - **"Black box"** as a repeated explanatory metaphor: - *"it basically becomes a black box to the model"* - *"that's that just makes a big black box for the model"* - *"you provided this black box that it has no idea about"* - **Repeated rule structure:** *"the very first rule uh for me"*, then *"this is rule three, this like supersedes all the other rules."* (Rule two is implied but not numbered explicitly — slight inconsistency in the framing.) - **Repeated phrase "you need to"** for prescriptive advice: *"you need to return both of these"*, *"you also need to provide to the model."* - Frequent hedging with **"you know"** and **"like"**: *"basically uh you know, I'm looking for barista in Austin."* - **"So"** as a primary transition word, starting many sentences. ## Teaching Habits & Structure - **Problem → mistake → solution pattern.** He repeatedly shows a naive approach first, then its failure, then the fix: - *"if you do a very naive thing, uh which is you still call your existing APIs"* → black box problem → structured content fix. - **Concrete examples anchored in one domain (job search)** — announced early: *"a lot of my examples are going to be job search."* - **Hypothetical user questions as illustrations:** *"tell me about the first result, or please rank this list of companies"*; *"write a cover letter for this job."* - **Attribution to sources:** *"this particular wording I stole uh from OpenAI... Apps SDK documentation."* - **Humor through understatement:** *"it took us a ridiculous number of hours and evals"*; *"this is out of date cuz there's no Sonic 5 here yet."* ## Closing Habits - Ends with **accessibility, not a booth:** *"I don't have a booth that I'm going to hang out in, but I'll I'll hang out in the hall if anyone has any questions."* - Brief social-media plug: *"I am either my last name or my first initial last name on most social media platforms."* ## Uncertainty Notes - Audience laughter/snorts are marked in the transcript but timing attribution is ambiguous, so humor reception cannot be fully characterized. - Some transcription anomalies (*"Macholic"*, *"MCP abstract"*, *"Sonic 5"*) — likely mis-transcriptions; observations rely only on clearly readable passages. # MCP Apps: Give the Model Data, Give the User a UI — Position Record **Speaker:** Dustin Mihalik (transcribed as "Macholic"), Indeed — AI platform team (AI guardrails, gateways, compliance). Talk framed as "lessons from the trenches" building MCP and MCP Apps for Claude, ChatGPT, and Indeed's internal agent **Career Scout**. ## Context & Motivation - Indeed builds job search; his team got early access to **MCP Apps** and **MCP connectors** through vendor relationships. - Most examples use job search scenarios (e.g., "barista in Austin"). ## Problem with Chat-Only MCP - Text-based responses work well, but lack **branding** and control over presentation. - Getting Claude or ChatGPT to **link to external pages** is difficult: > "It took us a ridiculous number of hours and evals to make sure that like Claude would consistently link to things." - Returning job results without links is, per Mihalik, "a terrible user experience." - MCP Apps / Apps SDK let Indeed control UI: apply button, highlighted content, and a "view details" modal so users don't leave the chat environment — described as a "win-win for both companies." ## Rule 1: Give the Model the Same Data You Show the User - Naive approach — calling existing APIs inside the app — creates a **black box**: the model doesn't know what's displayed, so follow-ups like "tell me about the first result" fail. - **Rule:** "Anything that you show to the user also needs to be provided as data to the model." - Implementation: return both **structured content** (as in text-based MCP) and the **resource URI** pointing to the HTML — and keep them in sync as the API evolves. - He notes he has seen MCP apps that only inject HTML and call APIs, creating this black box. ## Supplementary Practices - **Update tool descriptions** so the model knows results are displayed as UI; otherwise the model redundantly re-describes the output in text. Example description text: "results were automatically displayed to the user as UI components." - **Report user interactions back** via the MCP `update model context` method (a single string, requiring manual appending for multiple events), citing the MCP Apps shopping-cart documentation example. ## Rule 3 (Superseding): Separate Data Processing from UI Rendering - Motivation: he gives Claude hard problems — e.g., multi-city relocation searches with salary and industry filters. Text-based MCP handles this well (10–15 searches, filtering, summary table). - But a naive MCP App defeats it: once results render, the model assumes display is done and won't do deep dives — and users don't want "10 different carousels." - **Solution** (wording he attributes to OpenAI's Apps SDK documentation): separate data processing from UI rendering. - A text-based search tool the model can call repeatedly (`search jobs`). - A separate **render tool** (`render jobs widget`) taking a list of job IDs the model selects after exploring/filtering. - Render tool descriptions should state dependencies (e.g., "always call one of these three tools first"). - Generalizable to other domains: e-commerce, maps (pass in five addresses). - **Creative render tools:** let the model pass reasons ("why this is a good fit") or highlight sections of job descriptions, injecting "extra character" into the UI. ## Key Takeaways (as stated) 1. **Focus on data before UI** — rendering should be a result/side effect of the model exploring data, not the primary goal. 2. **Small composable tools** — multiple search tools, one or two render tools; simple descriptions avoid overloading the model while preserving flexibility in how it explores and renders. ## Qualifications & Unresolved Points - Mihalik numbers his rules (1, then "rule three, this supersedes all the other rules") without explicitly articulating a rule two in the transcript. - A job-search screenshot is acknowledged as out of date ("there's no Sonic 5 here yet… screenshot from 2 days ago"). - Branding limitations in chat interfaces are noted as possibly inherent, with uncertainty about "what we can do for branding or how we can control things." # Speaker Attribution & Provenance Record ## Video Identification - **Title:** MCP Apps: Give the Model Data, Give the User a UI — Dustin Mihalik, Indeed - **Video ID:** `01a15ca7-8db5-7907-8698-af9f9b45d717` ## Speakers | Speaker | Role | Evidence | |---|---|---| | Dustin Mihalik (transcribed as "Dustin Macholic") | **Sole presenter / speaker** | Introduces himself at start; works at Indeed on AI platform, guardrails, gateways, and compliance | No other speakers appear in the transcript; audience reactions are non-verbal only. ## Speaker Self-Description & Affiliation - Employed at **Indeed**, self-described as "the number one job site in the world" - Works on the **AI platform team**: AI guardrails, gateways, and compliance - Notes his team received MCP Apps / MCP connectors projects via vendor relationships ## Referenced Sources & Third-Party Claims - **OpenAI Apps SDK documentation** — the speaker explicitly states he "stole" the phrasing "separate your data processing from your UI rendering" from this documentation - **MCP spec and MCP Apps spec** — cited for structured content, resource URIs, and the `update model context` method - **MCP Apps documentation** — cited for a shopping cart example showing model-context updates - **Named products/platforms:** Claude, ChatGPT, Indeed's internal "Career Scout" agent for job seekers - **Claims of third-party experience:** speaker characterizes Claude/ChatGPT behavior (e.g., reluctance to include outbound links, tool-calling patterns) based on his team's own testing and evals — these are the speaker's claims, not independently verified ## Promotional Segments - **Indeed self-identification:** "we're the number one job site in the world" — a promotional claim made by the speaker about his employer - **No other promotional segments, sponsor mentions, or product pitches identified** ## Availability & Limitations - **Comment availability:** not indicated in the source material - **Curated metadata:** not present beyond title - **Transcript quality caveats:** transcript contains phonetic name rendering ("Macholic" vs. title's "Mihalik"), occasional transcription errors, and non-verbal markers ([snorts], [clears throat], [music]) - Speaker notes a screenshot is "out of date" (taken 2 days prior) — an explicit self-flagged staleness limitation ## Quotation Provenance Example > "Separate your data processing from your UI rendering" — attributed by the speaker to **OpenAI Apps SDK documentation** \>\> Uh hey everyone, I'm Dustin Macholic. Uh I work at Indeed. Uh we're the number one job site in the world. And I have to apologize for my voice. I'm recovering from a cold that I had last week. Um Yeah, so at Indeed, we build uh job search. And uh I also work on a team that does AI platform. And I do like AI guardrails and and gateways and compliance stuff. Uh occasionally uh my team gets cool projects to work on because we have relationships with the vendors. Uh MCP apps is one of those. And um MCP connectors. So, this is a little bit of like practical MCP apps. They gave a great introduction uh to MCP apps. This is a little bit of a lessons from the trenches, uh which is a little bit of like what did we learn in building MCP and MCP apps for Claude chat chat GPT and our own internal uh uh career scout, which is our uh agent that we have for job seekers. So, this is the this is the chat-based interface. So, a lot of my examples are going to be job search. This will I have a lot of screenshots of job searches. Um So, this is this is a job search, which is basically uh you know, I'm looking for barista in Austin. And this is a text-based response. And this works pretty well. Uh as we kind of discussed, like there's no branding here. There's no Indeed branding. Uh you know, Claude decided to say these are some jobs in Austin. These are some jobs in some suburbs of Austin. That's cool. That's probably good for the user. There may be some limitations uh of like what we can do for branding or how we can uh you know, how we can control things. And you'd be actually be surprised uh unless you've tried to do this yourself that um it's really hard to get Claude or ChatGPT to link to things cuz they don't want you to leave their environment. It makes complete sense, but uh if you get back, here's five jobs that are somewhere on the internet uh without any links, that's a terrible user experience. Uh so it's it took us a ridiculous number of hours and evals to make sure that like Claude would consistently link to things. So with MCP apps and with uh apps SDK, uh we could kind of control that. Uh we can decide uh you know, that we've got an apply button. We can decide what stuff is important that we want to highlight at the top. We can provide a link to view details um so that when you click it, you get uh a a pop-up, a a modal that has all the job details so you don't have to leave the environment. So it's it's a win-win uh for for both for both uh for both companies. So uh MCP apps is really good, but if you're thinking about hey, I want to build an MCP app or I want to take my website, I want to put it in ChatGPT or Claude, uh it's not quite just as easy as like dragging and dropping into a chat interface. Uh you really want to think about how you are representing the data, how you're making it available to the user. So if you do a very naive thing, uh which is you still call your existing APIs uh for loading data, um then it basically becomes a black box to the model, right? So you say, "Hey, I want to do something." The model says, "Cool, I'll call a tool." The tool says, "Okay, I'm going to show some stuff, but the model has no idea what what you're displaying." So, there's all these like follow-up questions, like tell me about the first result, or please rank this list of companies. The model has no idea what data is being displayed. So, the very first rule uh for me uh building MCP apps, anything that you show to the user also needs to be provided as data to the model. I think this makes sense, but uh I've definitely seen some MCP apps where they just, you know, use it to inject some HTML on the page and then call some APIs, uh and that's that just makes a big black box for the model. So, this is really easy to do uh using MCP spec and the MCP app spec. Uh this structured content, this is what you would already be returning if you were doing just text-based MCP. Um and then this resource URI, that's points to where the HTML is. You need to return both of these, and you need to keep them in sync, right? If you add something new to the API, you make sure you add something add that same data uh back. So, kind of the next step um that uh that once you do that, uh you'll find is that now you've provided data to the model, and you provided this black box that it has no idea about, it's still going to try and describe the it's still going to try and take the output and describe it as it normally would. So, you end up with like, "Here's your display." and then here's the model doing basically the same thing that it would normally do. Um so, what you need to do is you need to update your description in order to tell it that you're going to be displaying stuff in your MCP app. Uh that way you get this like nice, you know, here's a list of you know, here's a little summary of things, and you know, the results are are are showed above the links, rather than it trying to like do a whole text-based display. Um you'll end up with this a little bit of a battle between like what gets displayed in UI and what gets displayed by the model. You can try and steer that with descriptions. So, even something as simple as results were automatically displayed to the user as UI components at the top of your description, your tool description, uh that covers that covers quite a bit of the cases. Um So, that's one of the next things that you're going to want to do uh once you're providing both data and API access. Uh the next thing is there's these interactable pieces, right? There's the apply button, there's a view details button, which pops up a big job description. Um this is the same case where, you know, as you interact with those, the model's not going to know necessarily what you're looking at. So, you click view details, you get a big modal that's here's everything about the job. There's once again a whole bunch of questions that the user could ask. Uh write a cover letter for this job, summarize this job description. It has no idea because you've loaded that data in either in via API or you loaded it in dynamically, uh you know, hit you return 10 jobs and user clicks on one, the model has no idea which one you clicked on. Uh so, any information about user interactions, you also need to provide to the model. And uh once again, MCP abstract has a pretty easy way to handle it. There's this update model context um method, which lets you pass in a string uh that is So, for MCP apps, there's a single string. Uh so, if you like want to track multiple events over time, you kind of have to append uh multiple things to the string, but this is this is this is an example from the MCP apps uh documentation where basically, you know, this is a shopping cart application and they add the total cost and all the items that are on the shopping cart so the user can ask for uh you know, "Tell me information about the items that are in my shopping cart." \>\> \[snorts\] \>\> So, these two things give you an app that like the model could kind of see what's going on. Um but it doesn't necessarily make a really good MCP app yet uh because it gives you it gives you some UI that looks like what you want, but the thing that I usually do, I don't give I don't give the I don't I don't give Claude uh my easy problems to solve. I give Claude my really hard problems to solve, right? Like if I just wanted to do one search, I would go to the web and do one search. I want to do a whole bunch of searches. Uh this is this is out of date cuz there's no Sonic 5 here yet, but uh this is screenshot from 2 days ago. Uh but yeah, so that So, like this job search is "Hey, I'm looking for this I'm looking for this title. I'm willing to relocate, so I want to search across a whole bunch of different cities. Um you know, I'm looking for the highest paying option, so I want you to just cherry-pick a few out of there. There's some industries that I absolutely don't want to work in." Text-based MCP does really well. Like we all see this, right? Claude will do 10 different searches, 15 different searches. It'll filter, it'll pull out all the individual pieces, uh and then it gives you a nice table at the bottom, uh which is which is super nice. \>\> \[snorts\] \>\> But with the MCP app that we were just discussing, you know, we we said, "Hey, uh you know, my results are going to be displayed in this UI. Uh We know Claude Claude will call it once and then it'll be like, "Oh, I guess the results are already displayed. I'm not going to like do a deep dive, right?" Like it doesn't It's you as a user are not going to want 10 different carousels and Claude will also notice that like it's already been displaying some stuff and it won't call to show 10 different carousels. Um and so what you really want to do, and this is rule three, this like supersedes all the other rules, uh which is basically you want to separate your data processing from your UI rendering. And this particular wording I stole uh from OpenAI uh \>\> \[snorts\] \>\> OpenAI uh Apps SDK documentation. There's a couple places where they say this. Um but basically they want to You want to separate your data processing from your UI rendering. So the job search that we had we're just going to have that be a standard text-based MCP application. Claude can call that as many times as it wants. And then we have a render tool that either you can pass you can have the model basically pass all the data that it wants to render in or you can do a reference uh to it. So in our particular case uh you know, we had search jobs. Now we have a search jobs that doesn't return any UI and we have a render jobs widget that takes a list of IDs. Um and so that list of IDs uh can be, you know, Claude can do a search. It can get a hundred different jobs that it cares about. It can filter those. It can find five that it cares about and it can show those five to the user. Um now as you make these like render uh as you make these render calls, you need to update the descriptions to say like where did they get the data, what format the data should be. But it's a fairly easy fairly easy mechanism to update your tool description to say you need to always call one of these three tools first in order to get the data that you're going to be using for rendering. So, search jobs, this is a pretty good um It's a pretty good example of of how we where we want to split data from rendering. I think there's a ton of other like in most industries, you can kind of come up with like, "Hey, where do I want to you know, where do I want to split?" Like I want to be I want the model to be able to explore this data and then I want it to turn around and choose to be able to render it. Right? Like there's there's examples of you know e-commerce, right? Like a bunch of e-commerce options. If you've got a map, you know, maybe you want to come up with like five different addresses and then you pass in addresses. The other thing that you can do is you can let the model be a lot more creative. Like one of the things that we've seen in some of this text-based stuff is that you know, the model will say like, "This is a \>\> \[clears throat\] \>\> This is a reason why I picked this one." Or "This is a reason why this is really good." And so, you know, potentially we can add something to the render jobs widget where you say give us an ID and a reason why you think that this is a good fit. Or give us an ID and highlight a section of the job description that is really good. Um, so you can get really creative with your render tools to be able to have to be able to give some extra character that the model can inject into those so that so that you've got a much better experience for the user. So \[snorts\] the key takeaways right when building MCP apps, you want to focus on the data before you focus on the UI which sounds sounds opposite of you know how we were thinking about it of like hey there's all these there's these MCP apps like it's how I put UI into chat GPT. I think if you want to really have a good MCP apps experience, you need to you need to look at and see what data do I want to what data do I want to give to the model, what data do I want it to be able to do and then rendering is a side effect of of that or it's a result of the the model exploring the data. And then I think small composable tools, right? So uh basically, you know maybe there's like two or three different ways you can search for jobs. We could build two or three different search tools and then there's one render tool or maybe there's like maybe there's two render tools there's one that's render a list of jobs, one that's, you know, highlight one particular job. So you could build a bunch of much smaller tools. The descriptions can be fairly simple so you don't overload the model, but it gives the model flexibility about how it wants to explore the data and how it wants to render the tools. So that's basically basically my talk. I'm a few minutes few minutes fast. But I don't have a booth that I'm going to hang out in, but I'll I'll hang out in the hall if anyone has any questions. And I am either my last name or my first initial last name on most social media platforms. Thank you. \>\> \[music\] \>\> Mhm.