WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=Krzs8GeiWTc

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/Krzs8GeiWTc.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:12.639 --> 00:00:13.519
Good.

s2
00:00:13.519 --> 00:00:15.440
Um, thank you all for for coming out.

s3
00:00:15.440 --> 00:00:19.359
Um, I'm going to talk today about one of the weirdest pieces of software I've ever written.

s4
00:00:19.359 --> 00:00:23.680
It's sort of on the edge of a whole lot of stuff I've been putting putting forward into the world.

s5
00:00:23.680 --> 00:00:25.439
Um, so join me if you will.

s6
00:00:25.439 --> 00:00:32.480
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.

s7
00:00:32.480 --> 00:00:35.920
And so to begin, I want to talk about MCP apps.

s8
00:00:35.920 --> 00:00:39.840
I don't know if any of you were able to join any of the other talks earlier today.

s9
00:00:39.840 --> 00:00:44.079
Maybe the one that um Edo and Lead just gave maybe an hour ago.

s10
00:00:44.079 --> 00:00:45.760
Just a show of hands.

s11
00:00:45.760 --> 00:00:48.719
MCP apps familiarity.

s12
00:00:49.039 --> 00:00:52.559
Okay, this is probably the best crowd I've ever given this talk to actually.

s13
00:00:52.559 --> 00:00:54.160
So that's that's fantastic.

s14
00:00:54.160 --> 00:01:01.280
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.

s15
00:01:01.280 --> 00:01:07.920
And the idea is this is a typical request response cycle for an MCP um tool.

s16
00:01:07.920 --> 00:01:10.159
The user makes a request to the agent.

s17
00:01:10.159 --> 00:01:15.520
The agent in turn decides to use an MCP tool that's hosted on an MCP server.

s18
00:01:15.520 --> 00:01:23.040
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.

s19
00:01:23.040 --> 00:01:33.280
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.

s20
00:01:33.280 --> 00:01:37.759
It always goes through the brain of the agent and more importantly through the context window of the agent.

s21
00:01:37.759 --> 00:01:44.960
So MCP apps are an extension of this which allow us actually to bypass the agent and instead what happens is the following.

s22
00:01:44.960 --> 00:01:46.880
The user requests something from the agent.

s23
00:01:46.880 --> 00:01:54.720
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,

s24
00:01:54.720 --> 00:01:55.280
JavaScript.

s25
00:01:55.280 --> 00:01:58.479
It's a full UI and it can be whatever you want it to be.

s26
00:01:58.479 --> 00:02:03.840
And so the idea is you have this way to make to basically put the internet into your agent, so to speak.

s27
00:02:03.840 --> 00:02:07.920
You can ship any custom branded useful UI that you want.

s28
00:02:07.920 --> 00:02:11.520
You can let the user have any interactive experience that they want.

s29
00:02:11.520 --> 00:02:15.920
And then the user, as you can see in the diagram, the user now can interact with the application.

s30
00:02:15.920 --> 00:02:21.440
they can use the tools, they can send information back into a backend host on that app and really get a full experience.

s31
00:02:21.440 --> 00:02:29.520
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.

s32
00:02:29.520 --> 00:02:35.200
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.

s33
00:02:35.200 --> 00:02:36.800
And there's an extension coming now.

s34
00:02:36.800 --> 00:02:43.599
This is going to come out in um in the July MCP release where the agent can actually interact with the app as well.

s35
00:02:43.599 --> 00:02:54.319
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.

s36
00:02:54.319 --> 00:02:58.480
And so I think that's going to open up a whole new world of possibilities.

s37
00:02:59.200 --> 00:03:05.360
Now um some of you may know a framework that that I'm the author of and my company maintains called FastMPP.

s38
00:03:05.360 --> 00:03:08.720
Um fast MCP is one of the most popular ways of building MCP servers.

s39
00:03:08.720 --> 00:03:16.959
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?

s40
00:03:16.959 --> 00:03:23.280
And one of the most important things I have to share with you about our user base is that they're mostly Python engineers.

