Now we're in a state where people rely on the SDKS, where
the SDKS have hundreds of millions of downloads a year or
a month, and that gives us a different lever that we didn't
have 12 months ago. And you need to be aware of
these and then use them to your advantage and and be mindful
around the limitations. It does feel like a maturing
and. It does start this maturing,
yeah. Yeah, it's, it's something that
you're like, oh, very clear value prop.
There I need to do the minimal thing that I I know I can extend
so I can solve future problems additively rather than subtract
like with a subtraction or removing things.
What do you think people don't understand about tasks?
All right, probably a good place to start this one, dude.
And what I'm most stoked about is hearing the context around
the new release. What is it?
What was the inspiration behind it?
Yeah. And like the, I think the new
release is honestly probably one of the biggest release we have
ever done around MCP. It has a one big change to how
we are using MCP in in the sense that when we originally
developed MCP over the last year, the the protocol was
somewhat stateful. So you needed to keep you know a
session open between the server and the client.
And that did not work very well for some of their particularly
big hyper scalers that now use MCP pretty much everywhere.
That being the Microsoft of the world, the Google's of the
world, the anthropics of the world.
And so this release is really about moving away from the
statefulness of the protocol to a full day stateless protocol.
And we have worked really, really hard to make this work in
the, in the way MCP operates. And I've put a lot of work into
this and this probably the biggest change we've ever done
to the protocol. So I'm I'm super hyped about it.
So no more handshakes. What can you go a little bit
deeper into this inspiration? Because you probably saw this
coming up and then there was a point where you were like, we
need to figure out what's going on here.
Yeah, like the the original version of the protocol, right.
It was like all standard IO. It was like it was a very
natural thing that you have this notion of, you know, a program
that you can always interact with that's this MCP server.
And then as we went over trying to do this over HTTP, we tried
to retain this because we fundamentally believed that
agents are somewhat stateful. But it turned out operationally
over the year we learned that there are other methods how you
can still get that without having to rely on a stateful
protocol or a stateful transport.
And the cracks kind of showed, particularly when we saw again,
the really big hyperscaler tried to do this with like at like
massive scale, like thousands of 10s of thousands of servers
serving like millions of requests.
And then you're like, you're getting into really hard
difficulty problems of like, how do you scale this?
How do you, you know, move the state around?
There's a particular problem where, you know, you hit one
server and you kind of want to have a load balance to hit the
next server. But if you have some for state
in this one server, you kind of need to communicate this to the
other server. That's hard to do.
And you can do it and, but it's painful.
It's, it causes latencies and it causes CPU usage And it's just
like very unpleasant to serve. And so a lot of the hyper scaler
really wants stateless workloads, but that they can go
to 1 server, make a request, take the request, go to the next
server and do you know something else?
And everything you know can go through a load balancer,
everything can, you know, some of the things can be cached.
Just the standard things we kind of know how to do.
We kind of went there and we again overtime figured out what
are the pieces of MTP that needs to be stateful, what are the
pieces that don't need be stateful?
And we decided the transport part doesn't need to be.
And so it's, I think it's a very natural, you know, progression
and evolution of the protocol. Maybe you could have seen some
of that bit earlier, but I think now I think it's a great time
and we have worked really hard with again some of the the
industry giants honestly to like make this work for them and also
make it work for us. It does feel like a maturing
and. This is, yeah, it certainly is
maturing, Yeah. Yeah, it's, it's something that
you're like, oh, very clear value prop there.
Are there any trade-offs that you had to grapple with when you
were deciding this? Yeah, some of the hardest part
is that some things inside the protocol are somewhat inherently
stateful. So for example, if you send a
tool request and you want to do an elicitation, so you ask the
user for explicitly for input, that is kind of bound to that
tool call. In the original specification,
it was actually could at any time send this elicitation even
if there's no tool call. So we have to make constraints
of like now you need to do it within a true call, which is we
we did a survey of all guitar proposals we could find and
basically 99.9% use it exactly the way we are a tool call.
But it means that when you do this, you, you still need a way
for like there's some form of state being hold on a server
while this true call is ongoing and you asking for input from
the user. And so we needed to build a
little bit of a machinery on top of it of this like statefulness
approach as statelessness approach, which we call multi
round trip responses, which or requests which require you to
basically go there, do a tool call, get an hesitation back,
put all of this together to call plus solicitation result and
send it again. So you're basically appending to
the context and you're transporting the whole context
over the wire. And that just allows the like
another server can now send like response without having, you
know, while having the full context.
So there was some of that machinery we needed to build
into that is less that is a bit more unique to MCP because we
have this like there's inherent statefulness in some of the
semantics that we that are in the protocol.
Well, it does feel like these agents and the assumption at the
beginning of this needs to be stateful because agents
potentially have these unique characteristics and that got
disproven in a way, if I'm understanding you correctly.
Can you talk a little bit more about how that got disproven?
I I think that it's less about it got disproven as a as a
concept. I think it what we learned is
that it doesn't have to be on a transport level.
So it doesn't have to be on the HTTP channel that the state is
open. So for example, the that there
is state between a tool call and elicitation.
When you make a tool call and you ask the user for input,
there is some form of state. You know the tool call waits for
that elicitation to to be done and get this additional input.
So there's some form of state. But what we have now done is we
have taken all this state that is required and basically move
it over the wire over and over again.
So effectively making the the transport doesn't have to be
open all the time, but the data still encapsulates that kind of
state. And So what we have learned is
just to be more efficient about encapsulating and how we encode
the state. And we have learned areas where
we don't need that state. So for example, we have learned
that people always want to ask for user input during a tool
call and never outside of that. And that's some of the things
that we have learned and that learning over the years that has
led to this like new stateless mode that we call like multi
round trip responses, replies. And I think that's especially
the thing fundamentally, there's still statefulness in agents, I
think. I do like that you're starting
to see the patterns and you're starting to help MCP protocol
work together with the patterns, as opposed to all of us figure
out how MCP works and then create patterns around it.
Exactly. A second part of that learning,
for example, is and we have learned that when you do need
some form of session of like, oh, you will call, you know, you
call the tool to add something to a basket, only then you have
a new tool that has like a basket, you know, I don't know,
list my basket or whatever. We have learned that nowadays a
year and a half and part of that is the models just got better.
We is that you can just give the model us like an ID that it just
carries around between the tool calls.
And so it's like an implicit session.
You don't have to put it on the protocol level anymore because
the the model will just perfectly happily take a like an
ID that you give it and then move it into every other tool
call. So you can piece them together
that they belong to each other. And we have proven this was
basically all major models and all of them do this now.
Well, a year and a half ago, it would have been a very different
story. So part of it is also that the
models just get better. Yeah, and they're happy to carry
that ID. Yeah, they're happy to carry
that ID now, yeah. And that makes it much easier on
your side. I can see how that will help
with the the whole designing. You go, OK, well if this is true
then that makes our lives a little bit easier and you feel
more confident removing some of these pieces.
Yeah, exactly. And now paint me the picture of
someone who is currently using the MCP version and wants to go
to the new version. What does that look like?
Luckily it looks very, somewhat, very easy to you as long as you
use one of the SDKS. So we put a lot of effort at the
moment into changing the SDK such that the the lift is
somewhat minimal, at least minimal with the help of a
model. And they're the TypeScript SDK
and the Python SDK, for example, they come out with a version 2
that will support this. And the changes between version
1 and version 2 are very easily done by like an Opus model or
something like that. And so it's maybe a minor
update, but it's not a hard lift.
It's not a fundamental change. A lot of the hard pieces are
abstracted away by by the SDKS if you're not.
But if you're running your own SDK, the lift is significantly
higher. And I would highly say suggest
that you going to go and use some of the SDKS and all of
these SDKS currently kind of work, work for version 2.
I think the C# SDK also works towards the version 2.
Not sure about the Go SDK. I think they stick to a want to
still to that 10. But most of them again, have put
a lot of thought and effort into making sure the upgrade is very,
very minimal and basically one shot about with the model that
was like the base requirement that it's not a hard lift.
So it should be fairly easy. And then similarly, if you have
existing soft, if you have existing servers, they should be
able to, to, to continue to work, right?
The protocol has versions. There's a, there's a lot of
sessions and a lot of documentation and work in the
SDKS to make sure they fall gracefully back to the version
that your server is going to use.
So it should just continue to to use.
This can be in a way of forcing function to use those SDKS.
If you had been thinking about bringing over some ideas and
it's weekly, Yeah, just use it, make your life easier.
You don't need to impress anyone, but exactly the other
PSA is don't forget to pour everything to Rust before you
change it to the SDK. But apparently.
Always, always. Everything runs better after
it's been ported to Rust, apparently from the.
Research I but you just just give it to to Fable and it will
just do all of it for you. Exactly.
That's what I've heard, and it's so wild to think like, oh, take
it, port it to Rust, and then you can port it back to the same
language and it will perform better.
So yeah, maybe. I don't know, I have to try.
Yeah, yeah, there there's the rumor going around.
So we need some hard details and science backed proof on this.
But until I see that I'm still going to be perpetuating the
rumor. Anyway, there's a few things
that I want to go into that are more theoretical and less based
in the protocol. And that's like what you've
learned. You've been manning the ship and
there's a great maintainer team that is also working on this,
but there's a lot of precedence for open source projects over
the years. Are there things that you feel
like the MCP protocol can learn from all of our past open source
winnings, and this one comes specifically, I asked the
community for questions and we got some incredible questions.
This one's coming from a question from the community.
They're wondering like, what are you going to take from HTTP and
all these other protocols that we've seen in the wild?
I think there, I think there's always something to learn.
I think you can always take a look and sometimes you learn
things you want to repeat and sometimes you learn things you
do not want to repeat. Well, they don't apply to you.
It's less often that they're wrong.
It's mostly that they might not apply to you.
And so they're, I think there's a few things.
The, the first thing is on the standards, some of the big
challenges is the, the standards, most successful
standards work in a way that they take a long time to be
billed and they're mostly consensus driven.
That's like HTTP, some of that, a lot of the authorization work
things that come out of the ITF in general, for example, are
very consensus based. Consensus based mechanisms are
very, very slow. They they take a long time, but
at the same time they often, depending how you do it, they
result in usually solutions that are quite good.
They're not perfect, but they're quite good.
HTP 1.1, HP 10, interesting enough, did not work well. 1.1
is the one everyone's using, right?
And I think we keep forgetting that quickly. 2.0 is also quite
well done. But then even they already had
shortcut Cummings and now they're three, right?
And you can learn some of the carefulness and considerations
and being sometimes more on the conservative side and saying no
to things because you know that two things can happen.
First of all, you can change things and add things later
that's happened to, you know, HTTP 1.1.
I'm sure during the process of HTTP, two people have known that
they will be shortcomings that they are currently putting into
the protocol and yet they continue because it is good
enough and it is within the time frame that they have and they
know the version 3 periods later might, might change it.
And that's OK. Standards are not there to solve
everything. That's they're there to solve
most problems. And so I think there's a lot of
lessons to learn in that regard. There's a lot of lessons to
learn in like how you run a successful open source project
and like in a governance and like a general sense.
And there are many, many ways to do this.
You can run it in a BDFL style like like the Linux project.
You can run it in a steering committee style like the Python
community. And they all have their
drawbacks and benefits. And I think what we have learned
here is that I think for us like having a strong core to maintain
our foundation. So a set of like a more of a
steering committee type and plus the BDFL on top has worked for
the most part quite well. I think there's things that we
will change this year to make it even more democratic and allow
more as the project is maturing and the structures of maturing
and like being able to be a bit more, be even a bit more
democratic. So it's always like a matter of
like you look at these projects and like, okay, you know, an ITF
project chooses democracy over everything else and consensus.
And as a result, it's slow. A project like, I know, take
something like and like a like a famous new open source project
like Ghosty, like with a, with a clear one leading person was
Mitchell, right? He's very fast and in certain
ways because of just one person making a decision, right.
And then there are mixes like the Python projects and you
choose the thing for the stage you're in.
And I think that's the, there's a good lesson to be learnt
there. And so for us, the interesting
part is finding that middle ground of like, we want to be
fast. We want to be somewhat
democratic, but we will also want to move.
We also want to be considerate and be somewhat conservative,
but at the same time, you know, we also work in a, in a, in a
slightly different environment because we're working in
software where things can change quicker.
And for example, if you like pre creating like a hardware
standard or a telecommunications standard where someone puts the
standard on software onto a box, puts the box 200 kilometers into
the north of Sweden and it's going to sit there for the next
10 years, you have a very different set of problems than
if you build MCP, for example. I like that juxtaposition
because in the real world, yeah, the atoms take a whole different
route for the standards. And it also is cool to hear you
say like, you're choosing this path right now because it is
what you feel the most optimal route.
But in the future, once things stabilize even more than they
already are, you're open to taking on new ways and trying
those out and seeing like a new pair of pants.
Do they fit? Do they do they look good in
them? All right, cool.
I, I, I have a very clear picture in my mind of like where
this going to go in a year or two years and how this needs to
evolve on a governing perspective.
Because it's pretty clear that I think this model is, it's is a
is a temporary artefact in time for the current situation the
protocol is in. But that will not be the
situation of protocol as in a year from now and then.
It requires different governance.
And I did want to hit on something else that you
mentioned, which I have found to be true, especially back in the
ML OPS days, is the sooner you can get something out there and
get folks using it and testing it, the sooner you can realize
where you had gaps in your thinking.
And so it is like that speed that you're looking for is a
feature, not necessarily a bug in that regard.
That makes sense. I I agree with some constraints,
right? The constraint is like how
flexible is the environment. And again, I think the
environment in which MCP is at is exceptionally flexible
because people around AI do two things.
They first of all, assume an exceptionally high velocity of
change and they're using models that help them to retain that
high velocity. So some of the burdensome work
is less burden burdensome. And so those are things that are
cultural pieces that you need to take into account when you
design the, the speed that you're you're going at.
And this is, for example, not true for programming languages
per SE. In programming languages you
know, particularly older programming languages or certain
niche programming languages, you might have less adoption of AI
or you might have, you might not want to change your code
constantly because of changes and because you just want to get
stuff done. And so there's, there's
carefulness to be considered here.
And even we, I think, have limits, right?
Like when we did the protocol changes and now what we're
doing, the SDK changes in particular, we're paying a lot
of attention that the delta is small enough to be done because
we don't want to jump into the problems that let's say like a
Python 2 to Python 3. Change had or there's there's
other aspects or in IPV 4 or IPV 6, there's a bunch of these type
of things where they are very cumbersome and difficult to do
and you need to be careful that the delta is small enough that
that the net benefit outweighs the friction.
Are there breaking changes that you feel like may happen in the
future? I never know.
I think we are getting into a shape where it's a lot of the
things are additive. The the problem at the moment, I
think we're going to see now is that the complexity of the
protocol will increase. And by virtue of we're trying to
we're probably at like an 80% solution space like 8020 where
80% of the problems people have in that space of soft and 20%
are not. And if you, it turns out if you
push the boundary beyond these 80%, the last 20% are actually
like 80, like 80% more complexity added, right And so.
80 times it's. Disproportionately more
complexity, right? We're adding caching, we're
adding caching scopes, things that look very similar to things
that exist in HTTP, at which point you need to ask yourself,
OK, at which point you're just going to rely on HTTP, right?
And, and we have made some choices a year and a half ago
that make this a bit more tricky.
And so there are there are decisions to be made down the
road, but most importantly, it is it means added complexity.
When we originally designed the protocol, we were mostly
concerned and mostly obsessed with adoption because that's the
thing that makes or breaks the protocol.
And the key principle for the very first version of the first
six months of MCP was that it's very simple to implement to the
point where we constantly tested that if you just give it an SDK
or if you just give it even the specification, a model will
write you happily an SDK in that language.
I mean, that was true 6 done in the first six months.
I don't think that is necessarily true anymore because
the complexity has increased. But that's OK because now we're
in a different state. Now we're in a state where
people rely on the SDKS, where the SDKS have hundreds of
millions of downloads a year or a month, and that gives us a
different lever that we didn't have 12 months ago.
And you need to be aware of these and then use them to your
advantage and may and be mindful around the limitation.
Hundreds of millions of downloads a month.
There is unreal just as a stat that you kind of glossed over.
And that is a great segue into I think this philosophical battle
that I'm sure your going through day by day as you're looking at
what to add as an extension versus bring on as a core.
And one of the questions that the community asked me too to
ask you, well it comes from Manvika and she was asking where
do you draw the line between something that is core versus
extension, especially with the idea of simplicity in like that
you want to touch on? There's a few things I think.
I think it's a very good question.
It's an aspect that we very rarely explain, but I think like
there's some very thought, there's some thoughtful thinking
behind this. What the, the, the principle
that need to apply to core are it needs to be composable.
It needs to be so that for example, like a, a resource in
MCP is a fairly general like remote file system approach that
perfectly composes nicely with tools as an execution approach
and so on. Then that's one aspect of that.
The second aspect of that is it needs to solve like serve all
clients and all servers at the same time.
I give you an example. MCP apps is a great thing, but
it only works in surfaces that I have browser, a browser
rendering in it, which is very constrained, right?
Because it an MCP app renders HTML, right?
And so a terminal will never be able to and look at an MCP app
and that's OK, but it means that it's not part of core because
you're leaving out a large chunk of the MCP client clients out
there. And so there's these kind of
consideration that we are having that is, that is for what
belongs in the core. The second thing that belongs in
the core is concepts that we are very confident will stay very
stable. So one of the best example of
this is where we maybe made a, maybe not a mistake, but like we
were, it was a sequencing issue. It's MCP tasks, MTP tasks is
this idea of long running tasks for long running tool calls,
which allows you effectively to do agent to agent communication
over MCP, which I think is a massive unlock.
I think it's a huge thing that will be super good, super widely
used in the long run. And we'll have actually in the
long run a lot of client support.
But the first iteration of it had issues and it was part of
the as an experimental change, the core.
And it turned out we were much better separating it from the
core into its own extension where it can be developed at its
own pace independently from the release cycle of the core in
there. Like basically iterates fast
enough to the point where we are back being able to move it into
the core because then we have confidence that it works the way
it works. And the extension is already the
now MCP task extension is significantly different from the
original experimental core piece that we have now moved out.
And so we want to basically just like let it cook, like let it
cook in the extension space, let it let people iterate, let
people play around with it. And once we were confidence in
the design, we've got to put it back into the core because that
is one of the pieces that does fit nicely into the like,
compose like it composes nicely with the rest of their the
primitives. Do you feel like that's a nice
pattern? Let it be an extension, kind of
prove out its value, and then merge it into core.
Do you see that? Being potential core pieces, yes
there are pieces like MCP apps or skills of MCP that will
always stay extension. Yeah.
But then there's other pieces that potentially could be core,
but instead of doing it like you did with tasks, you can let it
stand on its own 2 legs 1st and then go.
That makes a ton of sense. So I want to go into a few more
of these questions that are coming through.
By far, the most asked question is about the progressive
disclosure. Can you talk to us a bit about
that? Yeah, progressive disclosure I
think is an interesting case. So what people, and I'm curious
what your take is, what people actually mean by that, because
that first and foremost is like, what do people, what do people
actually think about what, what does this mean?
Progressive disclosure. Most of the time I've seen it
being mentioned, it refers to this notion of making sure that
the model learns about specific of a tool only when it needs it.
Because otherwise if you put all the tools into into the context
window, you get context bloat very quickly.
And so it's, it's less that the people are worried about like
the one progressive disclosure. They just think it's one
solution to the problem of context bloat.
Exactly. I wholeheartedly agree with
that. Right.
And so context bloat is context bloat is a, is a, in my mind an
interesting problem because there's a separation in my mind,
what does the protocol do versus what does the client do.
The protocol transports information.
It transports information about the tools available.
The problem we have seen is that naively most client implementers
take whatever comes over the protocol and just slap it into
the context window. And that is not necessarily at
the right approach. What you should do is you take
the protocol as an informative piece of like these are the
tools available, but I then choose techniques on my side, on
the client side that are avoiding this context bloat and
the two mechanisms that we found exceptionally useful and
basically use everywhere Cloud code does this and basically all
anthropic products do this is using tool search.
So like instead of putting the tools into the context window
right away, we are, we are putting it into effectively an
index. And the model has trained, it's
been trained to like search for certain tools when it thinks it
probably needs a tool. And that works quite well.
And it basically reduces your token usage as you would expect,
right? It's the exact, it's basically
effectively some form of progressive disclosure or
discovery from the model side. The second part of that is
programmatic tool calling, which is like how you combine or
compose tools together. Normally the traditional old
school way is the model runs inference, it spits something
out, it tells you to recall a tool.
You write, you call the tool, you give back the true results
to the model. Now the model says, oh, thank
you for the input. I'll call this other tool.
And So what the model effectively doing is it's
composing tools together in a quite inefficient manner because
it doesn't bear inference. And what you can do instead is
you can have the model optimistically write a piece of
code that says, take this now a JavaScript block that says call
this tool, take the output, parse it into Jason, put this
over there into this other tool, and then give me the output,
right? And so you have two tool calls
put together in a script and you execute that.
And that saves tools as well. And these two things to combine
are very, very, very effective like tool search plus and
programmatic tool calling to basically get rid of tool to
bloat. And so that's a long winded way
to say that I think 80% of the problems are client implemented
problems that they're not doing a good enough job skills issue.
That being said, I think there is an argument that we're slowly
coming around where it might be useful in certain situations
where the server offers, where the server authors knows better
about the shape of the problem. So it might wanna offer some
form of search or some form of progressive discovery, our
disclosure. And so we're thinking about some
of the primitives, but fundamentally it's to some
degree a client problem. Very proud of myself because in
my head, that's kind of what I was thinking.
I especially on those two where it's like, yeah, well, tool
search, I think Cloudflare was the first to popularize that,
right? I can't remember who.
Exactly, they did something called code mode which is what
the other word for programmatic. We did it around the same time I
think Cloudflare did the popular blog post about it.
Yeah, I knew one of those. I remember seeing that and
thinking, yeah, that makes sense, right?
And especially because I had been hearing murmurs in the
community of folks saying, well, you want to just bring the
abstraction layer up So you don't give them 90 tools and say
here is get Slack ID, here is send Slack message.
It's like you want to just figure out what's the intent and
create that from the intent as opposed to a million tools.
And then you got to choose one by one.
You have one tool that can cascade down.
And the search is, it's kind of obvious because that in a way is
very much progressive disclosure, just a different way
of doing progressive disclosure, right?
And we have seen, without going into too much details, we have,
we have seen a tool search plus programmatic tool calling can be
as good if not even better than for example, CLIS.
Yeah, I believe it. I believe it 100%.
And you know, I think the reason that folks felt like they were
getting this bloat in the beginning was because there was
so many community built servers that just went up so fast and
you would go and try and use them, but it was, they were
built so poorly without any idea of how to do any of this.
And so again, it goes back to that maturity.
If I used an MCP server that was built poorly back in the day, of
course I'm going to be complaining.
And GitHub was the notorious one who did this the worst because
they just threw all the tools into the and it was.
So that was what you're saying? Yeah.
And then part of that is like the the classic is like take an
open API spec and like transport it like transform it one to one
to MCP. And that's that's fundamentally
an anti pattern because it just leads to poor and to to very
poorly performing MCP servers that also have the problem that
the tools look similar enough that the model gets very easily
very confused about which tool to use.
So it's a bit of a, it's a bit of a you 100% right.
Like they're it was amplified by poor servers.
It was mostly amplified by poor client, yeah.
Yeah, it got it. You just didn't realize it until
later that, oh, this is a skills issue.
This is not the protocol necessarily that's causing these
problems. It's just that folks who didn't
really go deep into the protocol and figure out how to build it
properly or leverage what is there like this search.
And part of it is also learning honestly, like everybody learns
on it, right? Like when MCP came out, like how
many tools would you where you're using in a session like
10, right? Six months later, 12 months
later, MCP led to pro to a proliferation in the ecosystem,
right? And so some of the solutions are
needed because of MCP being part of the amplifier of tools.
And so it's a bit of a chicken egg type of problems.
I'm not worried. I'm not.
I don't. I'm less worried about that.
I think the client author didn't do it right from the beginning.
Completely normal. We all learn, we all do
iterative work. I think what I'm what I want to
make sure is I think a lot of people don't realize that the
situation gets significantly better and most clients don't
have this issue. At least most major clients
don't have this issue anymore. Speaking of which, we talk a lot
about like this forward compatibility.
You know, in software you have backwards compatibility.
That's a thing, obviously, but I've heard people talk about
forward compatibility, especially as you're building
and knowing, all right, there's certain things that I can build
this right now or I can wait six months and the models probably
going to be able to do it on its own.
And the classic examples of this are back in the day when folks
would try and do all these hacky moves to make the context window
bigger. Or I know people in certain
e-commerce stores who built their own MCP because they
didn't have that. And it's like, wow, if you just
waited a few months, MCP came out, it became popular.
So as you're looking at ways that things could now be forward
compatible, or as you're thinking through like what's
going to get better, where do you plan on, OK, this can get
better. Maybe you can build it right
now, or maybe you can wait six months, and at the rate of
change, it wouldn't be a far stretch to say that this is
going to be done. It's such a good question.
I think there's a lot of these kind of scenarios where you need
to be so careful and some of them you will get right, some of
them you will get wrong, right. And like the session piece, we
kind of got wrong, I guess in retrospective, right, or there
was a temporary thing. But another example is like,
people often ask us to do something what we, what they
originally called primitive grouping, which is like ADC,
allow tools to be grouped, right?
And that's super sensible. It's a very good use case.
There's a lot of use cases around this.
But if you think forward, you're like, OK, first of all, there's
two things to this. First of all, the models would
get really good and people will not select tools as a group in a
session anymore. Six months ago, 12 months ago,
you have to select tools in, you know, UI.
Nobody does this anymore. Nobody expects us to do this
anymore. And so these things will just go
away to some degree, right. At the same time, the models
will get better to reason based on the tool description about
the grouping that's there in the 1st place that you don't have to
spell it out as a, as a human or that the group might not be
relevant to the the problem that the user that the user has.
And if the model might find the different grouping mechanism.
I mean, in the second part of that is like a group is, is
nothing but like a tree with a with a like with a depth of 1
effectively. So there's a generalization
there that you need to be very mindful when you design
protocols. You need to think about like,
let's just generalize. Does it solve a problem?
It's never is is often the case is yes, but the problem is like,
is it solving all my problems in the future?
And the answer has in some sense, no.
And I need to that's the the hard one.
And then you need to go back and like, no, let's wait, let's see
if the model gets better. Let's see if how the world looks
like in six months. Let's see how we're, you know,
if we find a more general mechanism, even though it takes
a three months more and it's painful for the people wait for
the solution in the meantime. And I understand that, but
that's the that's the kind of role that you will wear
forward-looking is super important.
And I think these things are super interesting, but there are
like things that are pretty clear that there are no horizon,
right? Like we know that the task, the
length of a task that a model does is increasing, right?
It's kind of like linear increasing.
And we know this and we have that.
That hasn't stopped really since the years this increase.
So we know that like more long running tasks will just
increasingly more important because we will increasingly
less interact with a model in our chat environment because the
model will like, because the task the model will do will be
more asynchronously how we interact with humans and they go
away and do something and come back.
And so in that scenario, you're like, OK, I will need something
like tasks, right? Like I will need something like
that. I need to design it minimal and
make sure it can be extended because I need to look in the
future that I cannot predict, right?
Nobody knows what's happening in six months from now in the AI
field. So I will not know it either.
So do all I know is I need to do the minimal thing that I know I
can extend so I can solve future problems additively rather than
subtract like with a subtraction or removing things?
What do you think people don't understand about tasks?
I think Task is a poor name. It's a poor name and a good
name. It's a good name because it's
accurate and what it's trying to do.
It's poor. Maybe it does agent to agent
communication effectively and I think there's some open
questions there around. Is this the right format where
there's some shapes to be experimenting around with it.
But I think people really don't understand that what it
effectively allows you to do is have an agent talk to another
agent that that's effectively what it's doing.
I think it's doing it quite effectively.
But again, in the long tradition of MCP, we are in poor at naming
things. So we we shall continue in our
old tradition of continuing to name things, probably.
Dude, you know, so I'm not going to comment on the naming of MCP
because that's your business and I will let you have your fun
with it. But I will say the folks who
name things the best by far in my experience are the damn
researchers. Follow me on this one.
Hallucinations with models, right?
And then you have, what else do you have?
Catastrophic forgetting of models.
Give me a better name. Maybe we need a bit more drama.
Exactly. Catastrophically forgotten that
10. Mug Yeah, yeah, maybe, maybe,
maybe should go in. Next time you have a big naming
conundrum on your hands, just go walk around the office and find
a few of the researchers and say, like, what would you call
this? I love it.
I I should do it.
That's a good idea. We are, we are certainly.
We are not. We are good at a lot of things.
Naming is not one of them. That's for.
Sure, but it is hard dude. It is so.
I It's hard. Vibe with you 100% on that
because you're like yeah, that sounds good.
And then somebody comes up and they're like well does that mean
this? And you're like, that is not at
all what I thought it was going to mean.
How did? You get that where you start and
where you end up. These are two different things.
And the name has does not change while the expectation has.
So there's a. There's a fundamental issue
there as well. Oh well.
All right. So I want to shift towards Jason
and token usage a little bit because a question came through
about Jason, how verbose it is, how many tokens it uses.
Do you feel like there's a world and of course this may and is
probably stepping outside of MCP world potentially, but is there
a world where Jason is not there or there's something more
efficient? I, I do not know, I think the so
there's two things from the on the what is what is MCP using as
a transport mechanism? And that's independent from what
you give the model, right? You can take a Jason BLOB and if
the model accepts something else than Jason, you can transform
them. As long as it's a bi directional
mapping, which it should be, it should be fine.
So what do you get from MCP? Must must not necessarily what
you give to the model, what you give to the model.
I do I do not know what the what the most recent research about
this is. I do think Jason is has a lot of
benefits. It is actually quite, quite
compact by itself. Like people forgot the world
where XML was the big thing that was verbose in comparison.
So I think Jason's actually quite compact.
I do think that I'm that I'm usually looking at things about
less of a like token usage, but like how much tokens did I need
to get a task done like that I that I wanted to do.
And I do think like, while tool usage might be now, might be not
the perfect, most efficient thing to do as, as we do it now,
I think it's probably very good enough, given that the that the
that the cost per task done is, is, is decreasing as the models
are getting better, right? Like, and so I'm less worried
about it. I don't honestly really see it
as a, as a massive issue. And I think actually that you
what, what, what you can foresee a world where instead of like
using Jason as a tool calling mechanism, you just write code
that you execute, that the model just writes code that you
execute. That's another idea.
And that failed. And then your effective format
becomes a JavaScript or whatever you might choose.
And that is also maybe not the most efficient thing, but it is
the thing that the the model is really pretty good at because it
turns out there's a lot of Jason in the world.
And so again, this is a good research question.
I think it's I did does not feel to me like a particularly high
priority in the savings you're getting from being smart about
your context selection, about being smart about the way you
execute things, the things using tool searches and tool and
programmatic tool calling. I think those in general are
probably bigger savings in my mind intuitively than a specific
formatting questions to be honest.
And I do like this idea of hey, just because the transport layer
uses it doesn't mean you can't use something else.
Oh yeah, yeah, yeah. But this is the thing, right?
MCP like that's maybe one of the biggest misunderstandings for
them to be people think is like that's what the model interact
with. That's not true.
It's what the application around interact with.
It's a pure it's a very old school program, a talk to
program B and some form of information.
And that information does not need to be the same thing that
goes into the true calling. It turns out that the format
that we chose is clearly the same format that like an open AI
or Anthropic API would expect to do.
Which is very convenient for people to do, but it does not
stop you to experiment with other things.
So anyway. Let's hit on observability
because this question came through and I, I really liked it
as far as like as agents start using multiple MCP servers and
then they're chaining the different tool calls, debugging
becomes difficult. You had mentioned earlier about
the ID session that potentially feels like it could be a little
bit of traces happening, but incorrect tool selection might
be there. Also, you have MCP server
failures. Do you see a world where your
standardized tracing or is this again something that you're like
that shouldn't be on us, that needs to be something else?
Two things that first of all, I think in a, in a more general
tracing mechanics, I don't think that's an MCP problem.
I think because there are aspects within the execution of
a of an of a model that are not MCP that you still want to
trace. And so those would be different
things. But at the same time, within
MCP, there's open telemetry standards that he should be
using. And so there are some of the
things that that we can do and, and should do.
But again, they're on the MCP layer.
And the MCP layer is just part of the general execution of, of
like a model loop and not the full loop.
And for that, you know, different model providers offer
different abilities to introspect this or write trans
transcriptions or something like that.
And that really depends. I if I'm not sure if there will
be an open centered, I don't know if there there should be.
If anything, I think should be something out of something like
an open telemetry to some degree.
I'm not sure if that's enough, if there might be more
additional information needed. There's always a challenge here,
particularly when you're dealing with raw unstructured text,
which effectively models are, is being careful about privacy and
data retention implications while being useful at the same
time, right. And the, the most useful tracing
you can do is trace everything, right?
That, that, that would of course include things that you probably
don't want to trace for the sake of your users.
And so there's trade-offs to be done.
Again, on the on the MCP side, there's a lot of open telemetry
work around. The open telemetry people have
some form of standards around how you trace MCP servers and
and a lot of the the the typical server and client SDKS do have
traceability functionality in it.
On the general thing, I do not know if there should be an open
standard or not. It's something that's not top of
my mind. It could be.
Yeah, it's outside of your scope.
You you just need to focus on naming properly and that's going
to get you way farther. So when will MCP be done?
Is there ever a finished state? How's the vision and mission set
for that type of thing or is it continuously going to go?
Do you feel like you're going to be able to put your feet up and
relax at any point if it gets to certain place?
I, I think there's, there's a world where the core part of it
will be kind of done. I, I think it's actually not
that far away. I think they're the, there's
things we need to do, but the general core pieces seem to get
into a reasonable good shape there.
It feels to me it might relate similar to how you see a lot of
standards, like for example, our authorization, others happen
where there will be a a small use case that someone has and
they will want to build an extension and to the protocol
and then they will make this a thing.
And then that's an important thing to do.
So there's a lot of there's a lot of like in the last 20% of
use cases, there's a lot there that still needs to be done.
Those will likely be done during extension.
And I think that has I do not see that to slow down.
There's so many open questions like how do you deal around
guardrails? How do you deal with the
compliance problems and regulator regulatory problems.
There's, there's is a extension called Interceptors that is
proposed by by the financial interest group at the MCP
project, which is mostly like consists of the Bloomberg, the
Capital One of the world, who all have very interesting, very
valid problems. And I think that will these kind
of senses will continue. There will be, you know, you
can, you can afford, I do not know, but like, for example, you
can think about like an extension that will do something
like A to UI and MCP where you are allowed to do the I
components that can be rendered in a terminal.
But there's a lot of these use cases that's awesome that I
think can happen. But I think they will happen in
an an extension type of way where the core hopefully should
be stable. That's the goal.
Like protocols like MCP thrive from from stability.
And most importantly, protocols like MCP have a budget of how
willing the ecosystem is to change.
And that budget is pretty much directly correlated with the
amount of attention the project has.
And the project has a lot of attention in year 1.
It has more some attention in year 2.
It will have less attention in Year 3 because it will just be a
standard part of the stack, and that's fine.
And that means that people do not want to change the center
part of the stack because they're thinking about something
else. Incredible, man.
Well, this has been great chatting with you.
I will say that you're going to be giving talks at the MCP Dev
Summit that we're doing right. You're coming to Japan.
I'm coming to Japan, I'm coming to Amsterdam, I think the week
after a few days later and then I'm going to be in October and
some some Jose at the the big Asian comp.
Well, it's. Going to be there batting.
With you, I'm going to be at all of those.
I'm going to be. I'll try and corral you when
we're there and. Are you going to go to even
more? Are you going to go to the the
Seoul one of the? Nairobi one, I am going to
Korea. I'm very excited for that
because I've never been to Korea.
I'm pretty sad I miss out of Korea.
I really like, I really like myself some some Korean food and
like watching some some E sports life and stuff like that.
I want to watch robots. Literally just saw as I was
boarding the plane to Lisbon that robot soccer has become
very popular now because of the World Cup, but Korea's not
playing anymore in it, so they're enjoying robot football,
so that's pretty good. Yeah, I've been to Korea before.
It's a great place, man. I'm I'm hope you're going to
enjoy it. Yeah, that should be fun and
we'll hear how people are using MCP over there.
So that should be fun. And then the big release is
coming out. So folks, let us know what you
think and we will. The 28th of of July comes the
release and then was that the the version true of all the
SDKS, which I think is the the thing that for developers matter
the most. Yeah, I really hope that
everybody's going to upgrade their MCP servers.
Give us feedback comes to the community.
We're we're actually I think a quite a friendly bunch.
We're busy, but we are friendly bunch and trying to listen to
everyone and understand what they're coming from.
So bring the problems, bring the ideas.
A lot of the things that are in this protocol revision are not
things that came out of my head. There are problems that other
people brought to us and that we're working on.
So yeah, bring the back the feedback, update your servers,
update your clients, and yeah, I'm super, super stoked and see
where the ecosystem is going then.
That's the beauty of open source.