WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=s4r6nk5WsZw NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/s4r6nk5WsZw.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:01.309 --> 00:00:03.309 [music] s2 00:00:12.480 --> 00:00:18.600 I know it's 1 minute ahead, but these 20-minute sessions are really short, so I'm going to get started. s3 00:00:18.600 --> 00:00:25.840 So, title of my talk you all have seen cuz you're all here, which is why the heck aren't any agents supporting MCP tasks. s4 00:00:25.840 --> 00:00:30.000 If you don't know what tasks are, don't worry, you will know in just a moment. s5 00:00:30.000 --> 00:00:34.680 But, the first answer to that question is, well, cuz they're smart. s6 00:00:34.680 --> 00:00:37.280 The people who are building those clients are smart. s7 00:00:37.280 --> 00:00:44.760 What I mean by that is that the MCP tasks specification that came out in November was marked as experimental. s8 00:00:44.760 --> 00:00:52.080 And so, well, you might shrug and say, well, gosh, those clients and servers, they're all supporting a whole bunch of experimental things. s9 00:00:52.080 --> 00:00:54.480 Why not MCP tasks? s10 00:00:54.480 --> 00:00:58.640 Well, again, you'll see the answer to that as we move forward. s11 00:00:58.640 --> 00:01:03.840 Um the next answer to that question is, well, they're pretty involved. s12 00:01:03.840 --> 00:01:11.640 Um there's a lot of complexity in here, and that's what I want to do over the next 20 minutes is teach you some of that complexity. s13 00:01:11.640 --> 00:01:14.040 Quick intro, my name is Cornelia Davis. s14 00:01:14.040 --> 00:01:16.840 I'm a technologist at uh Temporal. s15 00:01:16.840 --> 00:01:19.040 Uh we're distributed systems stuff. s16 00:01:19.040 --> 00:01:31.440 I have a long history in distributed systems, did a whole bunch of stuff in the microservices era, um including Cloud Foundry, Kubernetes, GitOps, Weave Works, all of that stuff, and I even wrote a book about that. s17 00:01:31.440 --> 00:01:32.880 That's who I am. s18 00:01:32.880 --> 00:01:42.080 Today's agenda in the next 19 minutes is that rather than just talking about things in the abstract, I'm going to ground us in a very concrete example. s19 00:01:42.080 --> 00:01:45.400 So, I'm going to give you the lay of the land of that concrete example. s20 00:01:45.400 --> 00:01:48.160 Then, I'm going to give you an overview of MCP tasks. s21 00:01:48.160 --> 00:01:53.120 Quick question, who here is wants to do things with tasks? s22 00:01:53.120 --> 00:01:55.240 Async MCP tools. s23 00:01:55.240 --> 00:01:56.080 Okay. s24 00:01:56.080 --> 00:01:58.800 So, I'm going to give you a little bit of an overview. s25 00:01:58.800 --> 00:02:01.720 Um then we're going to talk about it MCP tasks V1. s26 00:02:01.720 --> 00:02:07.280 That's the spec that came out in November and spoiler alert, there's a new one coming out in July. s27 00:02:07.280 --> 00:02:11.760 So, that comment that I made about them being smart about not implementing it yet. s28 00:02:11.760 --> 00:02:14.200 Well, there's some pretty radical changes. s29 00:02:14.200 --> 00:02:23.680 So, I'm going to show you um what's happening with V2 and I actually have some live demos to show all this working and then we'll have some takeaways at the end. s30 00:02:23.680 --> 00:02:29.160 So, the use case that we're going to talk about here is a simple purchase order use case. s31 00:02:29.160 --> 00:02:35.000 So, the use case is you're going to get in a purchase order and then it's going to go through a number of steps. s32 00:02:35.000 --> 00:02:46.200 It's going to record the fact that the goods were received and then it's going to do in parallel, it's going to do some back office stuff updating inventory, sending out notifications s33 00:02:46.200 --> 00:02:51.000 and then in parallel to that it's going to pay some invoices. s34 00:02:51.000 --> 00:02:55.760 Now, the invoicing is going to happen via an MCP tool. s35 00:02:55.760 --> 00:03:01.080 Now, that MCP tool is has itself a number of steps. s36 00:03:01.080 --> 00:03:08.680 So, it's going to validate against an ERP, then it's going to have a little human in the loop to request approval, maybe. s37 00:03:08.680 --> 00:03:14.239 Um then it's going to reconcile against the ERP again, do a little bit more human in the loop and so on. s38 00:03:14.239 --> 00:03:23.280 So, you can see that on the right hand side that MCP server that's going to be it's a tool that's going to be doing the invoice processing for us. s39 00:03:23.280 --> 00:03:25.080 It is long running. s40 00:03:25.080 --> 00:03:31.920 It's not going to work in a request response style and that's what MCP tasks are all about. s41 00:03:31.920 --> 00:03:44.720 And what we're going to do and I'm today's talk is not about temporal, but really what I did here was just showed you a couple of snippets of the code and yes, I will be sharing all the code for what I'm showing today. s42 00:03:44.720 --> 00:03:50.000 Couple of snippets here and the real point that I want you to look at is that reject or approve. s43 00:03:50.000 --> 00:03:56.280 That is showing you that there is a mechanism for signaling into a long-running process. s44 00:03:56.280 --> 00:03:58.040 And that's really the point. s45 00:03:58.040 --> 00:04:02.360 And that's what we need is that this is all about asynchronous. s46 00:04:02.360 --> 00:04:04.920 So, you understand what MCP tasks are now? s47 00:04:04.920 --> 00:04:17.280 MCP tasks are allowing you to have an MCP tool that you can invoke and then it is long-running in the background, and then eventually you can get back some response. s48 00:04:17.280 --> 00:04:21.480 So, let's talk about that MCP tasks overview. s49 00:04:21.480 --> 00:04:24.200 This is a very simple sequence diagram. s50 00:04:24.200 --> 00:04:30.840 It's exactly what you all would expect when I tell you that MCP tasks are long-running tasks. s51 00:04:30.840 --> 00:04:36.840 You're going to invoke a tool, and instead of getting back a response, you're going to get a handle. s52 00:04:36.840 --> 00:04:39.040 And you can interact with that handle, right? s53 00:04:39.040 --> 00:04:40.360 Obvious, right? s54 00:04:40.360 --> 00:04:42.440 This is This isn't rocket science. s55 00:04:42.440 --> 00:04:44.640 Looks easy enough, right? s56 00:04:44.640 --> 00:04:53.400 Well, it turns out that if you actually want this to work over long horizons, it gets a little bit more complicated than that. s57 00:04:53.400 --> 00:04:55.960 So, what are some of those complications? s58 00:04:55.960 --> 00:05:07.160 Well, you can have all sorts of the longer something runs, the more likely there's going to be some kind of infrastructure blip that's going to cause a problem in that long-running task. s59 00:05:07.160 --> 00:05:20.440 So, you could have network blips, you could have network challenges, you could have humans that you're waiting for their in-a-loop part, and they go away on vacation like I'm about to, yay, s60 00:05:20.440 --> 00:05:22.360 um day after tomorrow. s61 00:05:22.360 --> 00:05:25.000 Um or processes can crash. s62 00:05:25.000 --> 00:05:26.560 So, your agent can go down. s63 00:05:26.560 --> 00:05:32.880 The agent that's processing the purchase order can go down, or your MCP server can go down as well. s64 00:05:32.880 --> 00:05:39.680 So, all of those problems you need to deal with, and those are the things that makes it a little bit more difficult. s65 00:05:39.680 --> 00:05:52.160 Now, in addition to what I've told you about MCP tasks so far that you're going to get back a handle that you can interact with by the specification those MCP s66 00:05:52.160 --> 00:05:55.640 tasks can't disappear. s67 00:05:55.640 --> 00:06:03.440 This is verbage from the spec itself that says once you've locked launched a task it has to be durable. s68 00:06:03.440 --> 00:06:15.160 What that means is all of these things that I just showed you on the previous screen clients humans going away on vacation servers going down clients going down connections s69 00:06:15.160 --> 00:06:25.320 disconnecting the task needs to survive that and you need to be able to interact with that task when the infrastructure comes back. s70 00:06:25.320 --> 00:06:28.040 And I'm going to show you how all of that is done. s71 00:06:28.040 --> 00:06:40.080 Now on there's elements there's server side elements that talk about how you make the server side durable and I did a talk at the MCP Dev Summit in March s72 00:06:40.080 --> 00:06:49.560 and this is the QR code that it will take you to that YouTube video and that's where I go into a lot of detail about the server side and what you need to do with the server side. s73 00:06:49.560 --> 00:06:56.919 Today as you saw is an extension of that work where I'm talking about the client side. s74 00:06:57.000 --> 00:07:00.240 So without further ado let me go into a demo. s75 00:07:00.240 --> 00:07:03.760 I for those of you who know me I'm always doing demos. s76 00:07:03.760 --> 00:07:06.600 So what we have here is we have a dashboard. s77 00:07:06.600 --> 00:07:16.160 Um I am not doing this through a chat interface because it frankly it's more efficient for me to click a couple of buttons here to show you this rather than trying to type things in. s78 00:07:16.160 --> 00:07:21.360 So I have a user interface here that's showing you the number of purchase orders that have been submitted. s79 00:07:21.360 --> 00:07:35.160 I'm going to submit a simple purchase order so that's just a button that is kicking things off and in a moment if the dam demo gods are with me it says submitted we should see the purchase order pop up here and it should show some s80 00:07:35.160 --> 00:07:40.320 Ah here's why it's not working because I haven't started my servers. s81 00:07:40.320 --> 00:07:44.720 So remember I said it has to work even when the servers aren't running. s82 00:07:44.720 --> 00:07:51.840 I forgot to show you here that what I'm doing in this these two windows is in the upper window, I'm starting the back end. s83 00:07:51.840 --> 00:07:54.560 This is the MCP server. s84 00:07:54.560 --> 00:07:59.440 And in the um lower window, I am starting the MCP client. s85 00:07:59.440 --> 00:08:01.520 And you'll see what that client is in a moment. s86 00:08:01.520 --> 00:08:06.840 You can see in the splash screen there that I am using fast MCP on the client side. s87 00:08:06.840 --> 00:08:15.800 So, let's go back here and notice that even though I submitted that, even though my servers weren't running, that submission did go through. s88 00:08:15.800 --> 00:08:17.520 So, it's captured that. s89 00:08:17.520 --> 00:08:27.880 So, what you can see here, and you didn't see it cycle through, but on the far right-hand side, the invoice task is it initially showed you that it was work submitted, s90 00:08:27.880 --> 00:08:33.159 then it showed you that it was working, and now it's asking for input required. s91 00:08:33.159 --> 00:08:34.240 I can come over here. s92 00:08:34.240 --> 00:08:37.919 Let me show you what's going on at the back end and at the front end. s93 00:08:37.919 --> 00:08:43.360 What I have here are some dashboards that are showing those running processes. s94 00:08:43.360 --> 00:08:46.000 On the right-hand side, you have the back end. s95 00:08:46.000 --> 00:08:49.160 That's where the invoice processing is, and you can see the name here. s96 00:08:49.160 --> 00:08:53.040 Let me increase the font size there a little bit. s97 00:08:53.040 --> 00:08:58.720 So, you can see that this is running the invoice, and on the left-hand side, you can see that it's running the PO. s98 00:08:58.720 --> 00:09:03.080 I'll explain that task tracker thing in just a moment. s99 00:09:03.080 --> 00:09:08.360 So, if we go into the invoice, we can see that it has the process that we talked about earlier. s100 00:09:08.360 --> 00:09:12.120 It validated against the ERP, and now it's waiting for human input. s101 00:09:12.120 --> 00:09:14.320 It's waiting for that approval. s102 00:09:14.320 --> 00:09:22.680 Over on the PO side, we can also see the process that I showed you earlier, which is to say, let's go back here. s103 00:09:22.680 --> 00:09:25.240 It is So, ah, yes. s104 00:09:25.240 --> 00:09:29.320 So, it did that record recorded that the goods were received. s105 00:09:29.320 --> 00:09:35.400 Then, in parallel, it's invoking the invoice processor MCP task. s106 00:09:35.400 --> 00:09:40.080 And notice that there's this line item here that says task tracker workflow. s107 00:09:40.080 --> 00:09:41.160 Yes, indeed. s108 00:09:41.160 --> 00:09:43.800 That is my MCP client implementation. s109 00:09:43.800 --> 00:09:47.120 Remember I said nobody's implemented this on the client side? s110 00:09:47.120 --> 00:09:49.760 Well, I created my own implementation here. s111 00:09:49.760 --> 00:09:56.000 But in parallel with doing the invoice processing, we also had this back office stuff that was happening. s112 00:09:56.000 --> 00:10:02.720 So if I come back over here and I click on input required, I can approve this. s113 00:10:02.720 --> 00:10:04.120 And I'll hit submit. s114 00:10:04.120 --> 00:10:10.640 And we come over here and you'll see in just a moment that the signal is going to come into the back end. s115 00:10:10.640 --> 00:10:11.920 Uh need to refresh. s116 00:10:11.920 --> 00:10:13.080 Oh, there it goes. s117 00:10:13.080 --> 00:10:20.240 So the approval came into the back end and now the back end is going ahead with its additional process paying the invoice. s118 00:10:20.240 --> 00:10:22.560 And you'll see a number of line items there. s119 00:10:22.560 --> 00:10:31.680 There's some um some uh re- uh retries that are have been programmed in here, but you can see here that it took a few tries before the the ERP went through. s120 00:10:31.680 --> 00:10:36.760 We paid the line item and now you can see that the task completed. s121 00:10:36.760 --> 00:10:38.240 So everything's completed. s122 00:10:38.240 --> 00:10:48.400 If I go back to the dashboard that you saw at the top, you can see that all of those processes completed. s123 00:10:48.400 --> 00:10:49.320 Okay? s124 00:10:49.320 --> 00:10:51.440 So that's the basic stuff. s125 00:10:51.440 --> 00:11:00.080 And I can run that again, but in the in I already gave you inadvertently gave you the example of the infrastructure was down. s126 00:11:00.080 --> 00:11:07.080 I could have killed that server halfway through and it would have continued exactly exactly as you saw here. s127 00:11:07.080 --> 00:11:07.280 Okay? s128 00:11:07.280 --> 00:11:09.760 So you saw it at the very beginning. s129 00:11:09.760 --> 00:11:11.920 All right, let's go back to slides. s130 00:11:11.920 --> 00:11:13.720 So that's the first demo. s131 00:11:13.720 --> 00:11:18.880 So let's talk about um tasks version one. s132 00:11:18.880 --> 00:11:22.520 So in tasks version one, there were a number of tool semantics. s133 00:11:22.520 --> 00:11:28.040 And again, I go over these tool semantics in a lot more detail in that MCP Dev Summit talk. s134 00:11:28.040 --> 00:11:40.640 But there's one really interesting thing that I want to draw your attention to, which is that tasks come with it One of the things that the specification defines is a life cycle for tasks. s135 00:11:40.640 --> 00:11:43.000 And that's what you see here on the screen. s136 00:11:43.000 --> 00:11:44.720 It has working. s137 00:11:44.720 --> 00:11:46.760 It can go into an input required. s138 00:11:46.760 --> 00:11:53.720 From input required, it can go back to working, and then eventually it'll complete or be canceled or fail. s139 00:11:53.720 --> 00:12:03.160 So, that's one of the things that's super interesting about the task specification is that it's about the life cycle of the task. s140 00:12:03.160 --> 00:12:09.280 There's a whole bunch of other semantics there as well around obtaining inputs and delivering results. s141 00:12:09.280 --> 00:12:15.600 And I'm going to go through this fairly quickly because I already mentioned some of this is going away. s142 00:12:15.600 --> 00:12:20.080 So, this is what the tool semantics were before the task semantics. s143 00:12:20.080 --> 00:12:24.640 Notice that tools/call is exactly the same. s144 00:12:24.640 --> 00:12:28.560 There's some metadata that you pass in when you want it to be async. s145 00:12:28.560 --> 00:12:35.160 And then there's task get cancel list, as well as task result. s146 00:12:35.160 --> 00:12:39.200 And so, the top four are request-response in style. s147 00:12:39.200 --> 00:12:41.800 The bottom one keeps a connection open. s148 00:12:41.800 --> 00:12:43.800 It keeps a connection alive. s149 00:12:43.800 --> 00:12:47.760 And the sequence diagram that you can see here is kind of the basic stuff. s150 00:12:47.760 --> 00:12:56.120 Now, there's two hiccups with this um uh two major challenges with this particular version of the protocol. s151 00:12:56.120 --> 00:12:58.400 The first one is right here. s152 00:12:58.400 --> 00:13:00.080 Task list. s153 00:13:00.080 --> 00:13:02.839 This is a stateful protocol. s154 00:13:02.839 --> 00:13:09.720 So, what that means is that the Remember I said that the server was responsible for durability? s155 00:13:09.720 --> 00:13:17.440 Well, this particular endpoint allows me to go to the server and say, "Hey, what tasks do you have?" s156 00:13:17.440 --> 00:13:32.600 So, if I have had if the client has gone away, if the user took too long to respond, if my network dropped out and I had to reconnect, I can use this task list to go back to the server and say, "What have you got?" s157 00:13:32.600 --> 00:13:35.520 And then you can continue on with that. s158 00:13:35.520 --> 00:13:52.280 That works fine if you have one task or two tasks, or maybe it it even works if you have 10 tasks, but what happens if you've got a whole slew of agents out there and you've got a million tasks at the back end. s159 00:13:52.280 --> 00:13:56.040 Spoiler alert, there is no filter on that endpoint. s160 00:13:56.040 --> 00:14:02.120 So, you would have to go through a million tasks to find the one that you're looking for that you want to interact with. s161 00:14:02.120 --> 00:14:03.600 This is going away. s162 00:14:03.600 --> 00:14:06.200 You'll see in just a moment, but that's one of the challenges. s163 00:14:06.200 --> 00:14:08.560 Just because you can doesn't mean you should. s164 00:14:08.560 --> 00:14:15.440 The other one is the task result because that is where we were tunneling the input required. s165 00:14:15.440 --> 00:14:20.200 So, in the case of task result, this sequence diagram is really simple. s166 00:14:20.200 --> 00:14:23.240 It doesn't have the the interactivity. s167 00:14:23.240 --> 00:14:35.760 What we have as soon as you do task as soon as you have input required is the top and bottom are just fine, but this middle section has this weird protocol where you open a long-running connection s168 00:14:35.760 --> 00:14:40.280 and then the server elicits a response from the client. s169 00:14:40.280 --> 00:14:42.839 That gets super tricky. s170 00:14:42.839 --> 00:14:47.720 And I'm running short on time, so I'm not actually going to show you this demo. s171 00:14:47.720 --> 00:14:48.760 Happy to show it to you. s172 00:14:48.760 --> 00:14:51.080 I'll be around all day tomorrow, too. s173 00:14:51.080 --> 00:14:59.040 So, I can happy to show it to you, but I want to show you instead Here's basically the architecture of what you need to build on the server side. s174 00:14:59.040 --> 00:15:02.360 This is Notice that this is using fast MCP. s175 00:15:02.360 --> 00:15:08.640 So, fast MCP already has support for server side and some client side stuff as well. s176 00:15:08.640 --> 00:15:18.120 But, the interesting thing is notice that little box in the on the left-hand side that on the on the lower part where it says MCP client protocol handler? s177 00:15:18.120 --> 00:15:25.960 That protocol handler with the ugliness that I just showed you or results actually looks like this. s178 00:15:25.960 --> 00:15:30.560 And I can show this to you running and it has all sorts of complexity in it. s179 00:15:30.560 --> 00:15:32.200 I got to have the long-running connection. s180 00:15:32.200 --> 00:15:35.480 Well, what happens if my connection dies in the middle of that? s181 00:15:35.480 --> 00:15:38.320 How do I pick up where I left off when I come back? s182 00:15:38.320 --> 00:15:44.320 You'll see that a big part of what the task specification does is it talks about durability. s183 00:15:44.440 --> 00:15:51.000 So, back to the question of why the heck aren't there any clients that are supporting this protocol? s184 00:15:51.000 --> 00:15:52.520 Yeah. s185 00:15:52.520 --> 00:15:53.920 That's why. s186 00:15:53.920 --> 00:15:55.640 Super involved. s187 00:15:55.640 --> 00:15:58.600 It's still involved with V2, but it gets better. s188 00:15:58.600 --> 00:16:00.960 So, let me tell you about that. s189 00:16:00.960 --> 00:16:12.840 So, in May, Angie Jones, who's responsible for developer experience at the Agoric AI Foundation, which is where MCP now lives, posted this blog. s190 00:16:12.840 --> 00:16:21.240 And one of the things that made me jump up and celebrate a little bit is that the protocol is going stateless. s191 00:16:21.240 --> 00:16:32.200 So, as somebody who's been working in the microservices world for a long time, stateful protocols are the absolute worst thing in large-scale distributed systems. s192 00:16:32.200 --> 00:16:34.080 So, the protocol is going stateless. s193 00:16:34.080 --> 00:16:37.000 It's also doing a number of other things. s194 00:16:37.000 --> 00:16:39.000 So, the first bullet is a stateless core. s195 00:16:39.000 --> 00:16:46.320 The second bullet is interesting cuz it's they also have structured MCP so that there's a core and there's extensions. s196 00:16:46.320 --> 00:16:54.080 If some of you were in the room for the previous two talks, they talked about MCPUI two talks ago, they mentioned extension. s197 00:16:54.080 --> 00:17:04.800 Well, that's what's happening here in the V2 MCP protocol is that they have extensions and tasks have become an extension. s198 00:17:04.800 --> 00:17:12.280 So, let me tell you a little bit about how tasks changed from V1 to V2 and I do want to give you one more demo. s199 00:17:12.280 --> 00:17:16.640 So, on the left-hand side, you can see what the protocol was before. s200 00:17:16.640 --> 00:17:19.920 These are the RPC requests that you were doing over the wire. s201 00:17:19.920 --> 00:17:23.640 On the right-hand side, you can see a couple of things. s202 00:17:23.640 --> 00:17:27.040 Task list has gone away. s203 00:17:27.040 --> 00:17:28.199 Good. s204 00:17:28.199 --> 00:17:32.960 Wasn't particularly useful anyway, especially at large scale. s205 00:17:32.960 --> 00:17:45.960 And instead of having this input required going over a long-running session, you now have an endpoint that allows you from the client side to say, "Here's an update." s206 00:17:45.960 --> 00:17:52.160 So, if you remember a while ago, I showed you that screenshot that said Temporal has this notion of a signal. s207 00:17:52.160 --> 00:17:53.880 That's effectively what this is. s208 00:17:53.880 --> 00:17:57.720 It's a way of signaling into this long-running task. s209 00:17:57.720 --> 00:18:04.360 The task result stays, but it changes because it no longer has this long session-based protocol. s210 00:18:04.360 --> 00:18:15.120 But, I put the picture on the right-hand side here to emphasize the fact that the life cycle management of these tasks is unchanged. s211 00:18:15.120 --> 00:18:17.440 That's actually sound. s212 00:18:17.440 --> 00:18:23.000 Now, I go into this a lot into more detail in the talk that I keep referring to. s213 00:18:23.000 --> 00:18:30.360 Um on the server side, in invoice processing, I have my own state machine that the invoice is going through. s214 00:18:30.360 --> 00:18:48.800 And so, part of what you're doing when you implement these server-side these tasks is you're mapping from the life cycle states of the task over to the domain state machine that's running the the application that the the MCP server in the back end or the tool. s215 00:18:48.800 --> 00:18:51.000 So, list again goes away. s216 00:18:51.000 --> 00:18:57.200 Now, remember I said that the MCP tasks specification has durability all over it? s217 00:18:57.200 --> 00:19:07.000 With this change, given that lists are gone, you now are required on the client side, well, kind of required. s218 00:19:07.000 --> 00:19:10.840 There's a little an a little uh parenthetical remark here. s219 00:19:10.840 --> 00:19:22.480 The The spec right now says that clients should persist task IDs, but it also points out that if you don't persist task IDs, there is no way to get it back. s220 00:19:22.480 --> 00:19:28.160 So, I'm not quite sure why this doesn't have a an all caps must. s221 00:19:28.160 --> 00:19:37.560 The other thing that I want to point out is that I already mentioned it is that you're going to have potentially a lot of agents that are processing POs s222 00:19:37.560 --> 00:19:40.560 or a lot of agents that are doing a lot of things. s223 00:19:40.560 --> 00:19:46.880 And so, having multiple things running, I think is really um crucial as well. s224 00:19:46.880 --> 00:19:53.680 So, with that um I'm going to go to the the second demo. s225 00:19:53.680 --> 00:19:58.080 And I'm going to go back to my purchase order here. s226 00:19:58.080 --> 00:20:02.920 So, what I'm going to do now is I'm going to submit a number of things. s227 00:20:02.920 --> 00:20:07.520 And I'm actually still demoing here because I have 13 seconds left. s228 00:20:07.520 --> 00:20:09.800 I'm not going to switch over to my V2. s229 00:20:09.800 --> 00:20:15.120 You'll see that from the high level, it actually looks exactly the same. s230 00:20:15.120 --> 00:20:20.480 I am going to show you what the client proto- client server protocol looks like in the V1 case. s231 00:20:20.480 --> 00:20:21.680 It's really quite ugly. s232 00:20:21.680 --> 00:20:27.600 But, you'll notice here that we have um I've submitted a bunch of different ones. s233 00:20:27.600 --> 00:20:40.640 I can tell you with the V1 protocol, the reference implementation, if you had input required on multiple even though you can see that there's many of them in flight, on the client side they were FIFO. s234 00:20:40.640 --> 00:20:43.200 So, you could only respond to the first one. s235 00:20:43.200 --> 00:20:47.960 And part of the protocol that I implemented was to get around that gap. s236 00:20:47.960 --> 00:20:49.400 So, let's come over here. s237 00:20:49.400 --> 00:20:55.560 We can refresh both of these and you can see that there's going to be a bunch of POs in flight. s238 00:20:55.800 --> 00:20:59.080 And now I want to show you the task tracker. s239 00:20:59.080 --> 00:21:03.040 So, if we go into the task tracker, that's the MCP client. s240 00:21:03.040 --> 00:21:07.200 And now let me just expand this so we can see it in a little bit more detail. s241 00:21:07.200 --> 00:21:14.560 What you can see here is that remember that that protocol, I showed you that big long sequence diagram? s242 00:21:14.560 --> 00:21:16.920 There's a lot of steps involved in that. s243 00:21:16.920 --> 00:21:20.960 And what I've done here is I've implemented it as a workflow. s244 00:21:20.960 --> 00:21:27.320 And you can see here that there's some elicitation handling that's going from the server side back to the client. s245 00:21:27.320 --> 00:21:33.640 So, I won't go into any more details cuz I'm literally out of time now, but I want to share two more things. s246 00:21:33.640 --> 00:21:45.080 And that is Um so, going from V1, remember this ugly picture, to V2 in the client server protocol, much much cleaner. s247 00:21:45.080 --> 00:21:47.720 Much easier to implement. s248 00:21:47.720 --> 00:21:53.520 So, speaking of implementing, here's a summary of all the things that you need to do if you want to implement tasks. s249 00:21:53.520 --> 00:21:55.120 Still relatively involved. s250 00:21:55.120 --> 00:21:56.080 Here's a picture. s251 00:21:56.080 --> 00:22:01.480 I'm going to make these slides available in the Git repo that I'm about to show you. s252 00:22:01.480 --> 00:22:04.400 And here's the Git repo that I'm going about to show you. s253 00:22:04.400 --> 00:22:10.560 And while you're getting that screenshot, I'm going to tell you about two pieces of work that I'm continuing with. s254 00:22:10.560 --> 00:22:18.040 Number one, even though this is better, it still doesn't scale to the millions. s255 00:22:18.040 --> 00:22:19.120 Why? s256 00:22:19.120 --> 00:22:27.760 Because if I've got a million tasks running, I've got a million clients that are doing gets against each and every one of those tasks. s257 00:22:27.760 --> 00:22:29.800 That does not scale. s258 00:22:29.800 --> 00:22:45.160 There is a part of the MCPC task specification that is a notifications protocol, which I haven't gotten far enough yet, but it's showing promise, which is going to allow you to, instead of having a million clients s259 00:22:45.160 --> 00:22:53.120 uh uh to uh pulling their tasks, it's going to have a single endpoint where they can say, "Has something changed?" s260 00:22:53.120 --> 00:22:58.080 And if it has, tell me which one, and now I'll go pull that task. s261 00:22:58.080 --> 00:23:01.040 So, it's definitely from a scale perspective. s262 00:23:01.040 --> 00:23:13.120 The other thing that we're doing is in the very near future in the next month or so or two, we're going to have a an implementation of all of this where it's going to be much simpler for you. s263 00:23:13.120 --> 00:23:17.786 My goal is to actually implement it in in fast MCP so s264 00:23:17.786 --> 00:23:17.840 [snorts] s265 00:23:17.840 --> 00:23:24.160 that you can use the same protocol the same framework that you're using probably for your MCP servers today. s266 00:23:24.160 --> 00:23:26.080 So without further ado, that is it. s267 00:23:26.080 --> 00:23:30.680 Thank you to the next speaker for letting me go a few minutes long and I'll be around. s268 00:23:30.680 --> 00:23:34.816 I'll step out if you have any questions find me in the hallway. s269 00:23:34.816 --> 00:23:36.816 [applause]