s41
00:03:23.280 --> 00:03:31.040
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?

s42
00:03:31.040 --> 00:03:34.400
And this is the point in the talk where I reveal that I don't remember what the next slide exactly is.

s43
00:03:34.400 --> 00:03:35.360
So we're going to take a peek at it.

s44
00:03:35.360 --> 00:03:36.480
Nope, we're going to come back.

s45
00:03:36.480 --> 00:03:40.159
Um, we we have we have a challenge now.

s46
00:03:40.159 --> 00:04:00.159
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

s47
00:04:00.159 --> 00:04:02.720
haphazard Frankenstein of a system.

s48
00:04:02.720 --> 00:04:04.159
And so I really struggled with this.

s49
00:04:04.159 --> 00:04:12.239
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.

s50
00:04:12.239 --> 00:04:13.200
It's not going to work.

s51
00:04:13.200 --> 00:04:17.440
And so we thought pretty hard about who are our users in the fastmcp ecosystem.

s52
00:04:17.440 --> 00:04:20.639
Who are these Python developers who tend to be in enterprises?

s53
00:04:20.639 --> 00:04:22.880
What are they doing and what do they need these UIs for?

s54
00:04:22.880 --> 00:04:24.960
What do they need these MCP apps for?

s55
00:04:24.960 --> 00:04:30.800
Um what they don't need is consumer-grade custom UIs that are fully branded.

s56
00:04:30.800 --> 00:04:32.880
That that's not what these folks are doing.

s57
00:04:32.880 --> 00:04:48.080
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

s58
00:04:48.080 --> 00:04:59.199
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

s59
00:04:59.199 --> 00:05:08.960
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

s60
00:05:08.960 --> 00:05:16.479
building framework for the purpose of delivering UIs through an agent for the set of purposes that I mentioned a moment ago.

s61
00:05:16.479 --> 00:05:18.639
So this is a hello world card.

s62
00:05:18.639 --> 00:05:22.000
You might see this in any front-end framework, literally anyone.

s63
00:05:22.000 --> 00:05:27.520
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.

s64
00:05:27.520 --> 00:05:33.360
But of course, the weird thing about this one is that the code that generated it is entirely written in Python.

s65
00:05:33.360 --> 00:05:43.280
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.

s66
00:05:43.280 --> 00:05:49.680
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.

s67
00:05:49.680 --> 00:05:52.000
There's something about this that like kind of makes sense.

s68
00:05:52.000 --> 00:06:00.639
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.

s69
00:06:00.639 --> 00:06:10.560
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.

s70
00:06:10.560 --> 00:06:13.039
We are not trying to build a front end from scratch.

s71
00:06:13.039 --> 00:06:18.960
We are trying to compose a front end from a bunch of worldclass well-designed components.

s72
00:06:18.960 --> 00:06:22.240
And that's how we keep the guardrails and that's how we keep the user in mind.

s73
00:06:22.240 --> 00:06:24.800
The user here is not trying to do something arbitrary.

s74
00:06:24.800 --> 00:06:29.919
They're trying to take a well structured front end and put it in front of um whomever they're delivering it to.

s75
00:06:29.919 --> 00:06:32.319
And so here's a little quick tour of that DSL.

s76
00:06:32.319 --> 00:06:34.400
Um primarily we're using context managers.

s77
00:06:34.400 --> 00:06:44.560
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.

s78
00:06:44.560 --> 00:06:49.840
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.

s79
00:06:49.840 --> 00:06:58.720
And by nesting components with as context managers as you see here, we are building up the exact same structure in the UI.

s80
00:06:58.720 --> 00:07:00.400
It feels very natural when you read it.

s81
00:07:00.400 --> 00:07:02.080
You can see how things are structured.

s82
00:07:02.080 --> 00:07:10.639
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.

s83
00:07:10.639 --> 00:07:11.599
You can parameterize it.

s84
00:07:11.599 --> 00:07:16.080
you can pass it stuff like CSS classes and and make it look however you want.

s85
00:07:16.080 --> 00:07:20.960
And then the last thing which we're not going to have enough time to really explore today is these reactive variables.

