1 00:00:00,040 --> 00:00:02,400 Now we're in a state where people rely on the SDKS, where 2 00:00:02,400 --> 00:00:06,400 the SDKS have hundreds of millions of downloads a year or 3 00:00:06,400 --> 00:00:11,640 a month, and that gives us a different lever that we didn't 4 00:00:11,640 --> 00:00:13,720 have 12 months ago. And you need to be aware of 5 00:00:13,720 --> 00:00:17,320 these and then use them to your advantage and and be mindful 6 00:00:17,320 --> 00:00:20,080 around the limitations. It does feel like a maturing 7 00:00:20,360 --> 00:00:21,920 and. It does start this maturing, 8 00:00:21,920 --> 00:00:24,200 yeah. Yeah, it's, it's something that 9 00:00:24,200 --> 00:00:28,400 you're like, oh, very clear value prop. 10 00:00:28,400 --> 00:00:31,120 There I need to do the minimal thing that I I know I can extend 11 00:00:31,120 --> 00:00:36,360 so I can solve future problems additively rather than subtract 12 00:00:36,360 --> 00:00:38,200 like with a subtraction or removing things. 13 00:00:38,320 --> 00:00:40,760 What do you think people don't understand about tasks? 14 00:00:54,760 --> 00:00:57,080 All right, probably a good place to start this one, dude. 15 00:00:57,080 --> 00:01:00,320 And what I'm most stoked about is hearing the context around 16 00:01:00,320 --> 00:01:01,680 the new release. What is it? 17 00:01:01,680 --> 00:01:03,200 What was the inspiration behind it? 18 00:01:03,440 --> 00:01:04,680 Yeah. And like the, I think the new 19 00:01:04,680 --> 00:01:08,440 release is honestly probably one of the biggest release we have 20 00:01:08,440 --> 00:01:12,960 ever done around MCP. It has a one big change to how 21 00:01:12,960 --> 00:01:18,560 we are using MCP in in the sense that when we originally 22 00:01:18,560 --> 00:01:22,840 developed MCP over the last year, the the protocol was 23 00:01:22,840 --> 00:01:25,800 somewhat stateful. So you needed to keep you know a 24 00:01:25,800 --> 00:01:28,000 session open between the server and the client. 25 00:01:28,320 --> 00:01:31,040 And that did not work very well for some of their particularly 26 00:01:31,040 --> 00:01:34,400 big hyper scalers that now use MCP pretty much everywhere. 27 00:01:34,480 --> 00:01:36,600 That being the Microsoft of the world, the Google's of the 28 00:01:36,600 --> 00:01:38,360 world, the anthropics of the world. 29 00:01:38,680 --> 00:01:43,280 And so this release is really about moving away from the 30 00:01:43,280 --> 00:01:46,720 statefulness of the protocol to a full day stateless protocol. 31 00:01:46,720 --> 00:01:50,520 And we have worked really, really hard to make this work in 32 00:01:50,520 --> 00:01:54,880 the, in the way MCP operates. And I've put a lot of work into 33 00:01:54,880 --> 00:01:57,360 this and this probably the biggest change we've ever done 34 00:01:57,360 --> 00:01:59,400 to the protocol. So I'm I'm super hyped about it. 35 00:01:59,760 --> 00:02:03,400 So no more handshakes. What can you go a little bit 36 00:02:03,400 --> 00:02:06,200 deeper into this inspiration? Because you probably saw this 37 00:02:06,200 --> 00:02:09,680 coming up and then there was a point where you were like, we 38 00:02:09,680 --> 00:02:11,320 need to figure out what's going on here. 39 00:02:11,840 --> 00:02:15,240 Yeah, like the the original version of the protocol, right. 40 00:02:15,240 --> 00:02:18,120 It was like all standard IO. It was like it was a very 41 00:02:18,120 --> 00:02:21,800 natural thing that you have this notion of, you know, a program 42 00:02:21,800 --> 00:02:25,040 that you can always interact with that's this MCP server. 43 00:02:25,200 --> 00:02:28,800 And then as we went over trying to do this over HTTP, we tried 44 00:02:28,800 --> 00:02:31,920 to retain this because we fundamentally believed that 45 00:02:32,000 --> 00:02:36,360 agents are somewhat stateful. But it turned out operationally 46 00:02:36,360 --> 00:02:38,760 over the year we learned that there are other methods how you 47 00:02:38,760 --> 00:02:42,760 can still get that without having to rely on a stateful 48 00:02:42,760 --> 00:02:45,040 protocol or a stateful transport. 49 00:02:45,400 --> 00:02:49,800 And the cracks kind of showed, particularly when we saw again, 50 00:02:49,800 --> 00:02:54,080 the really big hyperscaler tried to do this with like at like 51 00:02:54,080 --> 00:02:56,720 massive scale, like thousands of 10s of thousands of servers 52 00:02:56,720 --> 00:02:58,280 serving like millions of requests. 53 00:02:58,520 --> 00:03:00,800 And then you're like, you're getting into really hard 54 00:03:00,800 --> 00:03:03,080 difficulty problems of like, how do you scale this? 55 00:03:03,080 --> 00:03:04,960 How do you, you know, move the state around? 56 00:03:05,800 --> 00:03:07,720 There's a particular problem where, you know, you hit one 57 00:03:07,720 --> 00:03:10,160 server and you kind of want to have a load balance to hit the 58 00:03:10,160 --> 00:03:12,400 next server. But if you have some for state 59 00:03:12,400 --> 00:03:14,840 in this one server, you kind of need to communicate this to the 60 00:03:14,840 --> 00:03:16,600 other server. That's hard to do. 61 00:03:16,600 --> 00:03:18,720 And you can do it and, but it's painful. 62 00:03:18,960 --> 00:03:23,440 It's, it causes latencies and it causes CPU usage And it's just 63 00:03:23,440 --> 00:03:27,240 like very unpleasant to serve. And so a lot of the hyper scaler 64 00:03:27,240 --> 00:03:30,520 really wants stateless workloads, but that they can go 65 00:03:30,520 --> 00:03:34,800 to 1 server, make a request, take the request, go to the next 66 00:03:34,800 --> 00:03:37,320 server and do you know something else? 67 00:03:37,560 --> 00:03:40,320 And everything you know can go through a load balancer, 68 00:03:40,320 --> 00:03:42,960 everything can, you know, some of the things can be cached. 69 00:03:43,200 --> 00:03:45,360 Just the standard things we kind of know how to do. 70 00:03:46,160 --> 00:03:50,120 We kind of went there and we again overtime figured out what 71 00:03:50,120 --> 00:03:52,680 are the pieces of MTP that needs to be stateful, what are the 72 00:03:52,680 --> 00:03:53,880 pieces that don't need be stateful? 73 00:03:53,880 --> 00:03:56,200 And we decided the transport part doesn't need to be. 74 00:03:56,520 --> 00:04:01,040 And so it's, I think it's a very natural, you know, progression 75 00:04:01,040 --> 00:04:04,280 and evolution of the protocol. Maybe you could have seen some 76 00:04:04,280 --> 00:04:06,680 of that bit earlier, but I think now I think it's a great time 77 00:04:06,680 --> 00:04:09,280 and we have worked really hard with again some of the the 78 00:04:09,280 --> 00:04:12,560 industry giants honestly to like make this work for them and also 79 00:04:12,560 --> 00:04:14,760 make it work for us. It does feel like a maturing 80 00:04:15,000 --> 00:04:16,519 and. This is, yeah, it certainly is 81 00:04:16,519 --> 00:04:18,920 maturing, Yeah. Yeah, it's, it's something that 82 00:04:18,920 --> 00:04:23,400 you're like, oh, very clear value prop there. 83 00:04:23,640 --> 00:04:26,760 Are there any trade-offs that you had to grapple with when you 84 00:04:26,760 --> 00:04:30,080 were deciding this? Yeah, some of the hardest part 85 00:04:30,080 --> 00:04:34,400 is that some things inside the protocol are somewhat inherently 86 00:04:34,400 --> 00:04:37,520 stateful. So for example, if you send a 87 00:04:37,520 --> 00:04:41,520 tool request and you want to do an elicitation, so you ask the 88 00:04:41,520 --> 00:04:45,720 user for explicitly for input, that is kind of bound to that 89 00:04:45,720 --> 00:04:48,920 tool call. In the original specification, 90 00:04:49,040 --> 00:04:53,160 it was actually could at any time send this elicitation even 91 00:04:53,160 --> 00:04:55,720 if there's no tool call. So we have to make constraints 92 00:04:55,720 --> 00:04:58,560 of like now you need to do it within a true call, which is we 93 00:04:58,560 --> 00:05:02,640 we did a survey of all guitar proposals we could find and 94 00:05:02,640 --> 00:05:07,480 basically 99.9% use it exactly the way we are a tool call. 95 00:05:08,640 --> 00:05:13,800 But it means that when you do this, you, you still need a way 96 00:05:13,800 --> 00:05:16,160 for like there's some form of state being hold on a server 97 00:05:16,160 --> 00:05:18,840 while this true call is ongoing and you asking for input from 98 00:05:18,840 --> 00:05:21,160 the user. And so we needed to build a 99 00:05:21,280 --> 00:05:25,120 little bit of a machinery on top of it of this like statefulness 100 00:05:25,120 --> 00:05:28,640 approach as statelessness approach, which we call multi 101 00:05:28,640 --> 00:05:35,440 round trip responses, which or requests which require you to 102 00:05:35,440 --> 00:05:39,440 basically go there, do a tool call, get an hesitation back, 103 00:05:39,920 --> 00:05:42,480 put all of this together to call plus solicitation result and 104 00:05:42,480 --> 00:05:46,240 send it again. So you're basically appending to 105 00:05:46,240 --> 00:05:49,160 the context and you're transporting the whole context 106 00:05:49,400 --> 00:05:52,840 over the wire. And that just allows the like 107 00:05:53,000 --> 00:05:58,360 another server can now send like response without having, you 108 00:05:58,360 --> 00:05:59,920 know, while having the full context. 109 00:05:59,920 --> 00:06:02,680 So there was some of that machinery we needed to build 110 00:06:02,680 --> 00:06:07,560 into that is less that is a bit more unique to MCP because we 111 00:06:07,560 --> 00:06:10,800 have this like there's inherent statefulness in some of the 112 00:06:10,800 --> 00:06:13,120 semantics that we that are in the protocol. 113 00:06:13,320 --> 00:06:17,000 Well, it does feel like these agents and the assumption at the 114 00:06:17,000 --> 00:06:20,560 beginning of this needs to be stateful because agents 115 00:06:20,560 --> 00:06:24,760 potentially have these unique characteristics and that got 116 00:06:24,760 --> 00:06:28,480 disproven in a way, if I'm understanding you correctly. 117 00:06:28,480 --> 00:06:31,240 Can you talk a little bit more about how that got disproven? 118 00:06:32,280 --> 00:06:35,600 I I think that it's less about it got disproven as a as a 119 00:06:35,600 --> 00:06:37,440 concept. I think it what we learned is 120 00:06:37,440 --> 00:06:40,120 that it doesn't have to be on a transport level. 121 00:06:40,120 --> 00:06:44,000 So it doesn't have to be on the HTTP channel that the state is 122 00:06:44,000 --> 00:06:47,520 open. So for example, the that there 123 00:06:47,520 --> 00:06:50,080 is state between a tool call and elicitation. 124 00:06:50,080 --> 00:06:52,200 When you make a tool call and you ask the user for input, 125 00:06:52,400 --> 00:06:55,600 there is some form of state. You know the tool call waits for 126 00:06:55,600 --> 00:06:59,040 that elicitation to to be done and get this additional input. 127 00:06:59,040 --> 00:07:02,320 So there's some form of state. But what we have now done is we 128 00:07:02,320 --> 00:07:07,000 have taken all this state that is required and basically move 129 00:07:07,000 --> 00:07:08,920 it over the wire over and over again. 130 00:07:09,120 --> 00:07:11,960 So effectively making the the transport doesn't have to be 131 00:07:11,960 --> 00:07:17,000 open all the time, but the data still encapsulates that kind of 132 00:07:17,000 --> 00:07:18,920 state. And So what we have learned is 133 00:07:18,920 --> 00:07:22,840 just to be more efficient about encapsulating and how we encode 134 00:07:22,840 --> 00:07:25,280 the state. And we have learned areas where 135 00:07:25,280 --> 00:07:28,440 we don't need that state. So for example, we have learned 136 00:07:28,440 --> 00:07:32,440 that people always want to ask for user input during a tool 137 00:07:32,440 --> 00:07:35,080 call and never outside of that. And that's some of the things 138 00:07:35,080 --> 00:07:38,040 that we have learned and that learning over the years that has 139 00:07:38,040 --> 00:07:41,800 led to this like new stateless mode that we call like multi 140 00:07:41,800 --> 00:07:45,480 round trip responses, replies. And I think that's especially 141 00:07:45,480 --> 00:07:48,800 the thing fundamentally, there's still statefulness in agents, I 142 00:07:48,800 --> 00:07:50,680 think. I do like that you're starting 143 00:07:50,680 --> 00:07:54,840 to see the patterns and you're starting to help MCP protocol 144 00:07:55,400 --> 00:08:00,240 work together with the patterns, as opposed to all of us figure 145 00:08:00,240 --> 00:08:03,320 out how MCP works and then create patterns around it. 146 00:08:03,880 --> 00:08:06,360 Exactly. A second part of that learning, 147 00:08:06,360 --> 00:08:10,200 for example, is and we have learned that when you do need 148 00:08:10,400 --> 00:08:14,240 some form of session of like, oh, you will call, you know, you 149 00:08:14,240 --> 00:08:17,960 call the tool to add something to a basket, only then you have 150 00:08:17,960 --> 00:08:20,800 a new tool that has like a basket, you know, I don't know, 151 00:08:20,800 --> 00:08:24,640 list my basket or whatever. We have learned that nowadays a 152 00:08:24,640 --> 00:08:28,040 year and a half and part of that is the models just got better. 153 00:08:28,360 --> 00:08:32,960 We is that you can just give the model us like an ID that it just 154 00:08:32,960 --> 00:08:35,320 carries around between the tool calls. 155 00:08:35,320 --> 00:08:37,000 And so it's like an implicit session. 156 00:08:37,240 --> 00:08:39,760 You don't have to put it on the protocol level anymore because 157 00:08:39,760 --> 00:08:44,480 the the model will just perfectly happily take a like an 158 00:08:44,480 --> 00:08:47,680 ID that you give it and then move it into every other tool 159 00:08:47,680 --> 00:08:49,400 call. So you can piece them together 160 00:08:49,400 --> 00:08:53,040 that they belong to each other. And we have proven this was 161 00:08:53,040 --> 00:08:55,480 basically all major models and all of them do this now. 162 00:08:55,480 --> 00:08:59,200 Well, a year and a half ago, it would have been a very different 163 00:08:59,200 --> 00:09:01,280 story. So part of it is also that the 164 00:09:01,280 --> 00:09:04,360 models just get better. Yeah, and they're happy to carry 165 00:09:04,360 --> 00:09:06,240 that ID. Yeah, they're happy to carry 166 00:09:06,240 --> 00:09:09,480 that ID now, yeah. And that makes it much easier on 167 00:09:09,480 --> 00:09:11,480 your side. I can see how that will help 168 00:09:11,480 --> 00:09:14,880 with the the whole designing. You go, OK, well if this is true 169 00:09:14,880 --> 00:09:17,600 then that makes our lives a little bit easier and you feel 170 00:09:17,600 --> 00:09:20,040 more confident removing some of these pieces. 171 00:09:20,680 --> 00:09:23,880 Yeah, exactly. And now paint me the picture of 172 00:09:24,040 --> 00:09:31,440 someone who is currently using the MCP version and wants to go 173 00:09:31,440 --> 00:09:33,120 to the new version. What does that look like? 174 00:09:33,680 --> 00:09:37,560 Luckily it looks very, somewhat, very easy to you as long as you 175 00:09:37,560 --> 00:09:40,080 use one of the SDKS. So we put a lot of effort at the 176 00:09:40,080 --> 00:09:45,080 moment into changing the SDK such that the the lift is 177 00:09:45,520 --> 00:09:48,280 somewhat minimal, at least minimal with the help of a 178 00:09:48,280 --> 00:09:51,600 model. And they're the TypeScript SDK 179 00:09:51,600 --> 00:09:54,360 and the Python SDK, for example, they come out with a version 2 180 00:09:54,360 --> 00:09:57,520 that will support this. And the changes between version 181 00:09:57,520 --> 00:10:01,040 1 and version 2 are very easily done by like an Opus model or 182 00:10:01,040 --> 00:10:03,760 something like that. And so it's maybe a minor 183 00:10:03,760 --> 00:10:06,000 update, but it's not a hard lift. 184 00:10:06,000 --> 00:10:09,400 It's not a fundamental change. A lot of the hard pieces are 185 00:10:09,400 --> 00:10:16,080 abstracted away by by the SDKS if you're not. 186 00:10:16,160 --> 00:10:18,800 But if you're running your own SDK, the lift is significantly 187 00:10:18,800 --> 00:10:21,760 higher. And I would highly say suggest 188 00:10:21,760 --> 00:10:26,040 that you going to go and use some of the SDKS and all of 189 00:10:26,040 --> 00:10:29,040 these SDKS currently kind of work, work for version 2. 190 00:10:29,040 --> 00:10:31,840 I think the C# SDK also works towards the version 2. 191 00:10:32,360 --> 00:10:34,920 Not sure about the Go SDK. I think they stick to a want to 192 00:10:34,920 --> 00:10:39,840 still to that 10. But most of them again, have put 193 00:10:39,840 --> 00:10:43,440 a lot of thought and effort into making sure the upgrade is very, 194 00:10:43,440 --> 00:10:46,680 very minimal and basically one shot about with the model that 195 00:10:46,680 --> 00:10:49,840 was like the base requirement that it's not a hard lift. 196 00:10:49,840 --> 00:10:52,120 So it should be fairly easy. And then similarly, if you have 197 00:10:52,120 --> 00:10:57,280 existing soft, if you have existing servers, they should be 198 00:10:57,280 --> 00:11:00,480 able to, to, to continue to work, right? 199 00:11:00,480 --> 00:11:04,080 The protocol has versions. There's a, there's a lot of 200 00:11:04,080 --> 00:11:07,520 sessions and a lot of documentation and work in the 201 00:11:07,520 --> 00:11:14,000 SDKS to make sure they fall gracefully back to the version 202 00:11:14,000 --> 00:11:15,240 that your server is going to use. 203 00:11:15,240 --> 00:11:17,240 So it should just continue to to use. 204 00:11:18,280 --> 00:11:22,080 This can be in a way of forcing function to use those SDKS. 205 00:11:22,080 --> 00:11:26,440 If you had been thinking about bringing over some ideas and 206 00:11:26,440 --> 00:11:30,600 it's weekly, Yeah, just use it, make your life easier. 207 00:11:30,600 --> 00:11:36,320 You don't need to impress anyone, but exactly the other 208 00:11:36,320 --> 00:11:40,600 PSA is don't forget to pour everything to Rust before you 209 00:11:40,600 --> 00:11:42,840 change it to the SDK. But apparently. 210 00:11:44,160 --> 00:11:47,120 Always, always. Everything runs better after 211 00:11:47,120 --> 00:11:49,600 it's been ported to Rust, apparently from the. 212 00:11:49,600 --> 00:11:53,120 Research I but you just just give it to to Fable and it will 213 00:11:53,120 --> 00:11:54,720 just do all of it for you. Exactly. 214 00:11:55,520 --> 00:11:58,760 That's what I've heard, and it's so wild to think like, oh, take 215 00:11:58,760 --> 00:12:01,240 it, port it to Rust, and then you can port it back to the same 216 00:12:01,240 --> 00:12:02,880 language and it will perform better. 217 00:12:02,880 --> 00:12:06,280 So yeah, maybe. I don't know, I have to try. 218 00:12:06,520 --> 00:12:09,480 Yeah, yeah, there there's the rumor going around. 219 00:12:09,480 --> 00:12:13,840 So we need some hard details and science backed proof on this. 220 00:12:14,120 --> 00:12:17,680 But until I see that I'm still going to be perpetuating the 221 00:12:17,680 --> 00:12:21,960 rumor. Anyway, there's a few things 222 00:12:21,960 --> 00:12:27,000 that I want to go into that are more theoretical and less based 223 00:12:27,000 --> 00:12:30,080 in the protocol. And that's like what you've 224 00:12:30,080 --> 00:12:32,720 learned. You've been manning the ship and 225 00:12:32,720 --> 00:12:35,640 there's a great maintainer team that is also working on this, 226 00:12:35,640 --> 00:12:40,200 but there's a lot of precedence for open source projects over 227 00:12:40,200 --> 00:12:43,160 the years. Are there things that you feel 228 00:12:43,160 --> 00:12:49,920 like the MCP protocol can learn from all of our past open source 229 00:12:49,920 --> 00:12:52,440 winnings, and this one comes specifically, I asked the 230 00:12:52,440 --> 00:12:56,200 community for questions and we got some incredible questions. 231 00:12:56,200 --> 00:12:58,720 This one's coming from a question from the community. 232 00:12:58,920 --> 00:13:03,560 They're wondering like, what are you going to take from HTTP and 233 00:13:03,560 --> 00:13:06,400 all these other protocols that we've seen in the wild? 234 00:13:06,760 --> 00:13:09,320 I think there, I think there's always something to learn. 235 00:13:09,320 --> 00:13:13,160 I think you can always take a look and sometimes you learn 236 00:13:13,560 --> 00:13:16,200 things you want to repeat and sometimes you learn things you 237 00:13:16,200 --> 00:13:18,560 do not want to repeat. Well, they don't apply to you. 238 00:13:19,200 --> 00:13:21,000 It's less often that they're wrong. 239 00:13:21,000 --> 00:13:22,760 It's mostly that they might not apply to you. 240 00:13:22,760 --> 00:13:26,800 And so they're, I think there's a few things. 241 00:13:26,800 --> 00:13:30,960 The, the first thing is on the standards, some of the big 242 00:13:30,960 --> 00:13:34,440 challenges is the, the standards, most successful 243 00:13:34,440 --> 00:13:40,040 standards work in a way that they take a long time to be 244 00:13:40,040 --> 00:13:42,960 billed and they're mostly consensus driven. 245 00:13:42,960 --> 00:13:47,480 That's like HTTP, some of that, a lot of the authorization work 246 00:13:48,040 --> 00:13:50,560 things that come out of the ITF in general, for example, are 247 00:13:50,560 --> 00:13:54,360 very consensus based. Consensus based mechanisms are 248 00:13:54,640 --> 00:14:00,600 very, very slow. They they take a long time, but 249 00:14:00,600 --> 00:14:04,320 at the same time they often, depending how you do it, they 250 00:14:04,320 --> 00:14:08,560 result in usually solutions that are quite good. 251 00:14:08,560 --> 00:14:10,720 They're not perfect, but they're quite good. 252 00:14:11,800 --> 00:14:18,560 HTP 1.1, HP 10, interesting enough, did not work well. 1.1 253 00:14:18,560 --> 00:14:20,520 is the one everyone's using, right? 254 00:14:20,520 --> 00:14:24,440 And I think we keep forgetting that quickly. 2.0 is also quite 255 00:14:24,440 --> 00:14:27,160 well done. But then even they already had 256 00:14:27,160 --> 00:14:29,600 shortcut Cummings and now they're three, right? 257 00:14:29,920 --> 00:14:34,920 And you can learn some of the carefulness and considerations 258 00:14:34,920 --> 00:14:38,360 and being sometimes more on the conservative side and saying no 259 00:14:38,360 --> 00:14:42,240 to things because you know that two things can happen. 260 00:14:42,240 --> 00:14:45,400 First of all, you can change things and add things later 261 00:14:45,880 --> 00:14:48,040 that's happened to, you know, HTTP 1.1. 262 00:14:48,280 --> 00:14:52,360 I'm sure during the process of HTTP, two people have known that 263 00:14:52,360 --> 00:14:54,760 they will be shortcomings that they are currently putting into 264 00:14:54,760 --> 00:14:59,120 the protocol and yet they continue because it is good 265 00:14:59,120 --> 00:15:03,200 enough and it is within the time frame that they have and they 266 00:15:03,200 --> 00:15:06,440 know the version 3 periods later might, might change it. 267 00:15:06,440 --> 00:15:09,440 And that's OK. Standards are not there to solve 268 00:15:09,440 --> 00:15:11,920 everything. That's they're there to solve 269 00:15:11,920 --> 00:15:15,560 most problems. And so I think there's a lot of 270 00:15:15,560 --> 00:15:18,080 lessons to learn in that regard. There's a lot of lessons to 271 00:15:18,080 --> 00:15:20,400 learn in like how you run a successful open source project 272 00:15:20,400 --> 00:15:23,080 and like in a governance and like a general sense. 273 00:15:23,080 --> 00:15:25,240 And there are many, many ways to do this. 274 00:15:25,240 --> 00:15:29,120 You can run it in a BDFL style like like the Linux project. 275 00:15:29,120 --> 00:15:32,280 You can run it in a steering committee style like the Python 276 00:15:32,280 --> 00:15:33,800 community. And they all have their 277 00:15:33,800 --> 00:15:37,560 drawbacks and benefits. And I think what we have learned 278 00:15:37,560 --> 00:15:42,480 here is that I think for us like having a strong core to maintain 279 00:15:42,480 --> 00:15:45,520 our foundation. So a set of like a more of a 280 00:15:45,520 --> 00:15:50,520 steering committee type and plus the BDFL on top has worked for 281 00:15:50,520 --> 00:15:54,280 the most part quite well. I think there's things that we 282 00:15:54,280 --> 00:15:57,800 will change this year to make it even more democratic and allow 283 00:15:57,800 --> 00:16:02,040 more as the project is maturing and the structures of maturing 284 00:16:02,360 --> 00:16:07,680 and like being able to be a bit more, be even a bit more 285 00:16:07,680 --> 00:16:10,000 democratic. So it's always like a matter of 286 00:16:10,000 --> 00:16:12,960 like you look at these projects and like, okay, you know, an ITF 287 00:16:12,960 --> 00:16:16,960 project chooses democracy over everything else and consensus. 288 00:16:16,960 --> 00:16:22,280 And as a result, it's slow. A project like, I know, take 289 00:16:22,280 --> 00:16:25,960 something like and like a like a famous new open source project 290 00:16:25,960 --> 00:16:28,920 like Ghosty, like with a, with a clear one leading person was 291 00:16:28,920 --> 00:16:31,240 Mitchell, right? He's very fast and in certain 292 00:16:31,240 --> 00:16:33,480 ways because of just one person making a decision, right. 293 00:16:34,200 --> 00:16:36,280 And then there are mixes like the Python projects and you 294 00:16:36,280 --> 00:16:38,640 choose the thing for the stage you're in. 295 00:16:38,720 --> 00:16:41,600 And I think that's the, there's a good lesson to be learnt 296 00:16:41,600 --> 00:16:43,800 there. And so for us, the interesting 297 00:16:43,800 --> 00:16:46,720 part is finding that middle ground of like, we want to be 298 00:16:46,720 --> 00:16:48,400 fast. We want to be somewhat 299 00:16:48,400 --> 00:16:50,400 democratic, but we will also want to move. 300 00:16:50,400 --> 00:16:54,400 We also want to be considerate and be somewhat conservative, 301 00:16:54,680 --> 00:16:58,360 but at the same time, you know, we also work in a, in a, in a 302 00:16:58,360 --> 00:17:00,160 slightly different environment because we're working in 303 00:17:00,160 --> 00:17:03,600 software where things can change quicker. 304 00:17:03,600 --> 00:17:06,480 And for example, if you like pre creating like a hardware 305 00:17:06,480 --> 00:17:09,560 standard or a telecommunications standard where someone puts the 306 00:17:09,560 --> 00:17:13,880 standard on software onto a box, puts the box 200 kilometers into 307 00:17:13,880 --> 00:17:16,160 the north of Sweden and it's going to sit there for the next 308 00:17:16,160 --> 00:17:18,760 10 years, you have a very different set of problems than 309 00:17:18,760 --> 00:17:23,359 if you build MCP, for example. I like that juxtaposition 310 00:17:24,000 --> 00:17:28,200 because in the real world, yeah, the atoms take a whole different 311 00:17:28,200 --> 00:17:31,440 route for the standards. And it also is cool to hear you 312 00:17:31,440 --> 00:17:36,680 say like, you're choosing this path right now because it is 313 00:17:36,680 --> 00:17:38,640 what you feel the most optimal route. 314 00:17:38,640 --> 00:17:44,160 But in the future, once things stabilize even more than they 315 00:17:44,160 --> 00:17:47,680 already are, you're open to taking on new ways and trying 316 00:17:47,680 --> 00:17:49,320 those out and seeing like a new pair of pants. 317 00:17:49,320 --> 00:17:50,840 Do they fit? Do they do they look good in 318 00:17:50,840 --> 00:17:51,680 them? All right, cool. 319 00:17:52,600 --> 00:17:56,040 I, I, I have a very clear picture in my mind of like where 320 00:17:56,040 --> 00:17:58,520 this going to go in a year or two years and how this needs to 321 00:17:58,560 --> 00:18:00,760 evolve on a governing perspective. 322 00:18:00,880 --> 00:18:04,600 Because it's pretty clear that I think this model is, it's is a 323 00:18:04,680 --> 00:18:08,480 is a temporary artefact in time for the current situation the 324 00:18:08,480 --> 00:18:11,560 protocol is in. But that will not be the 325 00:18:11,560 --> 00:18:14,000 situation of protocol as in a year from now and then. 326 00:18:14,000 --> 00:18:15,320 It requires different governance. 327 00:18:16,200 --> 00:18:18,080 And I did want to hit on something else that you 328 00:18:18,080 --> 00:18:22,840 mentioned, which I have found to be true, especially back in the 329 00:18:23,040 --> 00:18:27,400 ML OPS days, is the sooner you can get something out there and 330 00:18:27,400 --> 00:18:31,640 get folks using it and testing it, the sooner you can realize 331 00:18:31,640 --> 00:18:33,760 where you had gaps in your thinking. 332 00:18:34,480 --> 00:18:39,600 And so it is like that speed that you're looking for is a 333 00:18:39,600 --> 00:18:41,880 feature, not necessarily a bug in that regard. 334 00:18:42,320 --> 00:18:45,760 That makes sense. I I agree with some constraints, 335 00:18:45,760 --> 00:18:47,200 right? The constraint is like how 336 00:18:47,200 --> 00:18:50,520 flexible is the environment. And again, I think the 337 00:18:50,520 --> 00:18:54,560 environment in which MCP is at is exceptionally flexible 338 00:18:54,560 --> 00:18:57,800 because people around AI do two things. 339 00:18:58,000 --> 00:19:01,840 They first of all, assume an exceptionally high velocity of 340 00:19:01,840 --> 00:19:06,160 change and they're using models that help them to retain that 341 00:19:06,160 --> 00:19:09,640 high velocity. So some of the burdensome work 342 00:19:09,880 --> 00:19:14,120 is less burden burdensome. And so those are things that are 343 00:19:14,680 --> 00:19:17,520 cultural pieces that you need to take into account when you 344 00:19:17,520 --> 00:19:20,920 design the, the speed that you're you're going at. 345 00:19:21,240 --> 00:19:25,400 And this is, for example, not true for programming languages 346 00:19:25,400 --> 00:19:29,000 per SE. In programming languages you 347 00:19:29,000 --> 00:19:31,360 know, particularly older programming languages or certain 348 00:19:31,360 --> 00:19:35,200 niche programming languages, you might have less adoption of AI 349 00:19:35,200 --> 00:19:39,840 or you might have, you might not want to change your code 350 00:19:39,840 --> 00:19:45,280 constantly because of changes and because you just want to get 351 00:19:45,280 --> 00:19:50,120 stuff done. And so there's, there's 352 00:19:50,120 --> 00:19:52,080 carefulness to be considered here. 353 00:19:52,320 --> 00:19:54,640 And even we, I think, have limits, right? 354 00:19:54,640 --> 00:19:57,680 Like when we did the protocol changes and now what we're 355 00:19:57,680 --> 00:20:00,760 doing, the SDK changes in particular, we're paying a lot 356 00:20:00,760 --> 00:20:05,400 of attention that the delta is small enough to be done because 357 00:20:05,400 --> 00:20:10,840 we don't want to jump into the problems that let's say like a 358 00:20:10,840 --> 00:20:15,760 Python 2 to Python 3. Change had or there's there's 359 00:20:15,800 --> 00:20:20,120 other aspects or in IPV 4 or IPV 6, there's a bunch of these type 360 00:20:20,120 --> 00:20:24,040 of things where they are very cumbersome and difficult to do 361 00:20:24,040 --> 00:20:27,960 and you need to be careful that the delta is small enough that 362 00:20:28,080 --> 00:20:31,240 that the net benefit outweighs the friction. 363 00:20:31,400 --> 00:20:35,400 Are there breaking changes that you feel like may happen in the 364 00:20:35,400 --> 00:20:37,440 future? I never know. 365 00:20:37,440 --> 00:20:40,520 I think we are getting into a shape where it's a lot of the 366 00:20:40,520 --> 00:20:43,880 things are additive. The the problem at the moment, I 367 00:20:43,880 --> 00:20:46,560 think we're going to see now is that the complexity of the 368 00:20:46,560 --> 00:20:51,120 protocol will increase. And by virtue of we're trying to 369 00:20:52,240 --> 00:20:55,880 we're probably at like an 80% solution space like 8020 where 370 00:20:55,880 --> 00:20:59,680 80% of the problems people have in that space of soft and 20% 371 00:20:59,680 --> 00:21:01,640 are not. And if you, it turns out if you 372 00:21:01,640 --> 00:21:04,680 push the boundary beyond these 80%, the last 20% are actually 373 00:21:04,680 --> 00:21:08,080 like 80, like 80% more complexity added, right And so. 374 00:21:08,080 --> 00:21:10,640 80 times it's. Disproportionately more 375 00:21:10,640 --> 00:21:13,200 complexity, right? We're adding caching, we're 376 00:21:13,200 --> 00:21:15,960 adding caching scopes, things that look very similar to things 377 00:21:15,960 --> 00:21:19,200 that exist in HTTP, at which point you need to ask yourself, 378 00:21:19,200 --> 00:21:21,960 OK, at which point you're just going to rely on HTTP, right? 379 00:21:22,320 --> 00:21:25,000 And, and we have made some choices a year and a half ago 380 00:21:25,000 --> 00:21:26,200 that make this a bit more tricky. 381 00:21:26,200 --> 00:21:30,000 And so there are there are decisions to be made down the 382 00:21:30,000 --> 00:21:33,600 road, but most importantly, it is it means added complexity. 383 00:21:33,800 --> 00:21:37,240 When we originally designed the protocol, we were mostly 384 00:21:37,240 --> 00:21:40,440 concerned and mostly obsessed with adoption because that's the 385 00:21:40,440 --> 00:21:42,280 thing that makes or breaks the protocol. 386 00:21:42,600 --> 00:21:45,640 And the key principle for the very first version of the first 387 00:21:45,800 --> 00:21:50,320 six months of MCP was that it's very simple to implement to the 388 00:21:50,320 --> 00:21:55,040 point where we constantly tested that if you just give it an SDK 389 00:21:55,080 --> 00:21:58,960 or if you just give it even the specification, a model will 390 00:21:58,960 --> 00:22:01,440 write you happily an SDK in that language. 391 00:22:01,880 --> 00:22:04,840 I mean, that was true 6 done in the first six months. 392 00:22:04,840 --> 00:22:07,800 I don't think that is necessarily true anymore because 393 00:22:07,800 --> 00:22:11,520 the complexity has increased. But that's OK because now we're 394 00:22:11,520 --> 00:22:13,040 in a different state. Now we're in a state where 395 00:22:13,040 --> 00:22:16,520 people rely on the SDKS, where the SDKS have hundreds of 396 00:22:16,520 --> 00:22:21,760 millions of downloads a year or a month, and that gives us a 397 00:22:21,760 --> 00:22:24,920 different lever that we didn't have 12 months ago. 398 00:22:24,920 --> 00:22:27,600 And you need to be aware of these and then use them to your 399 00:22:27,600 --> 00:22:30,560 advantage and may and be mindful around the limitation. 400 00:22:30,560 --> 00:22:32,440 Hundreds of millions of downloads a month. 401 00:22:32,440 --> 00:22:36,240 There is unreal just as a stat that you kind of glossed over. 402 00:22:36,600 --> 00:22:43,320 And that is a great segue into I think this philosophical battle 403 00:22:43,320 --> 00:22:47,640 that I'm sure your going through day by day as you're looking at 404 00:22:47,640 --> 00:22:50,680 what to add as an extension versus bring on as a core. 405 00:22:50,680 --> 00:22:53,760 And one of the questions that the community asked me too to 406 00:22:53,760 --> 00:22:59,240 ask you, well it comes from Manvika and she was asking where 407 00:22:59,240 --> 00:23:02,320 do you draw the line between something that is core versus 408 00:23:02,320 --> 00:23:06,720 extension, especially with the idea of simplicity in like that 409 00:23:06,720 --> 00:23:10,800 you want to touch on? There's a few things I think. 410 00:23:10,800 --> 00:23:12,000 I think it's a very good question. 411 00:23:12,680 --> 00:23:16,760 It's an aspect that we very rarely explain, but I think like 412 00:23:17,000 --> 00:23:19,880 there's some very thought, there's some thoughtful thinking 413 00:23:19,880 --> 00:23:23,160 behind this. What the, the, the principle 414 00:23:23,160 --> 00:23:27,440 that need to apply to core are it needs to be composable. 415 00:23:28,120 --> 00:23:32,840 It needs to be so that for example, like a, a resource in 416 00:23:32,840 --> 00:23:37,360 MCP is a fairly general like remote file system approach that 417 00:23:37,480 --> 00:23:42,160 perfectly composes nicely with tools as an execution approach 418 00:23:42,560 --> 00:23:45,480 and so on. Then that's one aspect of that. 419 00:23:45,480 --> 00:23:49,520 The second aspect of that is it needs to solve like serve all 420 00:23:49,520 --> 00:23:52,040 clients and all servers at the same time. 421 00:23:52,400 --> 00:23:57,240 I give you an example. MCP apps is a great thing, but 422 00:23:57,240 --> 00:24:01,040 it only works in surfaces that I have browser, a browser 423 00:24:01,040 --> 00:24:03,800 rendering in it, which is very constrained, right? 424 00:24:03,840 --> 00:24:07,400 Because it an MCP app renders HTML, right? 425 00:24:07,720 --> 00:24:11,720 And so a terminal will never be able to and look at an MCP app 426 00:24:11,960 --> 00:24:15,280 and that's OK, but it means that it's not part of core because 427 00:24:15,280 --> 00:24:19,320 you're leaving out a large chunk of the MCP client clients out 428 00:24:19,320 --> 00:24:21,200 there. And so there's these kind of 429 00:24:21,200 --> 00:24:25,760 consideration that we are having that is, that is for what 430 00:24:25,760 --> 00:24:28,520 belongs in the core. The second thing that belongs in 431 00:24:28,520 --> 00:24:34,480 the core is concepts that we are very confident will stay very 432 00:24:34,480 --> 00:24:37,840 stable. So one of the best example of 433 00:24:37,840 --> 00:24:41,600 this is where we maybe made a, maybe not a mistake, but like we 434 00:24:41,600 --> 00:24:46,680 were, it was a sequencing issue. It's MCP tasks, MTP tasks is 435 00:24:46,680 --> 00:24:50,000 this idea of long running tasks for long running tool calls, 436 00:24:50,400 --> 00:24:53,240 which allows you effectively to do agent to agent communication 437 00:24:53,240 --> 00:24:55,640 over MCP, which I think is a massive unlock. 438 00:24:55,640 --> 00:24:59,840 I think it's a huge thing that will be super good, super widely 439 00:24:59,840 --> 00:25:03,200 used in the long run. And we'll have actually in the 440 00:25:03,200 --> 00:25:04,640 long run a lot of client support. 441 00:25:04,960 --> 00:25:09,280 But the first iteration of it had issues and it was part of 442 00:25:09,280 --> 00:25:11,680 the as an experimental change, the core. 443 00:25:12,000 --> 00:25:15,720 And it turned out we were much better separating it from the 444 00:25:15,720 --> 00:25:19,200 core into its own extension where it can be developed at its 445 00:25:19,200 --> 00:25:23,960 own pace independently from the release cycle of the core in 446 00:25:23,960 --> 00:25:26,360 there. Like basically iterates fast 447 00:25:26,360 --> 00:25:29,120 enough to the point where we are back being able to move it into 448 00:25:29,120 --> 00:25:32,960 the core because then we have confidence that it works the way 449 00:25:32,960 --> 00:25:35,720 it works. And the extension is already the 450 00:25:35,720 --> 00:25:41,360 now MCP task extension is significantly different from the 451 00:25:41,360 --> 00:25:45,800 original experimental core piece that we have now moved out. 452 00:25:46,360 --> 00:25:49,280 And so we want to basically just like let it cook, like let it 453 00:25:49,280 --> 00:25:52,760 cook in the extension space, let it let people iterate, let 454 00:25:52,760 --> 00:25:55,880 people play around with it. And once we were confidence in 455 00:25:55,880 --> 00:25:58,360 the design, we've got to put it back into the core because that 456 00:25:58,360 --> 00:26:03,240 is one of the pieces that does fit nicely into the like, 457 00:26:03,960 --> 00:26:06,760 compose like it composes nicely with the rest of their the 458 00:26:06,760 --> 00:26:08,560 primitives. Do you feel like that's a nice 459 00:26:08,560 --> 00:26:11,840 pattern? Let it be an extension, kind of 460 00:26:11,840 --> 00:26:16,520 prove out its value, and then merge it into core. 461 00:26:16,760 --> 00:26:19,000 Do you see that? Being potential core pieces, yes 462 00:26:19,000 --> 00:26:24,240 there are pieces like MCP apps or skills of MCP that will 463 00:26:24,240 --> 00:26:25,600 always stay extension. Yeah. 464 00:26:25,800 --> 00:26:28,600 But then there's other pieces that potentially could be core, 465 00:26:28,600 --> 00:26:34,680 but instead of doing it like you did with tasks, you can let it 466 00:26:34,680 --> 00:26:37,400 stand on its own 2 legs 1st and then go. 467 00:26:38,960 --> 00:26:43,080 That makes a ton of sense. So I want to go into a few more 468 00:26:43,080 --> 00:26:44,560 of these questions that are coming through. 469 00:26:44,560 --> 00:26:49,560 By far, the most asked question is about the progressive 470 00:26:49,560 --> 00:26:51,520 disclosure. Can you talk to us a bit about 471 00:26:51,520 --> 00:26:53,440 that? Yeah, progressive disclosure I 472 00:26:53,440 --> 00:26:56,720 think is an interesting case. So what people, and I'm curious 473 00:26:56,720 --> 00:26:58,960 what your take is, what people actually mean by that, because 474 00:26:58,960 --> 00:27:02,120 that first and foremost is like, what do people, what do people 475 00:27:02,120 --> 00:27:03,920 actually think about what, what does this mean? 476 00:27:05,080 --> 00:27:08,920 Progressive disclosure. Most of the time I've seen it 477 00:27:08,920 --> 00:27:13,960 being mentioned, it refers to this notion of making sure that 478 00:27:13,960 --> 00:27:18,440 the model learns about specific of a tool only when it needs it. 479 00:27:18,800 --> 00:27:25,160 Because otherwise if you put all the tools into into the context 480 00:27:25,160 --> 00:27:27,960 window, you get context bloat very quickly. 481 00:27:28,360 --> 00:27:32,040 And so it's, it's less that the people are worried about like 482 00:27:32,040 --> 00:27:34,720 the one progressive disclosure. They just think it's one 483 00:27:34,720 --> 00:27:36,560 solution to the problem of context bloat. 484 00:27:36,560 --> 00:27:39,200 Exactly. I wholeheartedly agree with 485 00:27:39,200 --> 00:27:40,200 that. Right. 486 00:27:40,720 --> 00:27:48,360 And so context bloat is context bloat is a, is a, in my mind an 487 00:27:48,360 --> 00:27:52,400 interesting problem because there's a separation in my mind, 488 00:27:52,400 --> 00:27:55,560 what does the protocol do versus what does the client do. 489 00:27:56,000 --> 00:27:58,120 The protocol transports information. 490 00:27:58,120 --> 00:28:00,760 It transports information about the tools available. 491 00:28:01,360 --> 00:28:05,240 The problem we have seen is that naively most client implementers 492 00:28:05,560 --> 00:28:08,960 take whatever comes over the protocol and just slap it into 493 00:28:08,960 --> 00:28:15,240 the context window. And that is not necessarily at 494 00:28:15,240 --> 00:28:18,160 the right approach. What you should do is you take 495 00:28:18,160 --> 00:28:22,520 the protocol as an informative piece of like these are the 496 00:28:22,640 --> 00:28:26,840 tools available, but I then choose techniques on my side, on 497 00:28:26,840 --> 00:28:31,880 the client side that are avoiding this context bloat and 498 00:28:31,880 --> 00:28:34,680 the two mechanisms that we found exceptionally useful and 499 00:28:34,680 --> 00:28:38,760 basically use everywhere Cloud code does this and basically all 500 00:28:39,600 --> 00:28:42,720 anthropic products do this is using tool search. 501 00:28:42,720 --> 00:28:46,440 So like instead of putting the tools into the context window 502 00:28:46,440 --> 00:28:51,880 right away, we are, we are putting it into effectively an 503 00:28:51,880 --> 00:28:55,920 index. And the model has trained, it's 504 00:28:55,920 --> 00:28:59,640 been trained to like search for certain tools when it thinks it 505 00:28:59,640 --> 00:29:03,320 probably needs a tool. And that works quite well. 506 00:29:04,640 --> 00:29:08,080 And it basically reduces your token usage as you would expect, 507 00:29:08,080 --> 00:29:09,640 right? It's the exact, it's basically 508 00:29:09,640 --> 00:29:12,960 effectively some form of progressive disclosure or 509 00:29:12,960 --> 00:29:16,360 discovery from the model side. The second part of that is 510 00:29:16,360 --> 00:29:19,240 programmatic tool calling, which is like how you combine or 511 00:29:19,240 --> 00:29:23,600 compose tools together. Normally the traditional old 512 00:29:23,600 --> 00:29:26,760 school way is the model runs inference, it spits something 513 00:29:26,760 --> 00:29:28,640 out, it tells you to recall a tool. 514 00:29:28,640 --> 00:29:31,560 You write, you call the tool, you give back the true results 515 00:29:31,560 --> 00:29:33,920 to the model. Now the model says, oh, thank 516 00:29:33,920 --> 00:29:35,960 you for the input. I'll call this other tool. 517 00:29:36,200 --> 00:29:38,080 And So what the model effectively doing is it's 518 00:29:38,080 --> 00:29:42,080 composing tools together in a quite inefficient manner because 519 00:29:42,080 --> 00:29:44,240 it doesn't bear inference. And what you can do instead is 520 00:29:44,240 --> 00:29:48,480 you can have the model optimistically write a piece of 521 00:29:48,480 --> 00:29:52,760 code that says, take this now a JavaScript block that says call 522 00:29:52,760 --> 00:29:55,200 this tool, take the output, parse it into Jason, put this 523 00:29:55,200 --> 00:29:57,200 over there into this other tool, and then give me the output, 524 00:29:57,200 --> 00:29:58,880 right? And so you have two tool calls 525 00:29:59,240 --> 00:30:01,200 put together in a script and you execute that. 526 00:30:01,560 --> 00:30:05,480 And that saves tools as well. And these two things to combine 527 00:30:06,000 --> 00:30:09,080 are very, very, very effective like tool search plus and 528 00:30:09,080 --> 00:30:13,440 programmatic tool calling to basically get rid of tool to 529 00:30:13,760 --> 00:30:17,040 bloat. And so that's a long winded way 530 00:30:17,040 --> 00:30:21,960 to say that I think 80% of the problems are client implemented 531 00:30:21,960 --> 00:30:25,320 problems that they're not doing a good enough job skills issue. 532 00:30:25,320 --> 00:30:28,240 That being said, I think there is an argument that we're slowly 533 00:30:28,240 --> 00:30:31,880 coming around where it might be useful in certain situations 534 00:30:31,880 --> 00:30:35,760 where the server offers, where the server authors knows better 535 00:30:35,760 --> 00:30:39,200 about the shape of the problem. So it might wanna offer some 536 00:30:39,200 --> 00:30:43,480 form of search or some form of progressive discovery, our 537 00:30:43,480 --> 00:30:45,480 disclosure. And so we're thinking about some 538 00:30:45,480 --> 00:30:49,840 of the primitives, but fundamentally it's to some 539 00:30:49,840 --> 00:30:54,920 degree a client problem. Very proud of myself because in 540 00:30:54,920 --> 00:30:57,240 my head, that's kind of what I was thinking. 541 00:30:57,240 --> 00:30:59,600 I especially on those two where it's like, yeah, well, tool 542 00:30:59,600 --> 00:31:02,600 search, I think Cloudflare was the first to popularize that, 543 00:31:02,600 --> 00:31:04,040 right? I can't remember who. 544 00:31:04,080 --> 00:31:07,440 Exactly, they did something called code mode which is what 545 00:31:07,440 --> 00:31:11,560 the other word for programmatic. We did it around the same time I 546 00:31:11,560 --> 00:31:14,000 think Cloudflare did the popular blog post about it. 547 00:31:14,040 --> 00:31:17,640 Yeah, I knew one of those. I remember seeing that and 548 00:31:17,640 --> 00:31:19,400 thinking, yeah, that makes sense, right? 549 00:31:19,400 --> 00:31:22,400 And especially because I had been hearing murmurs in the 550 00:31:22,400 --> 00:31:25,560 community of folks saying, well, you want to just bring the 551 00:31:25,560 --> 00:31:29,720 abstraction layer up So you don't give them 90 tools and say 552 00:31:29,720 --> 00:31:33,000 here is get Slack ID, here is send Slack message. 553 00:31:33,000 --> 00:31:36,160 It's like you want to just figure out what's the intent and 554 00:31:36,160 --> 00:31:41,680 create that from the intent as opposed to a million tools. 555 00:31:41,680 --> 00:31:43,480 And then you got to choose one by one. 556 00:31:43,600 --> 00:31:45,680 You have one tool that can cascade down. 557 00:31:45,920 --> 00:31:50,200 And the search is, it's kind of obvious because that in a way is 558 00:31:50,200 --> 00:31:54,160 very much progressive disclosure, just a different way 559 00:31:54,160 --> 00:31:55,840 of doing progressive disclosure, right? 560 00:31:56,160 --> 00:31:59,920 And we have seen, without going into too much details, we have, 561 00:31:59,920 --> 00:32:04,240 we have seen a tool search plus programmatic tool calling can be 562 00:32:04,240 --> 00:32:07,240 as good if not even better than for example, CLIS. 563 00:32:07,360 --> 00:32:10,160 Yeah, I believe it. I believe it 100%. 564 00:32:10,160 --> 00:32:15,800 And you know, I think the reason that folks felt like they were 565 00:32:15,800 --> 00:32:18,920 getting this bloat in the beginning was because there was 566 00:32:19,400 --> 00:32:24,800 so many community built servers that just went up so fast and 567 00:32:24,840 --> 00:32:28,000 you would go and try and use them, but it was, they were 568 00:32:28,000 --> 00:32:32,920 built so poorly without any idea of how to do any of this. 569 00:32:32,920 --> 00:32:35,520 And so again, it goes back to that maturity. 570 00:32:35,600 --> 00:32:40,560 If I used an MCP server that was built poorly back in the day, of 571 00:32:40,560 --> 00:32:41,640 course I'm going to be complaining. 572 00:32:41,640 --> 00:32:44,880 And GitHub was the notorious one who did this the worst because 573 00:32:44,880 --> 00:32:47,480 they just threw all the tools into the and it was. 574 00:32:47,680 --> 00:32:50,320 So that was what you're saying? Yeah. 575 00:32:50,400 --> 00:32:54,680 And then part of that is like the the classic is like take an 576 00:32:54,680 --> 00:32:57,840 open API spec and like transport it like transform it one to one 577 00:32:57,840 --> 00:33:00,400 to MCP. And that's that's fundamentally 578 00:33:00,400 --> 00:33:05,080 an anti pattern because it just leads to poor and to to very 579 00:33:05,080 --> 00:33:08,480 poorly performing MCP servers that also have the problem that 580 00:33:08,480 --> 00:33:10,840 the tools look similar enough that the model gets very easily 581 00:33:10,840 --> 00:33:12,960 very confused about which tool to use. 582 00:33:12,960 --> 00:33:16,080 So it's a bit of a, it's a bit of a you 100% right. 583 00:33:16,080 --> 00:33:19,400 Like they're it was amplified by poor servers. 584 00:33:19,760 --> 00:33:22,040 It was mostly amplified by poor client, yeah. 585 00:33:22,680 --> 00:33:26,360 Yeah, it got it. You just didn't realize it until 586 00:33:26,360 --> 00:33:28,360 later that, oh, this is a skills issue. 587 00:33:28,600 --> 00:33:31,800 This is not the protocol necessarily that's causing these 588 00:33:31,800 --> 00:33:33,960 problems. It's just that folks who didn't 589 00:33:33,960 --> 00:33:37,760 really go deep into the protocol and figure out how to build it 590 00:33:37,880 --> 00:33:41,120 properly or leverage what is there like this search. 591 00:33:41,200 --> 00:33:44,120 And part of it is also learning honestly, like everybody learns 592 00:33:44,120 --> 00:33:46,320 on it, right? Like when MCP came out, like how 593 00:33:46,320 --> 00:33:48,840 many tools would you where you're using in a session like 594 00:33:48,840 --> 00:33:51,680 10, right? Six months later, 12 months 595 00:33:51,680 --> 00:33:55,840 later, MCP led to pro to a proliferation in the ecosystem, 596 00:33:55,840 --> 00:33:58,240 right? And so some of the solutions are 597 00:33:58,240 --> 00:34:02,520 needed because of MCP being part of the amplifier of tools. 598 00:34:02,880 --> 00:34:05,000 And so it's a bit of a chicken egg type of problems. 599 00:34:05,000 --> 00:34:06,040 I'm not worried. I'm not. 600 00:34:06,400 --> 00:34:08,719 I don't. I'm less worried about that. 601 00:34:08,719 --> 00:34:11,280 I think the client author didn't do it right from the beginning. 602 00:34:11,280 --> 00:34:13,239 Completely normal. We all learn, we all do 603 00:34:13,280 --> 00:34:17,000 iterative work. I think what I'm what I want to 604 00:34:17,000 --> 00:34:19,080 make sure is I think a lot of people don't realize that the 605 00:34:19,080 --> 00:34:21,679 situation gets significantly better and most clients don't 606 00:34:21,679 --> 00:34:23,920 have this issue. At least most major clients 607 00:34:24,320 --> 00:34:26,800 don't have this issue anymore. Speaking of which, we talk a lot 608 00:34:26,800 --> 00:34:29,760 about like this forward compatibility. 609 00:34:29,760 --> 00:34:32,000 You know, in software you have backwards compatibility. 610 00:34:32,000 --> 00:34:35,760 That's a thing, obviously, but I've heard people talk about 611 00:34:35,760 --> 00:34:39,000 forward compatibility, especially as you're building 612 00:34:39,000 --> 00:34:42,840 and knowing, all right, there's certain things that I can build 613 00:34:42,840 --> 00:34:46,679 this right now or I can wait six months and the models probably 614 00:34:46,679 --> 00:34:48,080 going to be able to do it on its own. 615 00:34:48,440 --> 00:34:52,719 And the classic examples of this are back in the day when folks 616 00:34:52,719 --> 00:34:55,840 would try and do all these hacky moves to make the context window 617 00:34:55,840 --> 00:35:00,120 bigger. Or I know people in certain 618 00:35:00,120 --> 00:35:02,440 e-commerce stores who built their own MCP because they 619 00:35:02,440 --> 00:35:04,240 didn't have that. And it's like, wow, if you just 620 00:35:04,240 --> 00:35:07,800 waited a few months, MCP came out, it became popular. 621 00:35:08,160 --> 00:35:14,160 So as you're looking at ways that things could now be forward 622 00:35:14,160 --> 00:35:16,760 compatible, or as you're thinking through like what's 623 00:35:16,760 --> 00:35:22,560 going to get better, where do you plan on, OK, this can get 624 00:35:22,560 --> 00:35:24,120 better. Maybe you can build it right 625 00:35:24,120 --> 00:35:27,480 now, or maybe you can wait six months, and at the rate of 626 00:35:27,480 --> 00:35:31,600 change, it wouldn't be a far stretch to say that this is 627 00:35:31,600 --> 00:35:34,040 going to be done. It's such a good question. 628 00:35:34,040 --> 00:35:36,480 I think there's a lot of these kind of scenarios where you need 629 00:35:36,480 --> 00:35:38,640 to be so careful and some of them you will get right, some of 630 00:35:38,640 --> 00:35:41,800 them you will get wrong, right. And like the session piece, we 631 00:35:41,800 --> 00:35:44,760 kind of got wrong, I guess in retrospective, right, or there 632 00:35:44,760 --> 00:35:47,960 was a temporary thing. But another example is like, 633 00:35:47,960 --> 00:35:50,320 people often ask us to do something what we, what they 634 00:35:50,320 --> 00:35:53,640 originally called primitive grouping, which is like ADC, 635 00:35:54,000 --> 00:35:56,800 allow tools to be grouped, right? 636 00:35:57,440 --> 00:36:00,320 And that's super sensible. It's a very good use case. 637 00:36:00,320 --> 00:36:02,240 There's a lot of use cases around this. 638 00:36:02,520 --> 00:36:06,520 But if you think forward, you're like, OK, first of all, there's 639 00:36:06,520 --> 00:36:07,960 two things to this. First of all, the models would 640 00:36:07,960 --> 00:36:12,080 get really good and people will not select tools as a group in a 641 00:36:12,600 --> 00:36:15,440 session anymore. Six months ago, 12 months ago, 642 00:36:15,840 --> 00:36:19,160 you have to select tools in, you know, UI. 643 00:36:19,160 --> 00:36:21,560 Nobody does this anymore. Nobody expects us to do this 644 00:36:21,560 --> 00:36:23,400 anymore. And so these things will just go 645 00:36:23,400 --> 00:36:26,080 away to some degree, right. At the same time, the models 646 00:36:26,080 --> 00:36:28,840 will get better to reason based on the tool description about 647 00:36:28,840 --> 00:36:31,320 the grouping that's there in the 1st place that you don't have to 648 00:36:31,320 --> 00:36:36,360 spell it out as a, as a human or that the group might not be 649 00:36:36,360 --> 00:36:39,120 relevant to the the problem that the user that the user has. 650 00:36:39,120 --> 00:36:41,640 And if the model might find the different grouping mechanism. 651 00:36:42,120 --> 00:36:46,320 I mean, in the second part of that is like a group is, is 652 00:36:46,320 --> 00:36:49,960 nothing but like a tree with a with a like with a depth of 1 653 00:36:49,960 --> 00:36:51,960 effectively. So there's a generalization 654 00:36:51,960 --> 00:36:54,400 there that you need to be very mindful when you design 655 00:36:54,400 --> 00:36:55,600 protocols. You need to think about like, 656 00:36:55,920 --> 00:36:58,160 let's just generalize. Does it solve a problem? 657 00:36:58,160 --> 00:37:01,840 It's never is is often the case is yes, but the problem is like, 658 00:37:02,040 --> 00:37:04,080 is it solving all my problems in the future? 659 00:37:04,240 --> 00:37:06,720 And the answer has in some sense, no. 660 00:37:06,760 --> 00:37:08,760 And I need to that's the the hard one. 661 00:37:08,760 --> 00:37:12,280 And then you need to go back and like, no, let's wait, let's see 662 00:37:12,280 --> 00:37:15,280 if the model gets better. Let's see if how the world looks 663 00:37:15,280 --> 00:37:19,560 like in six months. Let's see how we're, you know, 664 00:37:19,560 --> 00:37:22,000 if we find a more general mechanism, even though it takes 665 00:37:22,000 --> 00:37:24,400 a three months more and it's painful for the people wait for 666 00:37:24,400 --> 00:37:27,080 the solution in the meantime. And I understand that, but 667 00:37:27,080 --> 00:37:29,360 that's the that's the kind of role that you will wear 668 00:37:29,680 --> 00:37:31,600 forward-looking is super important. 669 00:37:32,920 --> 00:37:37,240 And I think these things are super interesting, but there are 670 00:37:37,240 --> 00:37:39,360 like things that are pretty clear that there are no horizon, 671 00:37:39,360 --> 00:37:42,240 right? Like we know that the task, the 672 00:37:42,240 --> 00:37:46,000 length of a task that a model does is increasing, right? 673 00:37:46,000 --> 00:37:47,520 It's kind of like linear increasing. 674 00:37:47,520 --> 00:37:49,760 And we know this and we have that. 675 00:37:49,760 --> 00:37:53,000 That hasn't stopped really since the years this increase. 676 00:37:53,200 --> 00:37:57,640 So we know that like more long running tasks will just 677 00:37:57,640 --> 00:38:00,200 increasingly more important because we will increasingly 678 00:38:00,200 --> 00:38:04,000 less interact with a model in our chat environment because the 679 00:38:04,000 --> 00:38:06,680 model will like, because the task the model will do will be 680 00:38:06,680 --> 00:38:09,520 more asynchronously how we interact with humans and they go 681 00:38:09,520 --> 00:38:11,000 away and do something and come back. 682 00:38:11,520 --> 00:38:13,640 And so in that scenario, you're like, OK, I will need something 683 00:38:13,640 --> 00:38:15,640 like tasks, right? Like I will need something like 684 00:38:15,640 --> 00:38:17,960 that. I need to design it minimal and 685 00:38:17,960 --> 00:38:21,600 make sure it can be extended because I need to look in the 686 00:38:21,600 --> 00:38:23,080 future that I cannot predict, right? 687 00:38:23,080 --> 00:38:25,360 Nobody knows what's happening in six months from now in the AI 688 00:38:25,360 --> 00:38:29,040 field. So I will not know it either. 689 00:38:29,040 --> 00:38:32,640 So do all I know is I need to do the minimal thing that I know I 690 00:38:32,640 --> 00:38:37,360 can extend so I can solve future problems additively rather than 691 00:38:38,040 --> 00:38:40,480 subtract like with a subtraction or removing things? 692 00:38:41,200 --> 00:38:43,640 What do you think people don't understand about tasks? 693 00:38:45,240 --> 00:38:49,040 I think Task is a poor name. It's a poor name and a good 694 00:38:49,040 --> 00:38:50,480 name. It's a good name because it's 695 00:38:50,480 --> 00:38:51,840 accurate and what it's trying to do. 696 00:38:51,840 --> 00:38:54,800 It's poor. Maybe it does agent to agent 697 00:38:54,800 --> 00:39:00,240 communication effectively and I think there's some open 698 00:39:00,240 --> 00:39:03,680 questions there around. Is this the right format where 699 00:39:03,680 --> 00:39:06,400 there's some shapes to be experimenting around with it. 700 00:39:06,840 --> 00:39:09,640 But I think people really don't understand that what it 701 00:39:09,640 --> 00:39:13,080 effectively allows you to do is have an agent talk to another 702 00:39:13,080 --> 00:39:15,840 agent that that's effectively what it's doing. 703 00:39:15,840 --> 00:39:17,440 I think it's doing it quite effectively. 704 00:39:19,440 --> 00:39:25,680 But again, in the long tradition of MCP, we are in poor at naming 705 00:39:25,680 --> 00:39:29,000 things. So we we shall continue in our 706 00:39:29,040 --> 00:39:32,320 old tradition of continuing to name things, probably. 707 00:39:32,760 --> 00:39:37,280 Dude, you know, so I'm not going to comment on the naming of MCP 708 00:39:37,280 --> 00:39:40,360 because that's your business and I will let you have your fun 709 00:39:40,360 --> 00:39:43,480 with it. But I will say the folks who 710 00:39:43,640 --> 00:39:48,000 name things the best by far in my experience are the damn 711 00:39:48,000 --> 00:39:50,560 researchers. Follow me on this one. 712 00:39:50,800 --> 00:39:53,200 Hallucinations with models, right? 713 00:39:53,240 --> 00:39:55,200 And then you have, what else do you have? 714 00:39:55,440 --> 00:39:58,400 Catastrophic forgetting of models. 715 00:39:59,560 --> 00:40:02,440 Give me a better name. Maybe we need a bit more drama. 716 00:40:02,480 --> 00:40:06,880 Exactly. Catastrophically forgotten that 717 00:40:06,880 --> 00:40:10,720 10. Mug Yeah, yeah, maybe, maybe, 718 00:40:10,720 --> 00:40:14,680 maybe should go in. Next time you have a big naming 719 00:40:14,680 --> 00:40:18,200 conundrum on your hands, just go walk around the office and find 720 00:40:18,200 --> 00:40:21,080 a few of the researchers and say, like, what would you call 721 00:40:21,080 --> 00:40:24,200 this? I love it. 722 00:40:24,400 --> 00:40:25,960 I love it. I I should do it. 723 00:40:25,960 --> 00:40:28,160 That's a good idea. We are, we are certainly. 724 00:40:28,160 --> 00:40:29,880 We are not. We are good at a lot of things. 725 00:40:29,880 --> 00:40:31,240 Naming is not one of them. That's for. 726 00:40:31,240 --> 00:40:32,960 Sure, but it is hard dude. It is so. 727 00:40:33,080 --> 00:40:35,400 I It's hard. Vibe with you 100% on that 728 00:40:35,400 --> 00:40:37,000 because you're like yeah, that sounds good. 729 00:40:37,000 --> 00:40:38,960 And then somebody comes up and they're like well does that mean 730 00:40:38,960 --> 00:40:40,520 this? And you're like, that is not at 731 00:40:40,520 --> 00:40:41,760 all what I thought it was going to mean. 732 00:40:42,600 --> 00:40:44,240 How did? You get that where you start and 733 00:40:44,240 --> 00:40:45,880 where you end up. These are two different things. 734 00:40:45,880 --> 00:40:49,320 And the name has does not change while the expectation has. 735 00:40:49,640 --> 00:40:51,960 So there's a. There's a fundamental issue 736 00:40:51,960 --> 00:40:53,520 there as well. Oh well. 737 00:40:53,640 --> 00:40:57,200 All right. So I want to shift towards Jason 738 00:40:57,240 --> 00:41:00,560 and token usage a little bit because a question came through 739 00:41:00,560 --> 00:41:05,680 about Jason, how verbose it is, how many tokens it uses. 740 00:41:06,160 --> 00:41:09,800 Do you feel like there's a world and of course this may and is 741 00:41:09,800 --> 00:41:15,480 probably stepping outside of MCP world potentially, but is there 742 00:41:15,480 --> 00:41:19,680 a world where Jason is not there or there's something more 743 00:41:19,680 --> 00:41:22,680 efficient? I, I do not know, I think the so 744 00:41:22,680 --> 00:41:27,800 there's two things from the on the what is what is MCP using as 745 00:41:27,800 --> 00:41:30,640 a transport mechanism? And that's independent from what 746 00:41:30,640 --> 00:41:33,080 you give the model, right? You can take a Jason BLOB and if 747 00:41:33,080 --> 00:41:36,240 the model accepts something else than Jason, you can transform 748 00:41:36,240 --> 00:41:37,960 them. As long as it's a bi directional 749 00:41:37,960 --> 00:41:41,480 mapping, which it should be, it should be fine. 750 00:41:41,600 --> 00:41:44,280 So what do you get from MCP? Must must not necessarily what 751 00:41:44,280 --> 00:41:47,120 you give to the model, what you give to the model. 752 00:41:47,880 --> 00:41:50,640 I do I do not know what the what the most recent research about 753 00:41:50,640 --> 00:41:55,280 this is. I do think Jason is has a lot of 754 00:41:55,520 --> 00:42:01,160 benefits. It is actually quite, quite 755 00:42:02,280 --> 00:42:06,920 compact by itself. Like people forgot the world 756 00:42:06,920 --> 00:42:10,000 where XML was the big thing that was verbose in comparison. 757 00:42:10,000 --> 00:42:13,880 So I think Jason's actually quite compact. 758 00:42:14,680 --> 00:42:19,600 I do think that I'm that I'm usually looking at things about 759 00:42:19,600 --> 00:42:23,240 less of a like token usage, but like how much tokens did I need 760 00:42:23,240 --> 00:42:26,560 to get a task done like that I that I wanted to do. 761 00:42:28,240 --> 00:42:31,800 And I do think like, while tool usage might be now, might be not 762 00:42:31,800 --> 00:42:35,120 the perfect, most efficient thing to do as, as we do it now, 763 00:42:35,480 --> 00:42:39,000 I think it's probably very good enough, given that the that the 764 00:42:39,640 --> 00:42:44,200 that the cost per task done is, is, is decreasing as the models 765 00:42:44,200 --> 00:42:48,400 are getting better, right? Like, and so I'm less worried 766 00:42:48,400 --> 00:42:50,760 about it. I don't honestly really see it 767 00:42:50,760 --> 00:42:55,360 as a, as a massive issue. And I think actually that you 768 00:42:55,360 --> 00:43:00,240 what, what, what you can foresee a world where instead of like 769 00:43:00,240 --> 00:43:04,360 using Jason as a tool calling mechanism, you just write code 770 00:43:04,360 --> 00:43:06,320 that you execute, that the model just writes code that you 771 00:43:06,320 --> 00:43:08,160 execute. That's another idea. 772 00:43:08,160 --> 00:43:11,120 And that failed. And then your effective format 773 00:43:11,120 --> 00:43:13,320 becomes a JavaScript or whatever you might choose. 774 00:43:14,320 --> 00:43:17,000 And that is also maybe not the most efficient thing, but it is 775 00:43:17,000 --> 00:43:20,320 the thing that the the model is really pretty good at because it 776 00:43:20,320 --> 00:43:23,200 turns out there's a lot of Jason in the world. 777 00:43:23,920 --> 00:43:27,760 And so again, this is a good research question. 778 00:43:28,160 --> 00:43:32,560 I think it's I did does not feel to me like a particularly high 779 00:43:32,560 --> 00:43:35,720 priority in the savings you're getting from being smart about 780 00:43:35,720 --> 00:43:40,240 your context selection, about being smart about the way you 781 00:43:40,280 --> 00:43:43,640 execute things, the things using tool searches and tool and 782 00:43:43,640 --> 00:43:46,080 programmatic tool calling. I think those in general are 783 00:43:46,080 --> 00:43:50,360 probably bigger savings in my mind intuitively than a specific 784 00:43:50,360 --> 00:43:52,000 formatting questions to be honest. 785 00:43:52,120 --> 00:43:55,640 And I do like this idea of hey, just because the transport layer 786 00:43:55,640 --> 00:43:57,720 uses it doesn't mean you can't use something else. 787 00:43:57,720 --> 00:43:59,520 Oh yeah, yeah, yeah. But this is the thing, right? 788 00:43:59,520 --> 00:44:03,240 MCP like that's maybe one of the biggest misunderstandings for 789 00:44:03,240 --> 00:44:05,680 them to be people think is like that's what the model interact 790 00:44:05,680 --> 00:44:06,440 with. That's not true. 791 00:44:06,440 --> 00:44:09,480 It's what the application around interact with. 792 00:44:09,480 --> 00:44:16,120 It's a pure it's a very old school program, a talk to 793 00:44:16,120 --> 00:44:19,240 program B and some form of information. 794 00:44:19,560 --> 00:44:23,400 And that information does not need to be the same thing that 795 00:44:23,400 --> 00:44:28,440 goes into the true calling. It turns out that the format 796 00:44:28,440 --> 00:44:33,400 that we chose is clearly the same format that like an open AI 797 00:44:33,400 --> 00:44:35,520 or Anthropic API would expect to do. 798 00:44:35,520 --> 00:44:38,920 Which is very convenient for people to do, but it does not 799 00:44:38,920 --> 00:44:41,480 stop you to experiment with other things. 800 00:44:42,760 --> 00:44:46,280 So anyway. Let's hit on observability 801 00:44:46,280 --> 00:44:48,760 because this question came through and I, I really liked it 802 00:44:49,360 --> 00:44:54,840 as far as like as agents start using multiple MCP servers and 803 00:44:54,840 --> 00:44:58,880 then they're chaining the different tool calls, debugging 804 00:44:59,040 --> 00:45:01,360 becomes difficult. You had mentioned earlier about 805 00:45:01,360 --> 00:45:05,000 the ID session that potentially feels like it could be a little 806 00:45:05,000 --> 00:45:09,880 bit of traces happening, but incorrect tool selection might 807 00:45:09,880 --> 00:45:12,440 be there. Also, you have MCP server 808 00:45:12,440 --> 00:45:16,080 failures. Do you see a world where your 809 00:45:16,080 --> 00:45:19,120 standardized tracing or is this again something that you're like 810 00:45:19,840 --> 00:45:24,280 that shouldn't be on us, that needs to be something else? 811 00:45:24,960 --> 00:45:28,840 Two things that first of all, I think in a, in a more general 812 00:45:28,840 --> 00:45:31,720 tracing mechanics, I don't think that's an MCP problem. 813 00:45:31,720 --> 00:45:36,680 I think because there are aspects within the execution of 814 00:45:36,680 --> 00:45:40,280 a of an of a model that are not MCP that you still want to 815 00:45:40,280 --> 00:45:42,880 trace. And so those would be different 816 00:45:42,880 --> 00:45:46,560 things. But at the same time, within 817 00:45:46,560 --> 00:45:50,600 MCP, there's open telemetry standards that he should be 818 00:45:50,600 --> 00:45:52,240 using. And so there are some of the 819 00:45:52,240 --> 00:45:54,480 things that that we can do and, and should do. 820 00:45:54,840 --> 00:45:56,600 But again, they're on the MCP layer. 821 00:45:56,600 --> 00:46:00,920 And the MCP layer is just part of the general execution of, of 822 00:46:01,160 --> 00:46:03,440 like a model loop and not the full loop. 823 00:46:03,440 --> 00:46:07,640 And for that, you know, different model providers offer 824 00:46:08,200 --> 00:46:11,760 different abilities to introspect this or write trans 825 00:46:11,880 --> 00:46:13,680 transcriptions or something like that. 826 00:46:14,400 --> 00:46:16,600 And that really depends. I if I'm not sure if there will 827 00:46:16,600 --> 00:46:18,720 be an open centered, I don't know if there there should be. 828 00:46:18,720 --> 00:46:21,440 If anything, I think should be something out of something like 829 00:46:21,440 --> 00:46:24,000 an open telemetry to some degree. 830 00:46:24,560 --> 00:46:27,440 I'm not sure if that's enough, if there might be more 831 00:46:27,440 --> 00:46:30,840 additional information needed. There's always a challenge here, 832 00:46:31,400 --> 00:46:33,760 particularly when you're dealing with raw unstructured text, 833 00:46:33,760 --> 00:46:39,680 which effectively models are, is being careful about privacy and 834 00:46:40,080 --> 00:46:44,880 data retention implications while being useful at the same 835 00:46:44,880 --> 00:46:49,160 time, right. And the, the most useful tracing 836 00:46:49,160 --> 00:46:50,800 you can do is trace everything, right? 837 00:46:51,200 --> 00:46:54,240 That, that, that would of course include things that you probably 838 00:46:54,240 --> 00:46:56,760 don't want to trace for the sake of your users. 839 00:46:57,040 --> 00:46:59,200 And so there's trade-offs to be done. 840 00:46:59,320 --> 00:47:02,920 Again, on the on the MCP side, there's a lot of open telemetry 841 00:47:02,920 --> 00:47:05,160 work around. The open telemetry people have 842 00:47:05,480 --> 00:47:08,760 some form of standards around how you trace MCP servers and 843 00:47:08,760 --> 00:47:14,320 and a lot of the the the typical server and client SDKS do have 844 00:47:14,320 --> 00:47:16,040 traceability functionality in it. 845 00:47:16,440 --> 00:47:19,720 On the general thing, I do not know if there should be an open 846 00:47:19,720 --> 00:47:22,880 standard or not. It's something that's not top of 847 00:47:22,880 --> 00:47:24,320 my mind. It could be. 848 00:47:24,560 --> 00:47:26,040 Yeah, it's outside of your scope. 849 00:47:26,320 --> 00:47:31,080 You you just need to focus on naming properly and that's going 850 00:47:31,080 --> 00:47:38,080 to get you way farther. So when will MCP be done? 851 00:47:38,080 --> 00:47:42,520 Is there ever a finished state? How's the vision and mission set 852 00:47:42,520 --> 00:47:46,800 for that type of thing or is it continuously going to go? 853 00:47:46,800 --> 00:47:50,720 Do you feel like you're going to be able to put your feet up and 854 00:47:50,720 --> 00:47:55,000 relax at any point if it gets to certain place? 855 00:47:55,520 --> 00:47:58,520 I, I think there's, there's a world where the core part of it 856 00:47:58,520 --> 00:48:01,000 will be kind of done. I, I think it's actually not 857 00:48:01,000 --> 00:48:02,960 that far away. I think they're the, there's 858 00:48:03,080 --> 00:48:07,440 things we need to do, but the general core pieces seem to get 859 00:48:07,440 --> 00:48:09,640 into a reasonable good shape there. 860 00:48:09,640 --> 00:48:14,560 It feels to me it might relate similar to how you see a lot of 861 00:48:17,640 --> 00:48:21,480 standards, like for example, our authorization, others happen 862 00:48:21,480 --> 00:48:26,840 where there will be a a small use case that someone has and 863 00:48:26,840 --> 00:48:30,480 they will want to build an extension and to the protocol 864 00:48:30,480 --> 00:48:33,200 and then they will make this a thing. 865 00:48:33,200 --> 00:48:34,840 And then that's an important thing to do. 866 00:48:35,200 --> 00:48:39,600 So there's a lot of there's a lot of like in the last 20% of 867 00:48:39,600 --> 00:48:42,760 use cases, there's a lot there that still needs to be done. 868 00:48:43,040 --> 00:48:45,000 Those will likely be done during extension. 869 00:48:46,040 --> 00:48:48,840 And I think that has I do not see that to slow down. 870 00:48:48,840 --> 00:48:51,720 There's so many open questions like how do you deal around 871 00:48:51,720 --> 00:48:53,680 guardrails? How do you deal with the 872 00:48:53,680 --> 00:48:57,680 compliance problems and regulator regulatory problems. 873 00:48:57,680 --> 00:49:02,840 There's, there's is a extension called Interceptors that is 874 00:49:03,040 --> 00:49:06,920 proposed by by the financial interest group at the MCP 875 00:49:06,920 --> 00:49:10,320 project, which is mostly like consists of the Bloomberg, the 876 00:49:10,320 --> 00:49:15,160 Capital One of the world, who all have very interesting, very 877 00:49:15,160 --> 00:49:19,160 valid problems. And I think that will these kind 878 00:49:19,160 --> 00:49:21,760 of senses will continue. There will be, you know, you 879 00:49:21,760 --> 00:49:25,480 can, you can afford, I do not know, but like, for example, you 880 00:49:25,480 --> 00:49:27,560 can think about like an extension that will do something 881 00:49:27,560 --> 00:49:32,920 like A to UI and MCP where you are allowed to do the I 882 00:49:32,920 --> 00:49:35,000 components that can be rendered in a terminal. 883 00:49:35,200 --> 00:49:37,640 But there's a lot of these use cases that's awesome that I 884 00:49:37,640 --> 00:49:40,480 think can happen. But I think they will happen in 885 00:49:40,480 --> 00:49:44,960 an an extension type of way where the core hopefully should 886 00:49:44,960 --> 00:49:46,640 be stable. That's the goal. 887 00:49:46,640 --> 00:49:53,720 Like protocols like MCP thrive from from stability. 888 00:49:53,720 --> 00:49:57,840 And most importantly, protocols like MCP have a budget of how 889 00:49:57,840 --> 00:50:00,640 willing the ecosystem is to change. 890 00:50:01,080 --> 00:50:04,240 And that budget is pretty much directly correlated with the 891 00:50:04,240 --> 00:50:06,440 amount of attention the project has. 892 00:50:06,760 --> 00:50:08,720 And the project has a lot of attention in year 1. 893 00:50:08,720 --> 00:50:11,040 It has more some attention in year 2. 894 00:50:11,360 --> 00:50:14,240 It will have less attention in Year 3 because it will just be a 895 00:50:14,240 --> 00:50:16,720 standard part of the stack, and that's fine. 896 00:50:16,720 --> 00:50:19,120 And that means that people do not want to change the center 897 00:50:19,120 --> 00:50:21,000 part of the stack because they're thinking about something 898 00:50:21,000 --> 00:50:22,280 else. Incredible, man. 899 00:50:22,320 --> 00:50:23,800 Well, this has been great chatting with you. 900 00:50:23,840 --> 00:50:28,480 I will say that you're going to be giving talks at the MCP Dev 901 00:50:28,480 --> 00:50:30,960 Summit that we're doing right. You're coming to Japan. 902 00:50:31,520 --> 00:50:33,800 I'm coming to Japan, I'm coming to Amsterdam, I think the week 903 00:50:33,800 --> 00:50:37,840 after a few days later and then I'm going to be in October and 904 00:50:38,080 --> 00:50:40,120 some some Jose at the the big Asian comp. 905 00:50:40,600 --> 00:50:41,800 Well, it's. Going to be there batting. 906 00:50:41,800 --> 00:50:43,520 With you, I'm going to be at all of those. 907 00:50:43,600 --> 00:50:45,920 I'm going to be. I'll try and corral you when 908 00:50:45,920 --> 00:50:47,680 we're there and. Are you going to go to even 909 00:50:47,680 --> 00:50:49,480 more? Are you going to go to the the 910 00:50:49,480 --> 00:50:51,920 Seoul one of the? Nairobi one, I am going to 911 00:50:51,920 --> 00:50:53,160 Korea. I'm very excited for that 912 00:50:53,160 --> 00:50:54,160 because I've never been to Korea. 913 00:50:54,200 --> 00:50:55,600 I'm pretty sad I miss out of Korea. 914 00:50:55,680 --> 00:50:58,720 I really like, I really like myself some some Korean food and 915 00:50:58,720 --> 00:51:02,080 like watching some some E sports life and stuff like that. 916 00:51:03,040 --> 00:51:05,880 I want to watch robots. Literally just saw as I was 917 00:51:05,880 --> 00:51:09,920 boarding the plane to Lisbon that robot soccer has become 918 00:51:09,920 --> 00:51:13,320 very popular now because of the World Cup, but Korea's not 919 00:51:13,320 --> 00:51:17,600 playing anymore in it, so they're enjoying robot football, 920 00:51:17,920 --> 00:51:20,280 so that's pretty good. Yeah, I've been to Korea before. 921 00:51:20,280 --> 00:51:22,440 It's a great place, man. I'm I'm hope you're going to 922 00:51:22,440 --> 00:51:24,120 enjoy it. Yeah, that should be fun and 923 00:51:24,120 --> 00:51:25,920 we'll hear how people are using MCP over there. 924 00:51:25,920 --> 00:51:29,160 So that should be fun. And then the big release is 925 00:51:29,160 --> 00:51:31,400 coming out. So folks, let us know what you 926 00:51:31,400 --> 00:51:36,800 think and we will. The 28th of of July comes the 927 00:51:36,800 --> 00:51:40,520 release and then was that the the version true of all the 928 00:51:40,520 --> 00:51:43,600 SDKS, which I think is the the thing that for developers matter 929 00:51:43,600 --> 00:51:46,760 the most. Yeah, I really hope that 930 00:51:46,760 --> 00:51:48,560 everybody's going to upgrade their MCP servers. 931 00:51:49,000 --> 00:51:51,160 Give us feedback comes to the community. 932 00:51:51,160 --> 00:51:53,760 We're we're actually I think a quite a friendly bunch. 933 00:51:54,160 --> 00:51:57,120 We're busy, but we are friendly bunch and trying to listen to 934 00:51:57,120 --> 00:51:59,320 everyone and understand what they're coming from. 935 00:51:59,840 --> 00:52:01,400 So bring the problems, bring the ideas. 936 00:52:01,640 --> 00:52:06,120 A lot of the things that are in this protocol revision are not 937 00:52:06,120 --> 00:52:08,280 things that came out of my head. There are problems that other 938 00:52:08,280 --> 00:52:11,600 people brought to us and that we're working on. 939 00:52:11,600 --> 00:52:15,440 So yeah, bring the back the feedback, update your servers, 940 00:52:15,440 --> 00:52:19,480 update your clients, and yeah, I'm super, super stoked and see 941 00:52:19,480 --> 00:52:20,840 where the ecosystem is going then. 942 00:52:21,160 --> 00:52:22,600 That's the beauty of open source.