Talk by Jeremiah Lowin (founder and CEO of Prefect, author of FastMCP) on MCP apps, a protocol extension that lets tool results skip the agent and reach the user directly as HTML, CSS, and JavaScript. Motivated by the "world's most expensive copy paste" problem, where a naive file upload tool forces the agent to retype data into the server. Since FastMCP's users are mostly Python engineers who need tables, forms, and charts rather than consumer-facing products, Lowin constrained the problem: Prefab is a Python DSL where nesting context managers builds the UI, components are classes, and reactive variables provide client-side interactivity without JavaScript. The pipeline runs Python to a declarative representation to a JSON protocol to a React app; Lowin argues the serializable JSON is the actual point, since it is a UI an agent can generate, receive, or edit. He notes the Python DSL itself was an afterthought, Prefab's documentation is rendered entirely in Prefab and editable in place, and streaming Python over the wire proved roughly seventy percent smaller than JSON, so they convert it in a sandbox. # Channel Identity Observations: Jeremiah Lowin / Prefect ## Explicit Self-Description Evidence ### Speaker & Company Affiliation - The speaker identifies himself as author and maintainer of **FastMCP**: *"a framework that that I'm the author of and my company maintains called FastMPP"* — and notes it is *"one of the most popular ways of building MCP servers."* - He references company-level engineering principles: *"a principle that we really try to hold in a lot of our software at Prefect."* - He introduces **Prefab**, *"a piece of software that we open sourced a few months ago and has been surprisingly popular among this crowd"* — described as *"a scoped UI building framework for the purpose of delivering UIs through an agent."* ### Claimed Scope of Content - The talk's stated framing: *"one of the weirdest pieces of software I've ever written"* — positioned as *"the most reasoned approach to to a very strange thing that agents and MCP and other things have enabled."* - Claimed ecosystem reach: *"I think there's 130 or 140 components that we ship"*; docs *"are 100% rendered in prefab"*; *"this is already fully baked into FastMCP."* ## Intended Audience (Creator-Stated) - **Python engineers, largely in enterprises**: *"one of the most important things I have to share with you about our user base is that they're mostly Python engineers."* - *"Who are these Python developers who tend to be in enterprises? What are they doing and what do they need these UIs for?"* - Audience characterized as information-sharers within organizations: *"they are primarily charged with sharing information throughout their organization... for collecting information throughout their organization."* Explicitly **not** consumer-grade UI builders: *"what they don't need is consumer-grade custom UIs that are fully branded."* - A conference audience with MCP familiarity is assumed: *"MCP apps familiarity... this is probably the best crowd I've ever given this talk to."* ## Observable Presentation Patterns (Demonstrated, Not Claimed) - **Technical conference talk format** with live demos, slides, and code walkthroughs (e.g., hello-world card, data table + pie chart composition, file upload demo, generative UI streaming demo). - **Developer-focused pedagogy**: incremental code examples progressing from interactive tool → FastMCP app → fully generative UI; emphasis on ergonomic principles like *"one line of code, one big noticeable change."* - **Candid, exploratory tone**: acknowledges uncertainty mid-talk (*"this is the point in the talk where I reveal that I don't remember what the next slide exactly is"*, *"know your own slides is a good lesson"*), and frames the technology ambivalently: *"a really weird combination of like, yes, that's cool, and this really freaks me out."* - **Transparent engineering evolution**: shares lessons learned post-release, e.g., the discovery that *"the Python representation of a UI is about 70% smaller than the JSON representation,"* changing the streaming architecture. - **Calls to action oriented to practitioners**: *"you could try it in your servers this afternoon"*; docs at prefab.pref.io and on GitHub; *"I'll make these slides available later."* ## Distinguishing Claims from Demonstration - **Claim**: FastMCP's popularity and Prefab's reception (*"surprisingly popular"*) — creator assertion, no external verification in the material. - **Demonstrated**: working code patterns, a JSON/React rendering pipeline, reactive variable system (`RX`), upload component, and live docs — all shown via code and demos within the talk itself. - **Not inferable**: broader channel content strategy, private motivations, or audience size — only this single talk's evidence is available. # Delivery Observations: Jeremiah Lowin — "Generative UI... in Python?" ## Overall Tone - Conversational, self-deprecating, and openly puzzled by his own creation. He frames the talk around strangeness from the opening: **"one of the weirdest pieces of software I've ever written"** and closes the loop near the end: **"if you want to see the weirdest thing I've ever built."** - Repeatedly acknowledges the audience's likely discomfort and legitimizes it: **"If you're feeling a little uncomfortable about this, that is that is okay. It makes a lot more sense when we constrain the problem."** ## Verbal Habits - **Frequent filler and stutters**: "Um," repeated words ("for for coming," "putting putting forward," "how are we going to have have Python engineers"). This is consistent throughout — appears in nearly every paragraph. - **"So" as a pivot word**: used constantly to transition ("So this follows a principle...", "So uh we have these docs...", "So, it just went."). - **"And so" as a connective chain**: e.g., "And so fundamentally MCP servers are these fantastic ways...", "And so this is a little bit of a problem..." ## Recurring Vocabulary & Framing Devices - **"Weird"** as a recurring descriptor: "weirdest pieces of software," "a really weird combination," "this is super weird." - **"Fundamentally"** as an emphasis marker: "fundamentally MCP servers are...", "so fundamentally we expect that they're going to build tables." - **"Constraint" framing**: he repeatedly credits constraints as productive — "that constraint became really useful," "It makes a lot more sense when we constrain the problem," "this was another constraint we took on." ## Teaching Habits - **Audience calibration via show of hands**: "Just a show of hands. MCP apps familiarity." — then adapts: "this is probably the best crowd I've ever given this talk to." - **Concession + reframe pattern**: acknowledges limitations, then reframes — "You are welcome to use prefab for any kind of front-end problem you have... But the reason we built it... is for MCP servers." - **Live demo narration with fallbacks**: repeatedly hedges on media playback — "this would be better as a GIF. I apologize," "is this a gift? this is not a GIF or if it is it's not rendering," and jokes, **"know your own slides is a good lesson from this talk."** - **Progressive structure**: explicitly signals escalation — "three increasingly sophisticated ways that you can use it." - **Design principles stated memorably**: **"one line of code, one big noticeable change"** — one of the few fully polished aphorisms in the talk. ## Humor & Self-Correction - Self-deprecating asides about presentation mishaps: **"this is the point in the talk where I reveal that I don't remember what the next slide exactly is. So we're going to take a peek at it. Nope, we're going to come back."** - Memorable hyperbole for a technical critique: **"the world's most expensive copy paste operation. You give the agent a megabyte of text. the agent retypes it character by character." ## Honesty About Revision - Transparently notes when the demo no longer reflects current behavior: "When I recorded this demo was streaming JSON. What we now do is we actually stream the Python over the wire... this is just one of those things that we've learned on the fly." ## Uncertainty Notes - The transcript contains apparent ASR errors ("FastMPP," "shaden component," "pagionation," "a gift" for "a GIF"); quoted examples above reflect the transcript as supplied. - Tone and filler patterns are strongly evidenced; claims about audience reaction (other than the show of hands and closing applause) cannot be observed from the transcript. # Observation Record: "Generative UI... in Python?" — Jeremiah Lowin, Prefect ## Speaker - **Jeremiah Lowin**, author of FastMCP and founder/leader at Prefect (identified via curated metadata: title lists him and Prefect). --- ## 1. MCP Apps — Background Claims - **Claim:** MCP apps are an extension of the MCP protocol introduced around January of the same year (speaker hedged: "I think"). - **Standard MCP flow:** User → agent → MCP tool on an MCP server → tool result returns into the agent's **context window** → agent responds to user. - **Claim:** MCP servers add functions/business logic to agents, but there is "never a direct connection between a user and the MCP server" — it always goes through the agent's brain/context. - **MCP apps change:** The tool result is sent directly to the user as **HTML, CSS, JavaScript** — a full UI bypassing the agent. - **Use cases cited:** booking a restaurant table, changing a plane seat, interacting with a schedule — "the agent facilitated it, but you are going to interact as a human." - **Coming extension (July MCP release):** the agent can also interact with the app, enabling e.g. visual chess against the agent. Speaker flags this "will open up a whole new world of possibilities" but explicitly defers it. ## 2. Motivation and Constraints - **User base:** FastMCP users are "mostly Python engineers," often in **enterprises**. - **Rejected approach:** Speaker states he "can't pretend we're going to ship React and Python" — refuses a "Frankenstein" system that jams the frontend ecosystem into Python. - **Reframing the need:** Enterprise users don't need consumer-grade branded UIs; they need to **share and collect information** within their organizations — tables, forms, charts. - **Design principle:** "We are not trying to build a front end from scratch. We are trying to **compose** a front end from a bunch of world-class well-designed components." ## 3. Prefab — The Product - **Description:** An open-sourced (a few months prior) "scoped UI building framework" for delivering UIs through agents; "surprisingly popular." - **Hello-world demo:** A live-updating card whose generating code is entirely Python. Speaker's stated reaction: a mix of "yes, that's cool" and "this really freaks me out" — he invites the audience to feel the same discomfort. - **DSL mechanics:** - Built on Python **context managers**; nesting mirrors UI structure. - Analogy offered: FastMCP reduced to a decorator; prefab reduced to a context manager. - Components are instantiated, parameterized classes (rendered as **shadcn components**, per transcript "shaden"). - **Reactive variables** (`rx`) enable client-side interactivity with automatic compilation to JavaScript. - **Pipeline:** Python DSL → declarative representation → **JSON protocol** → rendered by a React app hosted as the MCP app. - **Key insight (speaker's stated priority):** "The Python is actually an accident that I discovered after the fact." The point was the **serializable JSON intermediate representation** — which agents can generate, send, or modify. - **Component count:** ~130–140 shipped components (speaker uncertain: "I think"). - **Docs claim:** Prefab docs are 100% rendered in prefab, with live-editable Python examples in a playground. ## 4. Three Usage Patterns ### a) Interactive tool - Change a FastMCP tool's return from a dict to a prefab component (e.g., data table); FastMCP auto-detects and spins up the MCP app machinery. - Demo (goose client): "show me the team directory" → interactive table with search, filtering, sorting, pagination. - Extending with a grid + pie chart follows the Prefect principle: **"one line of code, one big noticeable change."** - Fully client-side linked-controls demo with no JavaScript written. ### b) FastMCP app (full application) - A class with `app.ui` entry point returning prefab components plus zero-or-more `app.tools` backend methods; the MCP server acts as the backend. - **File-upload argument:** An MCP upload tool requires the agent to call it, producing "the world's most expensive copy paste operation" — the agent retypes text character-by-character into the server. An MCP app upload component lets the file **bypass the agent** — "safely and most importantly cheaply" — as a one-liner. ### c) Fully generative UI - Demo: Claude asked to "start streaming the most interesting UI you can come up with"; agent streams JSON protocol which is rendered in real time with JSON "healing." - **Discovered trade-off (post-demo change):** The Python representation is ~70% smaller than the JSON representation, so Prefab now **streams Python** (executed in a sandbox, converted to JSON server-side), giving "dramatic" token, cost, and latency benefits. Speaker notes the recorded demo used JSON streaming, so it differs from current behavior. - **Qualification:** Some clients have built-in generative-UI versions; users "may prefer to use it by all means." ## 5. Availability - Docs at prefab.pref.io; library on GitHub; fully baked into recent FastMCP versions as an optional install. --- ## Preserved Tensions and Qualifications - Speaker's own ambivalence: prefab is "the weirdest piece of software I've ever written" and simultaneously "weird" and "cool"; he repeatedly acknowledges audience discomfort as legitimate ("If you're feeling a little uncomfortable about this, that is okay"). - The JSON protocol is the stated core; the Python DSL is explicitly downgraded to a serendipitous "accident." - The streamed-representation change (JSON → Python) occurred *after* the demo was recorded — the demo does not reflect current behavior. - Dates and counts hedged in the transcript ("I think in January," "I think there's 130 or 140 components"). # Speaker Attribution Record ## Video **Title:** Generative UI... in Python? — Jeremiah Lowin, Prefect **Video ID:** `01a15ca7-69b1-79f4-b872-a9bbd7db8ac3` ## Speakers | Speaker | Role | Evidence | |---|---|---| | Jeremiah Lowin | **Creator / Presenter (sole speaker)** | Self-introduces as talk giver; identifies himself as author of FastMCP, maintained by his company (Prefect, per title) | - **No guests, narrators, or other identified speakers** appear in the transcript. - Audience presence is implied (show of hands, applause at close), but audience members are not identified speakers. ## Referenced Sources & Third-Party Claims - **MCP protocol / MCP apps** — described as an extension of the MCP protocol introduced "January of this year"; a further extension "coming out in the July MCP release" (speaker's claim, unverified). - **FastMCP** — framework the speaker states he authored and his company maintains; "one of the most popular ways of building MCP servers" (speaker's claim). - **Prefab** — open-sourced software described as "surprisingly popular"; scoped UI-building framework. - **Prefect** — speaker's company (per title); stated design principle "one line of code, one big noticeable change." - **shadcn components** — referenced as the rendered component basis ("a beautiful shaden component"). - **Goose client** — MCP client used in demo; speaker calls it "an excellent one." - **Claude (Anthropic)** — used in a generative UI demo; no claims attributed to Anthropic as an organization. - **Prior talk by "Edo and Lead"** — referenced as given "maybe an hour ago"; content not described. - **Technical claim (speaker-reported):** Python representation of a UI is "about 70% smaller" than the JSON representation — unverified speaker figure. ## Promotional Segments - **FastMCP** promotion: framed as one of the most popular MCP server frameworks; features highlighted throughout. - **Prefab** promotion: extensive demonstration, described as open-sourced, with a principle of "one line of code, one big noticeable change." - **Closing call-to-action (explicit promotion):** docs at `prefab.pref.io` (as spoken), full library on GitHub, described as "fully baked into FastMCP" — speaker invites audience to try it. ## Availability & Provenance Limits - **Slides:** Speaker states slides will be "made available later" — not yet available at time of talk. - **Demos:** GIFs/video demos referenced but one "is not rendering" during the talk; demo recorded previously. - **Comments:** No comment availability information present in source material. - **Curated metadata:** None supplied beyond title; no external verification of speaker claims possible from this source. Good. Um, thank you all for for coming out. Um, I'm going to talk today about one of the weirdest pieces of software I've ever written. It's sort of on the edge of a whole lot of stuff I've been putting putting forward into the world. Um, so join me if you will. We're going to try and have the most reasoned approach to to a very strange thing that agents and MCP and other things have enabled. And so to begin, I want to talk about MCP apps. I don't know if any of you were able to join any of the other talks earlier today. Maybe the one that um Edo and Lead just gave maybe an hour ago. Just a show of hands. MCP apps familiarity. Okay, this is probably the best crowd I've ever given this talk to actually. So that's that's fantastic. Um, for those that didn't put their hands up, MCP apps is an extension of the MCP protocol that was introduced I think in January of this year. And the idea is this is a typical request response cycle for an MCP um tool. The user makes a request to the agent. The agent in turn decides to use an MCP tool that's hosted on an MCP server. A tool result comes back into the agent's context and the agent chooses to form some response and send it out to the user. And so fundamentally MCP servers are these fantastic ways of adding uh functions and business logic to your agents but never a direct connection between a user and the MCP server. It always goes through the brain of the agent and more importantly through the context window of the agent. So MCP apps are an extension of this which allow us actually to bypass the agent and instead what happens is the following. The user requests something from the agent. The agent uses a tool, but instead of that tool request going back to the agent, it is sent out to the user and it's sent out as HTML, CSS, JavaScript. It's a full UI and it can be whatever you want it to be. And so the idea is you have this way to make to basically put the internet into your agent, so to speak. You can ship any custom branded useful UI that you want. You can let the user have any interactive experience that they want. And then the user, as you can see in the diagram, the user now can interact with the application. they can use the tools, they can send information back into a backend host on that app and really get a full experience. You can imagine booking a table at a restaurant or um changing your seat on a plane or interacting with a schedule for AI engineer. There's a lot of things that you can do as a user now where the agent facilitated it, but you are going to interact as a human. And there's an extension coming now. This is going to come out in um in the July MCP release where the agent can actually interact with the app as well. And this will tee up some really interesting use cases we're not going to talk about today, but you could hypothetically play a game of chess against the agent now in a visual app where you make a move and then the agent interacts with the app as well. And so I think that's going to open up a whole new world of possibilities. Now um some of you may know a framework that that I'm the author of and my company maintains called FastMPP. Um fast MCP is one of the most popular ways of building MCP servers. And so whenever new cool things come to the world of MCP, the first thing I wonder is how can I deliver this to our users? And one of the most important things I have to share with you about our user base is that they're mostly Python engineers. And so and so this is a little bit of a problem when we want to deliver frontends and UIs because how are we actually going to do that? And this is the point in the talk where I reveal that I don't remember what the next slide exactly is. So we're going to take a peek at it. Nope, we're going to come back. Um, we we have we have a challenge now. Uh, how are we going to have have Python engineers build UIs that are best practice, that are interactive, that are beautiful, that are useful without pretending that we're going to do something silly, something that's been tried, and jam all of the front end, all of the ecosystem, everything into Python in some sort of like weird compromised haphazard Frankenstein of a system. And so I really struggled with this. I need I really need I feel an obligation to find a way to deliver this, but I I can't I can't pretend we're going to ship React and Python. It's not going to work. And so we thought pretty hard about who are our users in the fastmcp ecosystem. Who are these Python developers who tend to be in enterprises? What are they doing and what do they need these UIs for? What do they need these MCP apps for? Um what they don't need is consumer-grade custom UIs that are fully branded. That that's not what these folks are doing. what they are uh primarily charged with is sharing information throughout their throughout their organization for collecting information throughout their organization and so it changed the nature of what we expect them to do within MCP apps framework and that constraint became really useful so fundamentally we expect that they're going to do things like build tables they're going to collect information through forms and they're going to want to share charts and so fundamentally with this constraint we can introduce a piece of software that we open sourced a few months ago and has been surprisingly popular among this crowd called prefab and it's a scoped UI building framework for the purpose of delivering UIs through an agent for the set of purposes that I mentioned a moment ago. So this is a hello world card. You might see this in any front-end framework, literally anyone. It'll have something that looks like this and it's on their website and you you type your name in and it it updates live. But of course, the weird thing about this one is that the code that generated it is entirely written in Python. And so I hope that you're feeling what I feel when I look at this, which is a really weird combination of like, yes, that's cool, and this really freaks me out. The yes, that's cool, comes from the fact that I think there's something about this code, even if you can't see it up close, I can make it a little bigger. There's something about this that like kind of makes sense. You can see the structure of the of the of the UI in the code, but there's also something about it that's obviously alien and a little bit a little bit odd. And we come to this conclusion when you when you feel that when you look at it, which is that when you compose a front end in Python, it's actually starts to feel good as long as we scope the challenge right. We are not trying to build a front end from scratch. We are trying to compose a front end from a bunch of worldclass well-designed components. And that's how we keep the guardrails and that's how we keep the user in mind. The user here is not trying to do something arbitrary. They're trying to take a well structured front end and put it in front of um whomever they're delivering it to. And so here's a little quick tour of that DSL. Um primarily we're using context managers. For those of you who do know fastmcp, you know that arguably you could reduce fastmc down and say the core innovation of fastmcp is that we used a python decorator to build an entire MCP server. So if you want to take the same reductive approach to prefab, you could say we use a context manager to build an entire UI. And by nesting components with as context managers as you see here, we are building up the exact same structure in the UI. It feels very natural when you read it. You can see how things are structured. Um each element of the UI, each component, which is a beautiful shaden component when it's rendered, as you can see here, is a class that you instantiate. You can parameterize it. you can pass it stuff like CSS classes and and make it look however you want. And then the last thing which we're not going to have enough time to really explore today is these reactive variables. Um I'll show you a demo of those in a moment, but essentially we have a full way to um create client side interactivity and bind data between components that allows you to build these really rich experiences again without having to go fully into the JavaScript world and leave an ecosystem that my user base at least is extremely comfortable with. Um, and this is the pipeline that prefab is essentially exposing. We use a Python DSL that I just shared with you. We use that to build a declarative representation of a UI that then gets serialized into a JSON protocol. And that JSON protocol is ultimately rendered by a React app which is hosted as the actual MCP app. And so this is going to open up a whole lot of possibilities for us that again I'm going to show you in just a second. But the key to this whole thing is the JSON in the middle. The Python is actually an accident that I discovered after the fact because it was a weird idiosyncratic thing that I wanted. The point of this was can we create a serializable representation of a UI and that's the JSON protocol again. And because it's serializable, I can generate it from an agent. I can send it to an agent. I can generate it as a human and ask an agent to modify. There's all this cool stuff that happens because of that intermediate representation in JSON. And then when the when the Python DSL just fell out of this and was really beautiful and easy to use, I kind of felt like we had something So uh we have these docs and sort of to prove the point this was another constraint we took on this is I don't even know what this is this is a doc these are the docs for the data table component in prefab I think there's 130 or 140 components that we ship that you can compose into an arbitrary form the docs for prefab are 100% rendered in prefab so the data table that's here in the basic usage it is live rendered in prefab the Python code you can see it sneaking in at the bottom of the screen that Python code is being rendered live by the renderer to generate that. If you want, you can take any example in the prefab docs, you can click a link, pop them into the playground, and you can edit the code live, the Python code live, and you will see the UI update. And again, this is super weird. If you're feeling a little uncomfortable about this, that is that is okay. It makes a lot more sense when we constrain the problem. And remember that we're composing a UI rather than building it. So, I want to bring this back to the thing I opened with now, which is MCP servers and more specifically MCP apps. You are welcome to use prefab for any kind of front-end problem you have. My team has started using it for small interactive data apps and things to explore. They've been building presentations with it. We ship a a dark mode theme that honestly looks kind of like the one I'm showing you right now to make slides and presentations. You can do a lot of stuff with it. But the reason we built it, the use case that it is satisfying is for MCP servers. And so um I want to give you a quick tour of three ways that you can use it, three increasingly sophisticated ways that you can use it in your MCP server. The first is to build an interactive tool. As I showed you at the beginning of the talk, typically an MCP tool is something your agent calls and the agent gets the result and you don't get to interact with it at all. So what's the easiest way that we can advance that that interactive functionality? I'm going to show you here. This is a fastm tool. It's been decorated with a tool decorator as you can see and it's just a Python function that returns some information. Bearing in mind this information will go to the agent, not the user. If we want to turn this into a fully interactive tool with prefab, we're going to make one change. Instead of returning a Python dictionary at the end, which will go to the agent, we're going to return a prefab component. In this case, it's the data table. These are the this is what I just showed you the docs for a moment ago. And when we return this prefab component, FastMPP will automatically detect that. It will automatically infer that you in fact want to return an MCP app. and it will spin up all the machinery to get the HTML, the JavaScript, the CSS, the render, everything in place so that your user will see a data table. Here's what this looks like in practice. This is using the goose client, which is an excellent one. Um, I asked a server that had the function I just uh showed you, show me the team directory. And what pops up uh this would be better as a GIF. I apologize, but what pops up is a fully interactive data table component. It supports um searching and filtering and sorting and pagionation and all this stuff. And all it is is what I showed you a moment ago. Just return the data table class and all this will be taken care of. We can go a step further. What if in addition to the data table, we want to show a pie chart right next to the data table that breaks down this team directory. As you might imagine, very, very, very similar code. Instead of the data table alone, we're now going to import a grid and a pie chart. And if you look at the bottom, you'll see that we compose both the pie chart and the data table into a grid very naturally with a context manager. And this is the result. we now get a pie chart next to our data table. So this follows a principle that we really try to hold in a lot of our software at Prefect, which is one line of code, one big noticeable change. We try to keep that complexity incremental. And so this satisfies a lot of things that I think are really important about frameworks and DSLs. Um, this is very quickly because we won't have time to go into it. This is just an example I threw together and recorded of fully client side interactivity where all of these controls are linked. Uh, stuff's updating, text is updating, values are updating. No JavaScript was written. This is just a couple of classes composed that all have the same attribute assigned. So they all work together automatically. Um, oh, and I did throw in a quick code example of what that looks like. We have a class called RX, which as you may guess stands for reactive. If you use these reactive variables, you can just reference them anywhere in your code. You can format them. You can you can make them the name of something and it will automatically compile into the correct uh JavaScript implementation. The second thing that we can do is a fastmcp app. So if an interactive tool is sort of a oneshot here's a user interface and you can interact with it in the client a fastmcp app is a full application with a backend and in this case the MCP server is going to be the back end. We don't have time to go through a full worked example in this session but here's what the code looks like just to give you a sense of the ergonomics. We're going to write a class which is our fastmcp app and then we're going to decorate at least two uh functions with app.ui UI. That's the entry point that's going to return the prefab components that form the base UI of that application. And then at least one, I guess this is optional, so zero or more um app.tools. And these are essentially backend methods that you can now reference in the UI. So you could have a button that takes data that the user has entered into a form and sends it to a database using a decorated tool like this. One thing that we use and we ship as a built-in component now in fastmcp is an upload component. So as you can see because only the agent has access to an MCP server you can't simply upload a file to an MCP server. It has to go through the brain of the agent. And so what ends up happening is a lot of people create basically an upload tool on their MCP server forget that the agent has to actually call it. And what you end up doing is the world's most expensive copy paste operation. You give the agent a megabyte of text. the agent retypes it character by character into the MCP and now yes in fact you have uploaded it but it's extremely extremely inefficient. So this is a really good use case for an MCP app where you ask the agent to bring up the app interface you drag a file into it and now the file bypasses the agent and goes right into the server. And we've made that a oneliner like this along with a handful of other um useful tools. And is this a gift? this is not a GIF or if it is it's not rendering but it would look like this in your client in any client that supports MCP apps if you ask the agent I need to upload something it can now show you this and you can upload safely and most importantly cheaply um oh I do have a gift mind know your own slides is a good lesson from this talk so here's the agent is now interacting with a file that I just uploaded that I dragged and dropped um I'll make these slides available later if you'd like to see this or of course it's a oneliner you could try it in your servers uh this afternoon. The last thing that I want to talk about which is sort of enabled by this architecture is a fully generative UI. Um, we're just going to skip and let this play while I talk. So, this is a very simple demo where I asked Claude, "Hey, just I'm giving a talk on this. Just start streaming the most interesting UI you can come up with." And so, it just went. And what it's doing here is we exposed a tool that accepts the JSON uh the protocol serialization of a UI that prefab is based on. And so now as the agent is streaming that information over the wire, we are in real time rendering whatever we've got, healing that JSON and rendering it. And so this was a really cool demo and it was really effective and people like this because now you don't even have to define the UI yourself. All you have to do is use the skill we already ship, share it with your agent so it knows how to write a UI and off it goes. It can make you whatever you want. There are some clients that have built-in versions of this. if they have a built-in version, you may prefer to use it by all means, but this may be a way for you to build your own custom uh approach or limited set of components that are useful to you. Now, a really interesting thing happened when we spun this up. So, as I mentioned, originally the plan was for the agent to send JSON over the wire and have it be rendered into this full React application. What we ended up discovering is that the Python representation of a UI is about 70% smaller than the JSON representation. So we don't do this anymore. When I recorded this demo was streaming JSON. What we now do is we actually stream the Python over the wire. It's executed in a sandbox. It's turned into JSON on the server and then that's rendered. And so this has a dramatic dramatic token efficiency, cost, and latency uh benefit. So it would work exactly the same as when I recorded this demo, but this is just one of those things that we've learned on the fly. And it's really fascinating that the Python representation is just that much more compact and ergonomic than the full um JSON one. So um that's prefab. If you'd like to check it out, if you're curious, if you want to see the weirdest thing I've ever built um along with however other many people, you can see the docs at prefab.pref.io. You can see the full library uh which is on our GitHub here. And this is already fully baked into FastmcP. So, if you're using a recent version of FastMPP, you should be able to install this optional addition, uh, import the components, return them, and start playing with these MCP apps. Thank you all for coming. \[applause\]