s86
00:07:20.960 --> 00:07:30.800
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

s87
00:07:30.800 --> 00:07:39.120
again without having to go fully into the JavaScript world and leave an ecosystem that my user base at least is extremely comfortable with.

s88
00:07:39.120 --> 00:07:42.160
Um, and this is the pipeline that prefab is essentially exposing.

s89
00:07:42.160 --> 00:07:44.720
We use a Python DSL that I just shared with you.

s90
00:07:44.720 --> 00:07:52.240
We use that to build a declarative representation of a UI that then gets serialized into a JSON protocol.

s91
00:07:52.240 --> 00:07:58.080
And that JSON protocol is ultimately rendered by a React app which is hosted as the actual MCP app.

s92
00:07:58.080 --> 00:08:02.319
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.

s93
00:08:02.319 --> 00:08:05.120
But the key to this whole thing is the JSON in the middle.

s94
00:08:05.120 --> 00:08:09.759
The Python is actually an accident that I discovered after the fact because it was a weird idiosyncratic thing that I wanted.

s95
00:08:09.759 --> 00:08:17.520
The point of this was can we create a serializable representation of a UI and that's the JSON protocol again.

s96
00:08:17.520 --> 00:08:20.479
And because it's serializable, I can generate it from an agent.

s97
00:08:20.479 --> 00:08:21.919
I can send it to an agent.

s98
00:08:21.919 --> 00:08:24.479
I can generate it as a human and ask an agent to modify.

s99
00:08:24.479 --> 00:08:28.400
There's all this cool stuff that happens because of that intermediate representation in JSON.

s100
00:08:28.400 --> 00:08:35.839
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

s101
00:08:35.839 --> 00:08:45.760
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

s102
00:08:45.760 --> 00:09:03.200
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

s103
00:09:03.200 --> 00:09:05.839
rendered live by the renderer to generate that.

s104
00:09:05.839 --> 00:09:15.519
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.

s105
00:09:15.519 --> 00:09:16.959
And again, this is super weird.

s106
00:09:16.959 --> 00:09:20.000
If you're feeling a little uncomfortable about this, that is that is okay.

s107
00:09:20.000 --> 00:09:22.080
It makes a lot more sense when we constrain the problem.

s108
00:09:22.080 --> 00:09:25.760
And remember that we're composing a UI rather than building it.

s109
00:09:25.760 --> 00:09:31.440
So, I want to bring this back to the thing I opened with now, which is MCP servers and more specifically MCP apps.

s110
00:09:31.440 --> 00:09:35.120
You are welcome to use prefab for any kind of front-end problem you have.

s111
00:09:35.120 --> 00:09:39.120
My team has started using it for small interactive data apps and things to explore.

s112
00:09:39.120 --> 00:09:40.800
They've been building presentations with it.

s113
00:09:40.800 --> 00:09:47.120
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.

s114
00:09:47.120 --> 00:09:48.320
You can do a lot of stuff with it.

s115
00:09:48.320 --> 00:09:52.800
But the reason we built it, the use case that it is satisfying is for MCP servers.

s116
00:09:52.800 --> 00:10:00.000
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.

s117
00:10:00.000 --> 00:10:02.880
The first is to build an interactive tool.

s118
00:10:02.880 --> 00:10:10.560
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.

s119
00:10:10.560 --> 00:10:15.920
So what's the easiest way that we can advance that that interactive functionality?

s120
00:10:15.920 --> 00:10:17.120
I'm going to show you here.

s121
00:10:17.120 --> 00:10:18.480
This is a fastm tool.

s122
00:10:18.480 --> 00:10:23.360
It's been decorated with a tool decorator as you can see and it's just a Python function that returns some information.

s123
00:10:23.360 --> 00:10:26.320
Bearing in mind this information will go to the agent, not the user.

s124
00:10:26.320 --> 00:10:32.720
If we want to turn this into a fully interactive tool with prefab, we're going to make one change.

s125
00:10:32.720 --> 00:10:38.000
Instead of returning a Python dictionary at the end, which will go to the agent, we're going to return a prefab component.

s126
00:10:38.000 --> 00:10:39.279
In this case, it's the data table.

s127
00:10:39.279 --> 00:10:42.160
These are the this is what I just showed you the docs for a moment ago.

s128
00:10:42.160 --> 00:10:47.279
And when we return this prefab component, FastMPP will automatically detect that.

s129
00:10:47.279 --> 00:10:50.560
It will automatically infer that you in fact want to return an MCP app.

s130
00:10:50.560 --> 00:10:58.160
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.

s131
00:10:58.160 --> 00:10:59.600
Here's what this looks like in practice.

s132
00:10:59.600 --> 00:11:02.000
This is using the goose client, which is an excellent one.

s133
00:11:02.000 --> 00:11:07.120
Um, I asked a server that had the function I just uh showed you, show me the team directory.

s134
00:11:07.120 --> 00:11:09.360
And what pops up uh this would be better as a GIF.

s135
00:11:09.360 --> 00:11:12.640
I apologize, but what pops up is a fully interactive data table component.

s136
00:11:12.640 --> 00:11:17.839
It supports um searching and filtering and sorting and pagionation and all this stuff.

s137
00:11:17.839 --> 00:11:20.160
And all it is is what I showed you a moment ago.

s138
00:11:20.160 --> 00:11:24.000
Just return the data table class and all this will be taken care of.

s139
00:11:24.000 --> 00:11:24.959
We can go a step further.

s140
00:11:24.959 --> 00:11:30.880
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.

s141
00:11:30.880 --> 00:11:33.680
As you might imagine, very, very, very similar code.

s142
00:11:33.680 --> 00:11:37.839
Instead of the data table alone, we're now going to import a grid and a pie chart.

s143
00:11:37.839 --> 00:11:45.200
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.

s144
00:11:45.200 --> 00:11:46.320
And this is the result.

s145
00:11:46.320 --> 00:11:49.360
we now get a pie chart next to our data table.

s146
00:11:49.360 --> 00:11:55.920
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.

s147
00:11:55.920 --> 00:11:57.680
We try to keep that complexity incremental.

s148
00:11:57.680 --> 00:12:02.320
And so this satisfies a lot of things that I think are really important about frameworks and DSLs.

s149
00:12:02.320 --> 00:12:05.279
Um, this is very quickly because we won't have time to go into it.

s150
00:12:05.279 --> 00:12:11.920
This is just an example I threw together and recorded of fully client side interactivity where all of these controls are linked.

s151
00:12:11.920 --> 00:12:15.600
Uh, stuff's updating, text is updating, values are updating.

s152
00:12:15.600 --> 00:12:16.800
No JavaScript was written.

s153
00:12:16.800 --> 00:12:21.040
This is just a couple of classes composed that all have the same attribute assigned.

s154
00:12:21.040 --> 00:12:23.680
So they all work together automatically.

s155
00:12:23.680 --> 00:12:27.040
Um, oh, and I did throw in a quick code example of what that looks like.

s156
00:12:27.040 --> 00:12:30.639
We have a class called RX, which as you may guess stands for reactive.

s157
00:12:30.639 --> 00:12:34.720
If you use these reactive variables, you can just reference them anywhere in your code.

s158
00:12:34.720 --> 00:12:35.519
You can format them.

s159
00:12:35.519 --> 00:12:42.160
You can you can make them the name of something and it will automatically compile into the correct uh JavaScript implementation.

s160
00:12:42.160 --> 00:12:44.720
The second thing that we can do is a fastmcp app.

s161
00:12:44.720 --> 00:12:53.360
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

s162
00:12:53.360 --> 00:12:57.519
with a backend and in this case the MCP server is going to be the back end.

s163
00:12:57.519 --> 00:13:03.600
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.

s164
00:13:03.600 --> 00:13:11.920
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.

s165
00:13:11.920 --> 00:13:17.279
That's the entry point that's going to return the prefab components that form the base UI of that application.

s166
00:13:17.279 --> 00:13:22.480
And then at least one, I guess this is optional, so zero or more um app.tools.

s167
00:13:22.480 --> 00:13:27.279
And these are essentially backend methods that you can now reference in the UI.

s168
00:13:27.279 --> 00:13:35.760
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.

s169
00:13:35.760 --> 00:13:42.959
One thing that we use and we ship as a built-in component now in fastmcp is an upload component.

s170
00:13:42.959 --> 00:13:50.880
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.

s171
00:13:50.880 --> 00:13:52.320
It has to go through the brain of the agent.

s172
00:13:52.320 --> 00:13:59.120
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.

s173
00:13:59.120 --> 00:14:02.240
And what you end up doing is the world's most expensive copy paste operation.

s174
00:14:02.240 --> 00:14:05.040
You give the agent a megabyte of text.

s175
00:14:05.040 --> 00:14:13.279
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.

s176
00:14:13.279 --> 00:14:24.240
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.

s177
00:14:24.240 --> 00:14:29.360
And we've made that a oneliner like this along with a handful of other um useful tools.

s178
00:14:29.360 --> 00:14:30.880
And is this a gift?

s179
00:14:30.880 --> 00:14:41.199
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

s180
00:14:41.199 --> 00:14:56.959
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

s181
00:14:56.959 --> 00:15:00.800
oneliner you could try it in your servers uh this afternoon.

s182
00:15:00.800 --> 00:15:06.880
The last thing that I want to talk about which is sort of enabled by this architecture is a fully generative UI.

s183
00:15:06.880 --> 00:15:09.519
Um, we're just going to skip and let this play while I talk.

s184
00:15:09.519 --> 00:15:14.240
So, this is a very simple demo where I asked Claude, "Hey, just I'm giving a talk on this.

s185
00:15:14.240 --> 00:15:17.760
Just start streaming the most interesting UI you can come up with."

s186
00:15:17.760 --> 00:15:19.120
And so, it just went.

s187
00:15:19.120 --> 00:15:28.720
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.

s188
00:15:28.720 --> 00:15:36.880
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.

s189
00:15:36.880 --> 00:15:42.639
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.

s190
00:15:42.639 --> 00:15:48.560
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.

s191
00:15:48.560 --> 00:15:50.000
It can make you whatever you want.

s192
00:15:50.000 --> 00:15:52.000
There are some clients that have built-in versions of this.

s193
00:15:52.000 --> 00:16:00.800
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.

s194
00:16:00.800 --> 00:16:04.240
Now, a really interesting thing happened when we spun this up.

s195
00:16:04.240 --> 00:16:12.240
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.

s196
00:16:12.240 --> 00:16:20.880
What we ended up discovering is that the Python representation of a UI is about 70% smaller than the JSON representation.

s197
00:16:21.040 --> 00:16:23.040
So we don't do this anymore.

s198
00:16:23.040 --> 00:16:25.120
When I recorded this demo was streaming JSON.

s199
00:16:25.120 --> 00:16:28.639
What we now do is we actually stream the Python over the wire.

s200
00:16:28.639 --> 00:16:30.639
It's executed in a sandbox.

s201
00:16:30.639 --> 00:16:34.079
It's turned into JSON on the server and then that's rendered.

s202
00:16:34.079 --> 00:16:39.600
And so this has a dramatic dramatic token efficiency, cost, and latency uh benefit.

s203
00:16:39.600 --> 00:16:45.120
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.

s204
00:16:45.120 --> 00:16:52.320
And it's really fascinating that the Python representation is just that much more compact and ergonomic than the full um JSON one.

s205
00:16:52.320 --> 00:16:54.399
So um that's prefab.

s206
00:16:54.399 --> 00:17:02.720
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.

s207
00:17:02.720 --> 00:17:06.400
You can see the full library uh which is on our GitHub here.

s208
00:17:06.400 --> 00:17:08.959
And this is already fully baked into FastmcP.

s209
00:17:08.959 --> 00:17:17.839
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.

s210
00:17:17.839 --> 00:17:20.559
Thank you all for coming.