One Year of MCP — with David Soria Parria and AAIF leads from OpenAI, Goose, Linux Foundation

Host

And here we are, joined finally in the studio for the first time. Welcome back, David, from Anthropic and MCP.

Yeah. Nice to finally talk to you in person. Last time, about a year ago, it was over VC, and this is way more fun.

Host

I watched it back—those 8 months. It’s been a crazy 8 months, and I think we just celebrated the 1-year anniversary of MCP.

Yes, we have—at least a public announcement. Also, last night—or yesterday—was the Agentic AI Foundation launch.

Host

Yeah, that was nice. It was a nice event. It was nice to see the Anthropic office. Very good food, I would say. In terms of my food benchmark, Anthropic does rank over OpenAI.

At least that’s what we have going for us.

Awesome, man. Do you want to give just a quick overview of what’s happening with MCP and how you’re donating it to the foundation? Then we’ll do a 1-year recap of the protocol itself, and after that we’ll have the rest of the leads from the foundation join us to talk at a higher level.

Yeah, that sounds good. Where we are at the moment: we launched MCP a year ago, and we’ve had this crazy adoption over the last year. It felt like an eternity, honestly, but we’ve had this crazy growth and adoption, initially through Thanksgiving and Christmas, with a lot of builders building MCP.

Then we had the first big clients coming in, like Cursor and VS Code. Then there was this inflection point around April, with Sam Altman, Satya Nadella, and Sundar Pichai all posting about MCP and saying that they were going to adopt MCP at Microsoft, Google, and OpenAI. That was really the big inflection point.

Yeah.

But in all of that time, we also had to do a lot of work on the protocol itself. We launched originally as basically local-only: you could build local MCP servers for Claude Desktop. Then, in March, we moved into how you could do remote MCP servers—really connect to a remote server—and introduced the first iteration of authentication.

In June, we revisited that and improved it quite a bit so that it worked better for enterprises in particular. We were very, very lucky that, from March to June, we were able to have absolute industry-leading experts who literally work on OAuth itself help us with some of the pieces and how to get it right. We focused a lot on security best practices and this type of work.

Now I feel we have a really solid foundation. We just launched, at the end of November, the recent iteration of the protocol—the next big improvement—which is long-running tasks, to really allow for deep-research-type tasks and maybe even agent-to-agent communication. I think we’re stepping into this territory now where we have really solid foundations. We have 1 more big primitive we want to have, and we want to make a little more scalability work. Then we’re going to get into a phase where it probably becomes a bit more stable.

It’s been an absolutely crazy year, man.

Host

You did say agent-to-agent, so there is an A2A protocol. I’m curious: when the Agentic AI Foundation got formed, was there any discussion about any of these other protocols being a part of it? Sean wrote a post called “YMCP1” already.

Host

One of my favorite posts.

Maybe it already was, and it was before Sam and all the other guys.

Yeah. You were right.

Host

Well, I think it was just obvious that was going to happen.

We of course have conversations around what else is in the market. There are payment protocols that are interesting, and so on. But when we wanted to start a foundation, we wanted to make sure of 2 things.

First of all, we wanted to start small and make sure that the group founding this—for us, it’s the first time Anthropic has had an open-source foundation, so this is all new to us—was learning along the way and able to shepherd this in the way we feel is best for the industry, together with OpenAI and Block.

But the second part is that we really felt we wanted to see things that have a lot of adoption, or, at least on the protocol side, a de facto standard. I don’t think any of the other protocols feel like they’re quite there yet. But of course, if they get there, we’re super open, as long as they’re complementary to what’s in the foundation.

On the application side, we’re a little more flexible and open. On the protocol side, I think we want to make sure the foundation doesn’t encompass 5 protocols for the same communication layer. There was discussion, but for now we just want to start small.

Host

Is there a role, like a double hat, that you have now with the foundation, or are you more focused on MCP?

I am still mostly focused on MCP. It’s a bit of a double hat. People need to understand that the foundation part is mostly just an umbrella to make sure the projects under it always stay neutral. I think that’s really the most important part, because the rest of it is, okay, how do we use the budget of the foundation for events and things that are quite dry?

The technical parts, like MCP, actually stay the same. In terms of the way we govern MCP, nothing has really changed. That’s still my job as the lead core maintainer: shepherding the processes and shepherding the protocol forward.

Beyond that, the additional double role is that I’m also going to be on the technical steering committee of the foundation. That will figure out what projects we want to have in the foundation. If someone comes with a project to us, the people who have projects in it will decide: Is this something we would want? Is this something that we feel is well maintained, has a lot of adoption, and isn’t going to go away?

We want to make sure the foundation has super-interesting and important projects and isn’t a dumping ground, like some foundations might have ended up with.

That’s true. We’re going to meet some of the others later, but maybe we’ll focus back on MCP development. You covered a lot. There have been 4 spec releases.

That’s a lot.

Host

Yeah. Some people may have missed some of them, is what I’m saying. I think it’s really interesting how we’ve continued to work on important parts. I always think it’s very hard to follow up a major success with a sequel, because it’s hard to repeat that impact. But I think every single time you’ve actually managed to focus on something important.

Yeah.

Maybe we’ll start with the March May one, which was Streamable HTTP, and the OAuth spec. I don’t know if you want to highlight any others, but we’ll just catch people up on that stuff.

Yeah, that was such an important one.

Host

It was the number 1 requested thing.

Yeah. It really opened up this remote thing. We already knew in December and November that the next big thing would be how to do this remotely, and authentication is quite important.

One thing I think people very rarely notice when it comes to MCP is that MCP is very prescriptive in each layer. Other protocols are not like that. For example, if you want to do authentication when the client and the server don’t know each other, you need to do OAuth, right?

We wanted very early to have 1 way to do something. We focused on what this meant, how to get it over the wire, how to build a protocol that had the streaming properties we required, and how to do authentication.

In the first iteration, I think we did an okay job with authentication, but we got some aspects wrong. Most of them, honestly, were just me not understanding enterprises well enough. But the strength that we have with MCP—and the 1 thing, if anything, I’m proud of—is building a community of people who can come together and help me figure things out.

I have my set of experiences and what I’m good at. Enterprise authentication turns out not to be one of them, but there are way better-suited people for that. That’s what we did in March.

Host

I saw you post that, but I didn’t really dig into the details. Was it the typical SSO-type authentication issue?

The main issue we had is that, in OAuth, there are 2 components. There’s an authentication server that gives you the token, and then there’s the resource server.

It takes the token and gives you the resource in return. In the first iteration of our authentication spec, we combined them together into the MCP server, which, if you were building—

Unusable, yeah.

It's kind of usable if you build an MCP server as a public server. If you're a startup building a server for yourself and you want to bind this to the accounts you already have, that is completely usable. The reality in enterprises is that you don't authenticate—you authenticate with some central entity. You have some identity provider, or IdP, and for most people, they don't even notice that's happening.

All they know is, “In the morning, I'm going to log in with Google and then get access to all my work stuff,” right? But that's effectively the IdP. If you combine these into the same server, you just can't do this anymore. So all we needed to do was say, “Okay, we are a resource server. The MCP server is a resource server. Here's how you get the token from the authentication server.” We have opinions on how you should do it, but it's kind of separated.

And that's what happened in the June spec, where we separated this out and worked through all of these questions, like how you do dynamic client registration and other aspects, which were also part of the March spec. We can talk about that; that's a whole other story of how we're actually pushing the boundaries of what OAuth can do with MCP, because we're trying something very unique with MCP. But, yeah, that was the big part in March: the first iteration of the authentication spec, and then fixing it in June.

Host

What's the state of agents authenticating on my behalf? Because even today with OAuth, I still have to log into Linear and whatnot.

OAuth is, for the most part, a very human-centric protocol. It just tells you how you obtain a token if you don't have one. Once you have a token, it doesn't matter; you just put it into the bearer token. So we're not very prescriptive about what agent-to-agent authentication or authentication on behalf of agents would look like. There are ideas that we're looking into, and I don't have all the specifics, but we're not prescriptive in the same way we're prescriptive with OAuth.

Technically, at the moment you have a token that might be bound to a workload identity or something like that, you can still pass it to the MCP server.

We're just not telling you how to obtain it just yet, so we're not prescriptive. People do this, and they can do it particularly when they're within an enterprise and have a somewhat closed ecosystem. But if the client and the server don't know each other, we just don't have a good solution for now.

Host

Yep. And then, on the remote thing, you went from local servers like stdio to streamable HTTP. Any learnings you want to call out there? Any regrets or learnings for others?

The transport discussion has never stopped. From the very beginning of last year, we've been talking about transport, and we literally just spent the last 2 days at the Google offices with a bunch of senior engineers from Google, Microsoft, AWS, Anthropic, and OpenAI, discussing what we need to do here to really, really make this solid.

When we looked into March, we wanted to get a transport going that basically retained a lot of the properties we had from stdio, because we really—and I still believe this today—think that MCP should also enable agents, and agents are inherently somewhat stateful. There's some form of long-term communication going between the client and the server, and so we always looked for something like that.

We also looked into alternatives. What happens if we do WebSockets, for example? We found a lot of issues with doing a proper bidirectional stream, and we thought, “Okay, what is the right middle ground between having something that can be used in the simplest form, where people just want to provide a tool, but then is able to be upgraded to a full bidirectional stream if you need it because you really have complex agents communicating with each other?” That's where streamable HTTP was born, with that intent.

And I think, in retrospect, we got something right and something wrong. I think we got it right that we're really leaning just on standard HTTP in that regard. We got it wrong that we made a lot of things optional for clients to do. The client can connect and open this return stream from the server, but it doesn't have to, and the reality is that no client does it because it's optional.

So a lot of the bidirectionality goes away. Features like elicitations and sampling are just not available to servers because the client doesn't have that stream open. The client implementer is like, “Ah, that's the minimum viable product for me; I don't have to do it,” and so that became an issue.

The second part of the lesson is that the way we designed the protocol, the transport protocol requires some form of holding state on the server side. That's fine if you have one server, but the moment you scale this horizontally across multiple pods in containers or something like that, now if you get a tool call, then an elicitation and an elicitation result, you might hit 2 different servers, and you need to find a way to have those 2 servers somehow get this result together.

You effectively need some form of shared state—Redis, Memcache, whatever you want, some form of shared state that you can use. That's kind of okay; we've seen this done in PHP and Python applications, but it's not fun if you do this at scale. We know from some companies, like Google and Microsoft, that they're doing MCP at a scale that I can't tell you the numbers, but it's in the millions of requests. So now it becomes a problem, right?

So now we're sitting here thinking, “Okay, how do you build an iteration of the protocol that allows for these principles: make it as simple as possible for simple MCP servers, but allow the full spectrum of really bidirectional streaming if you need it, and also make it scalable?” I think we're still trying to find the right solutions, but it's just complicated.

A lot of the technology today is really just—there's very little that does that. People either do the simple thing, like REST, or they do a full bidirectional stream, and then they're going to use WebSockets or gRPC and so on. We need kind of both.

Host

What's it like to be in that kind of meeting where you have all these impressive companies, everyone is senior, and everyone has an opinion? Is it much fun?

Yeah. I got to work with some of the best engineers in the industry. It's insane.

Okay. Well, who decides?

Usually, we're trying to get to consensus. The reality is that, technically, I decide at the end of the day, but I think that's more of a formalism. What you're trying to do is really narrow down what the real problems are, which we all agree on, what the things are where we don't necessarily agree, and then, within those bounds, build the best solution.

It takes a while and a lot of iterations, but it's so much fun because you get to see these unique problems from the companies. You see some of the identity of the companies in the problems themselves. Google has a different set of problems from Microsoft, and a lot of it comes from just their ways of building things. The problems from Anthropic look different from the problems from OpenAI.

What I love about all of this is that sometimes you step back and sit in a room with all these competitive companies, but you're actually building something together. I love that. I've been in open source for 25 years.

Yeah, it's very—I love this kind of stuff. When a standard works, this is the ideal—

These people are all amazing. I just learn so much from all my peers, so I'm very grateful to be in this situation.

Host

Yeah, this reminds me of the IETF standards process. Is there some discussion about how this works as a private group versus something more traditional?

It's an interesting one. It does look a little bit like the IETF. The IETF is very slightly different: it's an open forum where everybody can go. The result of that is that the IETF is very consensus-based and, by accident—not necessarily because they want to be—quite slow in its processes, which is very good in many ways.

It cannot be undone, right? Once it's up, it's—

Yeah, and, for example, when you look at the OAuth 2.1 spec, it's been in the works for 3 or 4 years, and they're just not done with it. That's the length of time that IETF standardization works; these things can take a long, long time. I think that's good for certain pieces, but I think AI at the moment is just moving so fast that you're somewhat forced to find a smaller group.

And so that's why we run MCP as a really traditional open-source project, with a core maintainer group of about 8 people that basically decide everything, and then input from everybody else. We get input, and people can make suggestions. A lot of the changes don't come from the core maintainers, but they are the ones who decide it, and that's way more—

It’s like a middle ground of being somewhat consensus-based but also somewhat like a bit of a dictatorship, which can be good if you want to move fast, which MCP wants to do at the moment.

Host

How do you balance the influence of model improvements with how to shape the protocol? Obviously, you have Anthropic and OpenAI—you guys are doing post-training on these models to make them better at tool calling—and you have preferences on the shape of the protocol, versus there are people who aren’t aware of how you’re structuring that. Do you share some of these? Does the protocol influence some of the model post-training, or vice versa, maybe?

I’m not 100% familiar. I’m a product person; I’m not fully familiar with everything we do on the research side, for sure. But it influences the post-training in the sense that we’re making use of things like MCP Atlas that we’re having in our model card, making sure that we’re taking this large set of tools in the wild and making sure our models work with that.

But I think the primitives of the protocol are actually very rarely influenced by model improvements. I think there’s a sense that we do anticipate the exponential curve that the models are on in terms of improvement, and that we’re relying to some degree on mechanics that you can put into the model training.

I’m going to get more concrete here. For example, people have had long conversations around context bloat of MCP servers. That happens because MCP opens up the door to a lot of tools. If you naively take all the tools and throw them into the context window, you just get a lot of bloat. It would be the equivalent of taking all the skills, taking all the Markdown files, and throwing them all into the context; you would also have a lot of bloat.

But we already knew—and I think we always knew—that you can do something like progressive discovery. That’s a general principle: you can give the model some information and let the model then decide to gain more information, right?

And of course, here is where we see some of the foresight, because we are the big model companies. We know that we can train this if we wanted to, and what the training does is just optimize it. The model can do it in principle already, right? Any model can do it if it does any type of tool calling, but if you train the model for it, it’s just better at it. These things then go hand in hand in a way.

But at the end of the day, the general mechanism of progressive disclosure is just inherent to any type of model that can do any type of tool calling. That makes sense.

Host

Yep. And I think the context rot point is important. I think then there’s the MCP-versus-code-mode thing, and it’s like, well, if Anthropic says code mode—and Anthropic made MCP—maybe is that the best way?

The blog post never actually called it code mode. That’s not what we called it. That’s it. People call it that; we call it programmatic tool calling, and others call it code. But at the end of the day, what it boils down to is this: MCP is a protocol between the AI application and servers. The model is technically not involved in MCP.

Now you have an application saying, “I have a bunch of tools. What can I do with them?” You can do the naive thing and say, “I have tools; I’ll throw them into the tools for the model and call them.” But you can be more creative with it. You can say, “Models are really good at writing code. What if I treat these like API calls?”

You give them to the model, and now the model generates code. What you’re effectively doing is composability that the model would have done anyway by calling tool A, getting the result, going back to inference to call B, and then combining it into call 3. All you’ve done is let the model optimize it in advance and put it into a bunch of code that is executed in a sandbox: call 1, put it into 2, put the results into 3, and get a result.

All you’ve done is an optimization at the end of the day. But the benefits of MCP—having authentication done for you, having something that is suited for the LLM, and having something that is automatically discoverable and self-documenting—those things have not gone away. That’s still MCP for you, right? You’re just using it in a different way.

So I’m always a little bit confused when people go, “But MCP—why? Why does it tell me that that doesn’t work? Does that mean MCP is useless?” No, it’s still there; it’s just a different use. I think you’ll see evolutions as we get better at how we use these models and the infrastructure around them gets a bit more mature.

You can suddenly assume that most AI applications will have some form of sandboxing for execution, and you can do a lot more fun stuff like that. But I don’t think the value of a protocol that connects the model to the outside world is gone because of it. I see it purely as an optimization, honestly—as a token optimization.

Host

This is a good time to bring up skills. Skills are always awesome.

Skills are a more recent concept.

Host

Yeah. I only bring it up because it’s mentally linked in my mind to progressive disclosure and to adding preset code scripts and all that. Skills can also create skills, which is very fun. I think a lot of people are trying to place MCP versus skills. Obviously, they’re not overlapping, but how do you view it?

Yeah, I agree. I think that’s the interesting part: they’re not overlapping. I think they solve different things. Skills are super great, and I think the first principle they’ve really been built from is progressive disclosure. But the mechanism of progressive disclosure is just universal to any type of thing you can do with a model.

What skills do is give you the domain knowledge for a specific set of tasks: how you behave, how the model should behave as a data scientist, or how the model should behave as an accountant or whatever. But MCP gives you the connectivity of the actual actions that you can take with the outside world.

I think they’re somewhat orthogonal. Skills really give you this domain knowledge—it’s kind of vertical—and MCP gives you this horizontal of, “Okay, give me that one action.” Of course, skills can take actions. They can take actions because you can have code and scripts in there, and that’s great.

But there are 2 interesting aspects. The first one is that you need an execution environment, so you need a machine. That’s perfectly fine if you run local Claude Code or something. We can talk about the CLI, for example, in those scenarios where you have an execution environment. These things make a lot of sense. If you have a remote execution environment, then it makes a lot of sense as well, but you still don’t get authentication in that regard.

What I think MCP brings is the authentication piece. It also means that you don’t have to deal with an external person. For example, if you have a Linear MCP server, they can improve the server, and you don’t have to deal with that in your skill, right? It’s not fixed in space.

And then the third part is that you don’t necessarily need an execution environment, because the execution environment is effectively somewhere else on the server. If you build a web application or a mobile application, these things work better in some of these regards.

So I think they are orthogonal for the most part. I’ve seen some quite cool deployments where people use skills to explore different functions—the accountant, the engineer, the data scientist—and then use MCP servers to connect these skills to the actual data sources within the company. I think that’s a really fun model, and that’s the closest to how I think about this.

Yeah. So MCP is the connectivity layer. I think that’s the word that you choose.

The communication layer.

Communication layer, yeah. Architecturally, I’m wondering if it’s the MCP client inside of each skill, or if there’s a shared client that can discover skills.

We do that as a shared one. I think you technically want more shared ones, because the more shared you have, the better. The more you can do discovery things, like, “Okay, I have connection pooling. I can do automatic discovery of things.” I can even, in a skill, very loosely describe what I want, and then look into the registry that I have access to and get an MCP server for you.

These are things you can do when you do that, but I think both work at the end of the day. These are things to experiment with.

Host

I do want to highlight for people who might have missed it: when you say, “We do this,” I think nobody understands enough how much Anthropic dogfoods MCP. I only understood this when I watched John Welsh give his talk, where he said, “Yeah, we have an MCP gateway. Everything goes through this.”

Yeah.

Host

What can you say more about that?

Yeah.

We use both, right? We use a lot of skills internally. We use a lot of MCP servers internally because, obviously, you want to make it very easy for people to deploy MCP. You want to have some form of integration with your IdPs and so on. So we have a gateway that we've purpose-built for ourselves, and you just have to deploy your MCP servers.

And it's all internal apps.

It's all internal stuff. Yeah, yeah. Some of them are external things—technically external things—but in the absence of them offering a first-party one, we have our own. We have a Slack MCP server, which I love to use to have Claude summarize my Slack for me. So there's quite a lot of usage for that.

We even have an MCP server for a semiannual survey, for example, around how we feel about the company, the future, AI, safety, and these types of things. They can ask a lot of questions about the results, which is really fun.

Is it your team maintaining it?

No, we maintain a gateway, but I think one of the fun parts is that when we started MCP—it was always MCP; before we even open-sourced it, it was born out of the idea of: I'm in a company that's growing like crazy. I'm on the development side of things, the development tooling side of things. I will grow slower than the rest. How can I build something that they can all build for themselves?

That's really the origin story of MCP. So it's fun to see a year later that that's what's actually going on: people build MCP servers for themselves. I probably don't even know 90% of the MCP servers that are built on top of it, because they might be in research and I might not even see them, or I just don't know because people build for themselves.

But do they host it themselves? Is there a remote option?

They effectively have a command to launch it, and it just launches in a Kubernetes cluster for them. So it's partially managed. Yeah, that's good infrastructure for anyone at a large company to build any platform infrastructure, and some platforms offer that to you. For us, from a security perspective, we want to build these ourselves.

But Jeremiah, who built FastMCP, has a company that offers FastMCP Cloud, which is a little bit like that. You just use 2 commands and you have a running instance of an MCP server that speaks Streamable HTTP. A lot of enterprises use things like LiteLLM as a gateway, and then they can even launch stdio servers, attach them to the gateway, and the gateway does all the authentication—all the hard parts of MCP—for them.

There are a lot of ways to do this, but that's good infrastructure you really want to have: make it trivial, make it 1 command to launch an MCP server that was a stdio server, and suddenly it's a Streamable HTTP server with authentication integrated. You, as an end developer, only had to do the standard part.

Yeah, I love calling that stack out because people will take that and actually put it into their companies. Otherwise, the alternative is chaos—reinventing everything. Shout-out to Jeremiah. I actually invited him to do a workshop on FastMCP at my New York summit recently.

He had a very great blog post about a lot of the usage of MCP we're actually seeing being internal in companies, and that's actually what we see at the moment too, which is really cool. In what companies?

Internally in companies—in big enterprises—you see MCP everywhere, and it's actually growing way faster than you would think because it's mostly internal to companies and people aren't seeing it.

Host

About discovery: you launched a registry. There were registry companies, there were gateway companies. The official registry now has other registries putting their own MCP servers in your official registry.

Host

You need more registries, man.

[laughter]

Just 1 more, bro. 1 more.

Yeah. What's the—

Host

Registry to rule them all?

Any learning from that? Like launching a registry for a new technology, and whether or not people use it? Smithery is one example, right? If you go on the official registry, all these Smithery AI MCPs require you to authenticate through them. So it's kind of like just a passthrough registry in a way. How do you see this shaking out?

I think we saw a lot of these different registries come up, and we really felt that there is a need for basically an npm kind of approach to this, where there's 1 more central entity where everybody can publish an MCP server. That's really where the original registry came from.

We wanted to make sure that at least we're encouraging the ecosystem to have a common standard for what these registries can talk to, because what we want to do is live in a world where a model can auto-select an MCP server from a registry, install it, and then, for the given task you have at hand, just use it. It should kind of feel like magic, but for that you need some form of standardized interface.

That was really the inflection point. We started quite early working with the GitHub folks, even in April, and then I got distracted with other things, like authentication, and worked on that. What I want to see—and I think where this is slowly heading—is a world where we have the official registry, where everybody can put their MCP server, but this is the equivalent of npm, which has the exact same problems as npm: everybody can put it there, and you don't know what to trust and what not to trust. You have supply-chain attacks; these are just fundamental properties of public registries.

That's why we have this concept of subregistries, which Smithery and others can hopefully provide, where they can filter and curate on top of it. That's really the world we want to live in. I don't think we're quite there yet, but we're slowly getting there.

The GitHub registry is curated from the official registry and speaks the same format as it. What we want is that you, as a company, can have an internal registry that's a secured form of the official one, plus maybe your own ones. It speaks the same API as the official registry, and if you have VS Code or anything else that wants to talk to a registry, you just connect it to yours and you're good to go. That's really what we want to do.

It's interesting because npm, in a way, is almost like a download gateway. I'm not really using npm for discovery that often; I don't go to npm and search for packages. I find them in other ways.

Yeah.

I'm interested in whether you see discovery as a core piece of the registry, or if you still assume that there's going to be some other way for the agent to discover them.

I do think discovery is important in the model world, but I think that's where it's different from npm, because we're building something for AI first and we can assume there's an intelligent model that knows what it wants. I think that's something that didn't exist before, right?

If you were to build modern package-management systems with models at heart, maybe you would take a similar approach: “Here's what I want to build. Just figure it out—I don't care what packages you install, just do it,” right? I mean, that's the equivalent in the end of the day.

But again, with a public registry, you should probably not do this because it's a dump—it's a dumping ground for everybody. You want to do it against a curated, trusted registry.

Host

I like your phrasing that the model knows what it wants.

Yeah.

Because I think there's a dream that people have that agents can use the MCP directories to discover new servers and install them for themselves. That seems like—

Host

Very AGI if it works.

Yes.

Host

But it may not work, and I wonder what needs to happen in order to do that.

I do think we need a good registry interface, on the one hand. The second part is just that we need to build for this and see what works and what doesn't.

Host

We need trust levels, maybe.

You definitely need trust levels. You need trust levels. You might need some form of—

Yeah, you need trust levels. You might need some form of signatures.

For example, one of the ideas—I'm not sure if we're going to do it; just a random idea—but one of the ideas I always had is that you can attach signatures from different model providers that have scanned this MCP server and say, “We trust this.” Here's the signature from Anthropic that these tool descriptions are safe, and here's the signature from OpenAI that these are trusted by us, and then you can decide. Wow. So I think this is distributed code signing.

Maybe. [laughter]

And it's not really distributed; it's just central in a way, right? But I think this is the kind of stuff you'll require. In the simplest form, what you can do—and where you'll probably see it first—is internally to a company, where you have inherent trust, because they will use a private registry.

They're effectively using private registries already for npm; they're using them for PyPI, and they will also do it for MCP servers. In there, you have implicit trust, and then you can just search.

Host

Yeah, right. I think that’s really the interesting ground where we want to experiment. We have our internal registry, effectively, because when you launch an MCP server via John’s infrastructure, it gets registered, right? So we need to go and experiment with that, too.

Host

I actually wanted to ask you about that, too. You started running some events over in London. You had the Agents Hackathon and the Dev Summit that you called out on your timeline. I just wanted to get anecdotal stories about what you learned as you saw the community spring to life.

So we had 2 big summits this year. We had the MCP Dev Summit in San Francisco.

Host

And the one in London, too.

And the one in London. I think what you learn is a few things. One thing that’s very hard to get otherwise is these stories about how people use it internally in their companies. There, you see some of the struggles, but you also see some of the success stories.

One of the interesting bits, which I really loved, is that, particularly in London, you had a lot of people from financial services there because it’s clearly a financial hub. The whole conference was in the financial district, and learning about the kinds of problems—things you need to enforce because of legal contracts and financial regulations—was fascinating. These were things I didn’t know before, and I learned a lot about what a communication layer like MCP needs to look like when you have constraints that don’t exist in the normal development world.

For example, if you’re in financial services and exposing some data, that data might be coming from a third party, and you must guarantee that you attribute that third party. That’s a legal contract: if a client displays this data, it must tell you that it came from this third party, right? These are constraints that just don’t really exist in the normal development world. But in the financial industry, this is legally enforced.

So you’re thinking, okay, how will this work in a world with MCP? That’s when we started creating this financial services interest group that Bloomberg is heading up, to figure out what a client must do if it wants to speak to our financial services MCP server, for example, and what needs to be respected. These are the kinds of things you only learn on the ground, at conferences, talking to people.

The other thing you see is just how many people are building, and the excitement and creativity that some people bring to this. I love that, especially when it comes from areas you didn’t expect. I loved the people at Turkish Airlines who built the Turkish Airlines MCP server, where you can search for flights and things like that.

I love when people bring really creative ideas to the MCP ecosystem. I love it when the community comes together because you’re meeting people and ideas that are a little bit outside of your bubble, and you get some input. I think there’s a lot of learning there. We’re going to repeat it in New York in April, I think, or March or something like that, and then we’re going to do it again 6 months later. I absolutely love that.

Host

Any good sampling use cases that you found?

Not so much.

Host

That’s always the thing. Last time we talked about sampling a little bit, man. I think one thing I learned from sampling is that everyone wants to use tools with sampling, including tools that aren’t exposed via the MCP server. When you want to do sampling, you want to have a set of new tools that you only want to use during that sample call, and we just had no ability to do it.

We just fixed this in this iteration, so we hope to see a bit more sampling use cases. You’ll find an MCP server that does it every now and then. But particularly as MCP servers have moved from being more local to being more remote, in remote cases it’s probably always better for you to bring an SDK because you have full control.

You can deploy it, deploy an API, and maybe even charge someone. In a local case, it’s really powerful because you’re shipping something to a lot of people, and you don’t know what model they have configured or what application they’ve plugged it into. It might be VS Code; it might be Claude Desktop.

In those cases, sampling is useful, but clients just don’t support it. Sampling is one of these things I’m still sad about. I still think it’s a very powerful idea, but you’ve got to win some and lose some.

No, no, but you’re also upgrading it.

My hopes are still up there, and it’s—

Weird. In some ways, when you get it right, this will be the real agent-to-agent protocol.

Yes, yes.

Host

Are most of the use cases that you see still data consumption? That’s been my use case for MCP mostly—it’s about context, getting data. The most action MCP takes is updating the Linear task status. Have you seen very complex MCP action workflows, or are people still mostly using it for context?

Most people use it for context. I think that’s the vast majority of usage.

Host

It is in the name: model context.

Yeah. Nick Cooper from OpenAI always keeps telling me, rightfully so, that the name MCP was probably a little poorly chosen because it feels like it restricts it a little bit. I agree with that. It’s mostly data use cases.

I’ve seen people doing deep research via it. I think people expose agents via it, so they’re a little bit more complex, but it’s not super common. People have experimented with it, and the deep-research use case is a good one. It’s not too uncommon for people to do custom research.

Host

Beyond data and deep-research use cases, you now have this new aspect where people expose UI components through MCP-UI, or what we’re going to call MCP Apps in the future.

I think that’s super, super promising, and I think it’s really quite fun. That’s actually something you see a lot now with chat apps and MCP Apps in general.

Host

Yeah. You have Tasks in the latest spec, right? I’m curious because if most use cases are about context and then you build Tasks, it seems like people aren’t really using it for tasks. I’m curious how you designed it and what you expect people to use it for.

We designed Tasks because people come to us and say, “We really want a long-running operation,” which is basically agents. We want a long-running, deep-research task that finishes in an hour. We want tasks that might not finish within a day, right?

People have awkwardly tried to do this with our tools, and you can, because tools are effectively just an RPC interface at the end of the day. But it gets awkward very quickly because now the model needs to understand, “Oh, I need to poll this.” It’s just not very fun; it’s not a first-class primitive, and you run into a lot of limitations.

It comes from the fact that people want long-running agents. That’s something we heard from so many areas, and we saw so many people trying to do this that we really felt we needed to do something like Tasks. In GitHub issues from big companies, everybody was saying that long-running operations were really top of mind.

I really think we’re going to see a lot of it now, but it’s a little early to see how well it’s going to go because it just landed in the SDKs, and it needs to land in the clients. Then we’re going to see more of it. I definitely think you’ll see a lot of the custom-research use cases in other areas.

Host

Yeah, I’m very bullish on Tasks. I think it was very important to get right. Basically, every orchestration or protocol needs a sync version and an async version.

Host

Yeah, exactly. On the basic version, were there any design choices you want to call out? Were there 2 directions and you picked one in the overall design of Tasks?

In the design, there was a lot of conversation. Some people asked whether this was just asynchronous tools, or whether we should use different primitives. In the end, it was important to me—my litmus test was always—that if I wanted to expose something like Claude Code or any other coding agent as an MCP server, hypothetically, this needed to work.

A purely asynchronous tool call wouldn’t do this. You want some form of operation that can return intermediate results. In the long term, we want to be able to say, “I got to this result by calling this tool, this tool, and this tool. I had this other input, I had this other tool, I did this, and now this is the result,” right?

That’s really what you want to expose. Tasks is early, and it doesn’t do that just yet, but it’s built in a way that will be generic enough to support this. That was the main constraint. The other constraint was making sure it wasn’t just a copy of tools with slightly different semantics.

But instead, what it's doing is this: you can create a task by calling a tool with a certain set of metadata fields, and then it automatically creates a task. The task itself is just the concept of a container for doing something asynchronously, from starting here to ending here, and the thing we're doing is a tool call. I mean, that opens the door to later plugging in other things, and maybe even other tasks.

Host

Like observability as well, potentially, which is obviously going to be important.

So I think that was really the design goal, which makes it a little bit more abstract and a little bit more complicated to implement. But that goes away because the SDKs just do it for you, and then over there you just async-call this and return something. I mean, there you start to overlap with other async things, like tRPC in JavaScript land or whatever gRPC protobuf stuff that Go people have.

Yeah. At the end of the day, it's designed like a classic operating system interface: you create a task, you poll it until it's done, and then you can make an optimization—which we're going to do in the next round, which we didn't get around to—where, instead of having to poll every minute or hour, or whatever interval you choose, the server can call us with events, call a webhook or something, and go, “I'm done.” That's the optimization, but the actual core interface is always that the client can poll.

That's actually how a classic filesystem operation on an operating system can work: you poll, “Has the file changed? Has the file changed?” But you can also use a modern interface on the kernel, like inotify or io_uring or something like that, that tells you, “Oh, I'm done.”

Host

Great.

The file has changed.

There's a trick I learned where servers can hold the HTTP connection until it's done, and then they terminate it. That's the signal to the backend.

Yeah, which we don't necessarily want to do, because it might take a few days, and I don't know what people—

It's very irresponsible, but it's cool.

Yeah. There are plenty of ways. I think we were just going to go the webhook way, honestly.

Tasks are really interesting, and we basically had to invent this when we did the Devin API at Cognition. I think that's also an interesting reinvention of the fact that everyone is going to need some kind of long-running operation, and when you're calling an agent, you also need this.

Yeah. But the interesting part for us is that MCP is always trying to encapsulate what people are currently trying to do, and we don't want to be prescriptive about what you're supposed to do a year from now. We don't know. We don't predict.

We did tasks because people said, “We need this now,” right? We needed this basically 6 months ago, and we're like, “Okay, I guess now it's time to do this,” instead of trying to predict the future. That's why we're trying to keep the protocol somewhat minimal and, I think, to some degree achieve this, although other people would already think there are too many primitives in the protocol.

One minor thing: let's say it's a super long-running task. Lots of messages go back and forth. Anthropic was kind of a leader in context compression, or compaction—maybe let's just call it compaction—and I think a lot of the other labs are also doing the same thing.

Is there a way to handle that, or do we just statelessly cut context and it's fine? Do you need a full log of everything that happens, or no?

No, you don't. We just get stuff out. I think this is the thing: we're very early in the industry still. We're learning a lot about what the model does and doesn't need, and even today, some agents start to drop tool-call results after a few rounds because they don't need them anymore. I think that's very, very good.

Besides compaction, you'll see better mechanics for understanding what you need and what you don't need. For a long asynchronous task, you might have a way where, for a while, the model sees it, but once you get the result, you just drop everything else. You might even call a small model, like a Haiku model, and ask, “Of all this, what should I retain? Tell me.”

The AGI build approach might just be to let the model figure out what it needs to retain. You can see both worlds, and I think there's a lot to learn. There's not one answer yet, because we're still figuring these things out. Compaction is a good step, but I don't think it's the last step either.

It's the most obvious one, but I don't think it's the last one. If you pay more attention to it, particularly think about what you could train a model to do here, I think we get to much better ways of doing that. But they're all independent from how you obtain the context, and I think MCP, back to what I said, is an application-layer protocol. It's just how you obtain the context and how you select the context. That's a problem for the application, and that's a problem all the agent applications will have at the end of the day.

There will be a lot of different techniques. A year ago, everybody would have told you it was RAG-style stuff, which now apparently is dead. Now we use models and compaction, so I don't know what's going to happen a year from now.

Host

Cool. Around MCPs, another question I had is: how do you see them being used by developers to build AI apps versus being a protocol for AI consumers to plug things in? I think that's one of the main things people get wrong. It's like, “Well, I can just use a REST API. Why do I need MCP?” To me, it's almost like it's not really for developers to use; it's for people using AI tools to just plug things in.

I get the comparison with the REST API quite a lot, and I think there's interest. It's funny, because there are 2 problems in general. The first one is that REST does not tell you what to do about authentication. The second part is that everyone complains to me about tool bloat, but have you looked at the average OpenAPI spec length? If you put that into a model, you will have a lot of bloat there too—actually, way worse.

When people try to map things one-to-one, the model often gets slightly confused because you have “search by name,” “search by ID,” “search by something else,” and suddenly you have 5 tools that look very similar to each other. The model goes, “Which one do you want?” I have no clue anymore.

That's a side note to REST versus MCP, but I do want to live in a world where MCP is very much a consumer-focused thing. That's something consumers should know about. I want a world where you go to your application, say, “Do this,” and it should just do the thing. It should just connect to the right services, and the fact that MCP is under the hood is a detail that the developer needed to know about because that's the communication channel they're talking through.

At the end of the day, you just get the tasks done. I actually prefer a world where nobody—my mom, for example—should know what MCP is. If she wants to use Claude, the end of the—

Host

Yeah. Yeah. Well, from a developer-tool perspective, the new Chrome one is like the new meta. I also understand that, for developers, things like Claude Code locally can be better approached to some degree, and that's okay.

I'm curious about the MCP Apps UI with what you're talking about, where every client, like ChatGPT, has its own, right? So if I'm used to the MCP app of one product, but then I go into another, there's a different version that they've curated. It's kind of a different experience.

There are 2 influences. MCP-UI existed as a project, which had a lot of really good ideas. OpenAI took some of them and really improved upon them. One thing we just announced 3 weeks ago on the MCP blog is that we're actually working with both of them together to build a common standard.

Host

Write once, run everywhere.

We're really hoping that we're getting back to a world where you build for one platform and can use it across all of them, or you build for ChatGPT and might be able to use it in Claude or in Goose, or whatever program of your choice implements this.

But I think the general promise is that there are certain problems. If you think about a modern AI application, everything is very text-based, and that's okay. It's nice, but there are things that, as a human, you're just way better suited to do visually.

The most basic example is that you want to book a flight and select a seat. You now get to select the seat in text.

It’s like, here are the 25 seats you have available. Nobody wants to do that, right? I have no clue where these seats are even based on a drawing. And of course, you want an application that you can select with, or it might be a theater that you want to book for, or something like that. It’s so obvious that you do want to have some form of an application and a user interface that the model can navigate and interact with, but you as a human can also interact with at the same time.

And I think that’s what we’re looking for. I think it’s just this next iteration of building richer interfaces, because the pure text interface is somewhat limited and there are very natural things where, as a human, you’re just way better suited to do things visually. You see this in music production. You will see it, of course, with certain brands that will deeply care about presenting their interface. Shopping is a good example. Shopping has 20 years of A/B testing: what’s the best way to sell you something? Shopping interfaces are super complicated, actually, and you just want a way of displaying that to the user so it’s familiar to them and they can interact with it. And that’s what MCP Apps is, at the end of the day.

Host

Yeah. And, technically speaking, is the iframe the way they were thinking about it?

Yeah, it’s an iframe. You are serving basically raw HTML over an MCP resource. It goes into an iframe, and then it talks to the outside world via postMessage over a specific interface. What you can do now is, because it’s raw HTML and you’re not loading some external content, you can analyze it in advance for security if you wanted to. Because you have an iframe, the external application can just speak through a very clearly bounded, security-bounded interface.

Yeah, and this has been in browsers forever. I think I’m scared of it only because I hate CORS issues. Iframes always have CORS issues.

Yeah, but again, this does not load anything external. It surely should not, right? There probably are restrictions that we then iterate on, and in 5 years maybe it has 25 CORS headers and whatnot. But I think we’re starting small again: with pure raw HTML, you should probably not have external references, so you don’t run into these issues. But you’re right.

Host

And can I inherit styles?

No, in this iframe. I think you need to put it inline.

Yeah, you will want it. I feel like this is really minor, but UI people care about this. You have it—it should look like ChatGPT.

Yeah.

Inside of ChatGPT should look like Claude.

I think that’s a very good question. I 100% agree with you. Brands and others will deeply, deeply care about—

Designers will 100%. [laughter]

Yes. And that’s something we need to figure out. That’s where we need to get it out of the door, see how people use it, and then iterate on it.

Host

That’s why I don’t think it should be an iframe long term. I don’t know what the solution is, but we need a new iframe that lets some permeability because of this stuff.

Well, I think that’s sensible. Yes.

Well, I don’t know. But the other solution to the problem is the GUI-build approach: I just give it a tool that says, “Give me a style,” and the model can call you and tell you what you’re supposed to look like.

Okay. Should an MCP app know what it’s being used in? What the parent application is? You know what I mean?

It might be that the application also exposes tools, right, that the model is free to call.

Right. Right. Right. Okay. So maybe the standard is an interface for people to pass down styles.

Yeah. Maybe, I don’t know, but it’s a very big question. Let me ask the team. I’m mostly directly there; I’m not in the weeds of doing everything there.

Host

Yeah, it seems like a little bit of a surprise to me. I never really paid any attention to MCP-UI, and then suddenly you guys all adopted it. I was like, “Okay, well, I guess this is a part of MCP now.” And it went from a purely back-end concern to now the front end.

It’s also notable, technically, that it’s an extension to MCP. It’s not MCP MCP. That’s a pure technicality because—

It’s a governance thing, right?

Yeah. It’s mostly that if you are a client that can render HTML, then you might want to consider implementing it. But you’re still an MCP client if you don’t. The reality is, your average CLI agent can’t do it, right? So they will never do it. And I think that’s fine.

Are there any other extensions that are similar? We’ve got to look into financial services as an extension. You might end up in a world where, a year from now, there are clients that have certifications that they are an MCP client and get a signature that they’re financial-services MCP clients. They can prove it to the server, and only then does the server allow connections, because it knows they’re respecting these data contracts that you put into place.

You’ll see this everywhere. If you want to deal, in the long run, with public servers and public clients that deal with HIPAA data, like healthcare data, you will have to have guarantees. Isn’t it part of just auth or OAuth?

Not necessarily. I’ll give you an example. If I have a client that might need to have 5 servers installed, and there’s 1 healthcare server, that healthcare server might tell you, “You are not allowed in this session to use any of the other MCP servers,” because this data I’m giving you cannot leave. You must guarantee this data doesn’t go anywhere else because it’s HIPAA data, financial data, whatever it might be. This is a good example, and that might be some of the enforcements you need to do—

Because you don’t want your Social Security number or healthcare data to show up in your backend, right?

Awesome. We’re going to transition and have the rest of the AI group join, but any final call to action—either people that should join your team, people that should contribute to the MCP spec, or anything else?

I think the most important part is still building with MCP on a day-to-day basis, for people to just go out and build really good MCP servers. We see a lot of mediocre MCP servers, but also some very, very good ones. Just building good MCP servers and looking at how to use them—I think that’s super important.

The second aspect is that we’re a fairly open community, and we’re running it as a traditional open-source project based purely on what people are able to put in, in terms of effort and time. So just being an active part of it—either giving us feedback, being in the Discord channel, talking with us, giving us ideas, while also helping us implement the TypeScript SDKs and Python SDKs—we’re always looking for new SDKs, right? We have active Go SDK development, but we don’t have a Haskell SDK. I don’t know, if you’re a Haskell developer, maybe you want to write that, right?

Yeah, there you go. And so I think there’s a bunch of stuff we can do and be part of. Don’t underestimate how much you can just be part of the community, but also just go and build. I think there’s so much opportunity now, particularly to build amazing clients, now that we’ve understood progressive discovery better and understood code mode better. There’s just this next iteration of clients to build and the next iteration of servers to build that I’m looking forward to people doing.

Yeah. My last question, or call-out, is that I wanted people to hear directly from you. I sense the energy. I’m very excited by everything that you’re doing. But a lot of people are anxious about joining MCP and joining the Linux Foundation. They’re like, “Oh, is this Anthropic taking its eye off the ball?” Can you address those concerns?

Yeah, I love that you asked me that. I can totally see why people think that, but it’s actually quite the opposite. The commitment of Anthropic is the same, right? We still have the same people helping with the SDKs. We’re still super committed in our products to MCP. I’m still the lead core maintainer. Nothing has actually changed.

The foundation is mainly about 2 things. The number 1 is making sure that the whole industry knows that this will stay forever open, that this cannot be taken away. There have been histories of companies taking an open-source project and suddenly making it proprietary again.

We have protocols that are proprietary. Look at HDMI. What are the problems with HDMI in Linux?

What’s HDMI?

Uh—[laughter] HDMI 2.1. The HDMI Forum does not want to allow AMD to develop open-source Linux drivers for HDMI 2.1. Really, there’s some—look it up.

Wow.

So, you know, people keep a very close tab on it, and what this does is—no, this is now owned by a neutral entity. It will always stay open. You can use the word MCP. Nobody’s going to sue you over it.

So there's a bunch of that, just giving the ecosystem and the industry the confidence that this stays neutral. I think that's important. The second part to that is that I think one thing I'm, if anything, the most proud of is that I think we have set the tone for open standards in the industry and are now able to use that momentum to build community in a space where people can come and bring really well-done, well-supported, well-maintained projects and have them be part of this foundation.

I think that's the other part to that. But the funny part is that our bar for the foundation is going to be that it needs to be really well maintained. It's not like you're taking the ball off. That's exactly what we don't want, and so we will not do that. MCP is still core to the product and still super important, and Anthropic is still just as committed as we've ever been.

Amazing. Awesome. Thanks for joining, David. And we're here in the studio with core team members of the Agentic AI Foundation. It's the biggest panel we've ever had on the podcast. Welcome, guys. Maybe we can go left to right and have everyone introduce themselves, and also identify the voices for people listening on audio.

I'll start. I'm Jim Zemlin. I'm the CEO of the Linux Foundation. I've been working there 22 years, and I was the person who helped facilitate the launch of the foundation. But take no credit for any of the technology work that's to my left.

I'm Nick Cooper from OpenAI. I've been there just over 2 years now, I think. I'm generally OpenAI's head of a lot of protocol things and very interested in the open ecosystem. I'm our representative for the Agentic AI Foundation, as well as a core contributor to MCP.

Got it. What's another protocol that might fall under that umbrella?

AGENTS.md, just in general. Not just the protocols, but also the product experiences of where OpenAI products intersect with other SaaS-provider things and other systems.

I'm David Soria Parra. I'm working at Anthropic as a member of technical staff there. I'm the co-creator of MCP, and at Anthropic I mostly lead all the MCP efforts.

Great.

And I'm Brad. I'm a principal engineer at Block. By day, I build AI products, and by night I work on open source like Goose. I'm the original author of Goose.

It's great to see everybody come together. I think when I heard about the news, I didn't really expect it. It wasn't on my bingo card. So maybe let's have a little bit of inside baseball. You obviously have OpenAI and Anthropic, and yesterday at the launch event you were joking about how you didn't know that the 2 companies even talked to each other. And then, yeah, how did the conversation start?

The conversation started out of 2 things. The first one is that, on the MCP side, we always knew that we wanted to find a neutral home for MCP to make sure that the industry understands that this stays open and that this is something safe to adopt.

Very early in the process, as we were looking around at what to do about this—should this be a project in a foundation? Should this be inside its own foundation?—which are common patterns you see for this kind of work, we got approached by our friends at Block to discuss it, because they were looking into donating Goose, I think, at the time. So there was a question around doing something together.

Then we approached OpenAI, and they were very welcoming and very open to the idea as well, and it slowly formed. I think the time frame of this is a few months. These things are not happening out of thin air in a week or so. There was just a lot of conversation: What do we want to do? What are the kinds of constraints we want to have? What is the thing we want to build?

Of course, we were looking for where to put this kind of stuff, and that's where the Linux Foundation comes in. It's, I think, the biggest foundation of its kind and certainly has decades of experience helping companies through a process like this and building what is technically called a directed fund within the Linux Foundation to build these kinds of things out.

I think David said basically the whole story from my side as well. We saw this need to connect systems, and then MCP gained very large developer traction. We at OpenAI were very excited to use it and then contribute and actively participate in this.

From my point of view, it was always very natural that this would grow into something bigger and move to a neutral place. MCP has always been a foundation for communication between agents and contexts.

In a similar way, the Agentic AI Foundation is, well, it's a foundation, but it's also the starting point where I really look forward to other contributions, starting with Goose and our own AGENTS.md, where we're really open for a lot of technical contributions to build out a full agentic ecosystem.

I'm curious, Jim. I've been to Linux Foundation events before. I've spoken at them. Is MCP so early that—how do you even structure it in a way? I'm curious because so many of the technologies that the foundation supports are core pillars of infrastructure and the internet. This is probably the youngest technology that you've brought in as a foundation. What are the goals of it?

Yeah, I mean, I think what's interesting here is, even though it's young, I think if you—

I think AI years are kind of like dog years.

Absolutely.

Do you use this metaphor?

Yeah, totally. This is why I run 3 conferences a year.

Yeah, exactly. You can't do annual.

I think last night someone was asking, “What do you see a year from now?” And I'm like, “If I dial the clock back a year, would I have anticipated where we're at right now?” There's no way.

And so I think part of the thing with MCP is that we're just living in this kind of dog-years velocity. In the past, I think things took a lot more time to coalesce. What is clear is that a lot of people are adopting MCP. You see it in commercial products that companies are rolling out. You see a lot of usage in the enterprise already, and there still is a ways to go in terms of the technology becoming mature.

But I think the same thing held true in internet protocols. That took a little bit longer to mature, and the internet matured over time. But I think the thing I'm most excited about is that it's becoming clear that MCP will be a key protocol for this technology movement.

I think David and these folks were all pretty wise to realize that if internet protocols had been owned by a single entity, we'd still be calling it America Online. It wouldn't work. I think this has got all of the underpinnings to be a huge movement.

At the Linux Foundation, we ask 3 questions for every project. Will this be meaningful and impactful for industry and society? The second question is, do you need more than 1 organization to collaborate to do it? Otherwise, you don't need us.

In this case, clearly we've got that.

Then 3, can we get the resources and build an ecosystem around it? And 50 companies on day 1. A huge set of folks in line to participate and join. My inbox—I'm sure yours are too—is full in 24 hours: “How do I participate? We want to contribute. How do I get in there?”

I've never seen that kind of inbound interest starting any project at the Linux Foundation in 22 years.

How do you pick? You've got all these people reaching out. You know, there's good and bad.

It's a really good question. I think how to pick—how we expand the foundation itself from a governance standpoint, but also technical contributions, and how the foundation can best support them as well—that's really top of my mind.

It's the first thing we need to define: some structure and how to bring it all together. But I think even before those details, there's such value in establishing this one forum that people can come to.

Even having a list of eager technical participants and potential opportunities, that's a huge opportunity in front of us to distill what's truly meaningful to developers, users, and everyone. I very much appreciate the Linux Foundation acting as a sort of galvanizing rod for this attention.

Brad, on the Block and Goose side, the involvement that you guys have had and the sort of engagement that you guys have had is interesting. What was your calculus in joining the Agentic AI Foundation?

So for us, I think in developing something like Goose, the thing that I see as being part of this umbrella is that it's the most concrete piece. You can actually download Goose and use it in a way that you—

It can download an AGENTS.md.

Right. What do those parts do together without having something that actually connected the client side, like a real client? And I think there's a lot of value in that, because when you get into the protocol space, you want to add things to it, but you have to actually show what is enabling it. Why are you making the protocol wider and putting it into something? A reference implementation shows you, “Oh, it's giving this value to people,” very concretely.

For example, there's a spec for MCP Apps that's brand new, and we've been working on MCP-UI.

For Goose?

Yeah, so Goose has been kind of a day-one partner with the MCP-UI team.

Oh, I didn't know that.

And so now we've had MCP Apps. We opened an issue today about how we're going to get that into Goose. That's something where I think people hear something abstract like that: What is the server sending an iframe to the client? What does it do?

I think Goose is a place where you can see it: Okay, you're going to build a dashboard, or you're going to have this enhanced chat experience. This is something where I think we collaborate more and more to say, “This is what it looks like,” and look at some of these abstract things and make them real.

I think the other tidbit here, maybe going back to the history of both MCP and Goose, is that Goose was the first open-source agent interface, or agent, that reached out to us and worked with us to integrate MCP.

I think Block is technically the first non-Anthropic contributor to MCP ever, on day 2 or something like that—very, very early. So this goes all the way back to November last year, to the partnership to have MCP inside Goose.

Yeah, we had a version of Goose—you can go check the GitHub history—that was there a little bit before MCP came out. We were sitting there with a plugin ecosystem, and we were like, “This is awful. Why would anyone develop a plugin just for Goose?” [laughter]

We saw all these opportunities, so we started talking to Anthropic, and we were like, “I think there’s a space here for a protocol.” They were like, “Well, let me tell you about…” No, we reached out before we heard the Zed thing.

We wanted to pile onto something that had a chance of succeeding because, as a client, it’s an ecosystem, right? The more people use it, the more value you get as a client than as a server, because your servers are going to work with any client. As a client, you have this giant library of servers.

That’s been a big part of what Goose does. It is a coding tool—people use it as a coding tool—but you can turn off the code part and just connect to any MCP server. It can operate like a science experiment, or like Google Docs or whatever. I think it shows you how MCP goes beyond just the coding space.

Yeah, I think as well that the fact that it’s concrete is so important. For all these standards, there’s a long history throughout computing of people proactively writing a standard, and then when it’s actually tried out, it has problems.

Yeah.

But for MCP and all these new agentic standards we’re coming up with, we really want demonstrated utility. The most common thing on the core committee is that there’s a proposal, and we come back to people saying, “Have you tried it out? Does it work?”

The protocol is about communication, so if you’re trying something out, you need collaborators. You need concrete open-source projects like Goose, clients, and a variety of servers, because it’s only with that sort of open ecosystem that people can meaningfully understand if this is actually going to work.

Yeah, I totally agree with that. I think the worlds of standards and open-source development are just merging, right? You co-develop these things together.

I was trying to figure out whether David is Vint Cerf or Linus Torvalds for agents, and I think maybe it leans a little more Vint Cerf. Maybe Goose is a little more Apache Web Server, and my whole Linus Torvalds part kind of falls apart at that point. But you do need something substantive to try the protocols out in order to make sure you know how to improve them. It’s that feedback loop that’s so critical.

OpenAI also has a coding agent that is open source. What’s the thinking there, apart from whether Codex would ever be donated to the Agentic AI Foundation—or we just don’t know yet?

I think the short answer is that we don’t know yet. But it’s a feedback loop: in this open ecosystem, we don’t want too much alignment around one implementation or one thing.

There’s real value to users, developers, or whoever the participant is, in active competition in some parts. There’s a balance here: we need openness to foster collaboration and experimentation, but I’d like to see a variety of coding agents. Each one might deliver unique value and be free to explore independently.

There’s a bit of a tastemaking approach to contributing things that benefit from being open. Agents are an example: open up any GitHub repository, and it has this file that works the same way. If everyone did their own thing there, that’s potentially very low value and potentially damaging to the way things work. There’s commonality value.

For actual concrete implementations and projects, though, it’s great to have reference implementations in many ways, or experimental grounds like Goose. I really favor a huge variety of them, because that way we’ll see what comes to be the best.

Is there a roadmap for what you want to add—for example, the Agentic Commerce Protocol, like ChatGPT already uses, but that’s not part of it? There’s no model as part of the foundation. Do you already have a roadmap, or, like you said, are you just going month by month, seeing what people are using and what should be in there?

I think we don’t have a roadmap in the sense of projects lined up, but I think what we have are principles by which we will select projects, to some degree. The effort here is mostly around sitting together now that the foundation is created and evolving these principles as we see people asking us about the projects they would want to put in, and then developing the foundation further as time goes.

At the moment, I think the most important part is that we have the principles in place and then go have conversations with people who want to be part of this foundation.

One principle that really comes to mind is composability. I often use the analogy of Lego blocks. Agentic systems are a sum of many, many parts, so something I hope the foundation can evolve to do is have interoperable, composable bits that all work together.

We don’t have a roadmap of future contributions, but I welcome all contributions that play nicely with other contributions and really create a potentially future-flexible, open agent stack—not a universal agent, but an agent that suits everyone’s purpose or need.

Yeah, it’s tricky. These guys have the harder job at this early point in the innovation cycle. You don’t want to restrict innovation by saying, “Oh, well, this is the one versus that one.”

But you also don’t want to let every single random thing into an organization like this. Tastemaking is a good way to describe it: a group of elite architects and developers—folks like the 3 people sitting next to me—are curating. Some things can work; some things might not.

There needs to be a process, which I think we’ll define, to do that curation. It happens via tastemakers, and it’s essentially a technical effort—not something where a committee of people from vendors gets together and says, “My product should be in this roadmap, and that guy’s product should be in this roadmap.” That tends not to be very successful.

Right. Yeah, I think you’re looking for something to have already found a niche and to be established, because you don’t really want to be pushing a speculative architecture. You want to embrace something that already works.

A lot of the stuff we’re talking about, like payments or an interface to model architectures, is really interesting, but it’s not yet obvious that that pattern needs to exist. That’s something where we can go see it, try to make it work in some projects, and then bring that back if it really has a role.

And on the opposite side, what’s my incentive to bring you my project? I have a project with adoption. It’s well-maintained. It’s healthy. What’s the benefit I get from donating it to the foundation?

I can start that, but I’d love to hear from these guys as well. I think all technology is an implicit futures contract, right? If there’s technology that has traction and that traction wants to be built upon, having that technology at a neutral place like the Agentic AI Foundation—where the whole industry is making decisions about how to invest—can be really valuable.

When I say “investment,” I don’t mean becoming a member of the foundation, because you don’t need to become a member to participate on the technical side. I mean decisions like, “Hey, I’m going to assign 10 of my company’s engineers to co-develop this with your organization, the contributing organization.”

That’s a way that we can all essentially co-develop together. It provides better support, more development velocity, and higher code quality, because more people are participating in it.

That’s a massive incentive if you want your technology to actually be used and adopted in industry and get more feedback—a positive feedback loop of a great project producing great products in the market. That market feedback allows companies to make money off them. They then pay engineers to improve the project. Better products, more profits, better project. That’s the incentive, which is a pretty high one.

I could add a technical spin: none of these things are built in a vacuum. All these projects build on lessons, learnings, or practical code from other projects, and that’s a big opportunity.

Any technical contribution will bring its own unique value to the foundation. At the same time, it gets to learn the lessons that all the other participants in the foundation do. I’ve found it really valuable over this past year, working with David and others on the MCP committee, because it’s actually that communication that makes our ideas more robust and makes the implementation better.

We can be sure it's secure and safe and actually works. This requires communication, and the foundation is the natural town square for this in a way.

I think so. One last angle on this: if you're working on a standard or a protocol, this is such an obvious decision, right? The value in the protocol is about how many people are adopting it. So being a part of this gets you that reach.

But I will say, as someone who's working on a client and not a protocol, I think there's value there too, right? We want this to be part of the foundation because we develop these ideas together, to your point, and so it makes it better. We're donating Goose because we think it's going to make it a higher-quality tool.

Host

I actually have a follow-up question on just the Linux Foundation side. The Linux Foundation has many other funds and organizations, including the LF AI & Data Foundation, as well as dedicated projects like PyTorch and all the other ones. I guess why a new foundation?

Well, because everyone's special. [laughter]

No, I think that the way we look at this space—I’ll put aside the projects in semiconductor technology and operating systems and stuff—is that in AI, we think of it sort of like how the market has evolved. It started with tools like PyTorch and the transformer technology that is used to create LLMs.

The Linux Foundation kind of took a pass on the frontier-model world because, in the open-source space, having a connection to the internet, some intelligence, and a computer—that's sort of entry into the world of frontier LLMs. It's a computer connection to the internet, some intelligence, $2 billion worth of GPUs, and a ton of data. It's harder for consortiums to do that kind of work, so we passed.

Then you look at how reasoning models have come—you need things to be scalable in the inference world. Okay, now you've got interesting technology: VLMs, Ray, things like that. They have to be deployed on something; Kubernetes is sort of that. These are all distinct components. Agents are a distinct enough set of technology that it merits its own community.

Separate from data.

Yeah, because a PyTorch developer isn't really doing a ton of stuff in agent land, right? Somebody working on Docling maybe is a little more adjacent, right? But not quite the same as somebody who's working on transformer technology or VLMs. And so they are logical categories.

Sometimes stuff comes in over time, and we sort things out later. We had, early on in the telecommunications sector, a software-defined networking effort, a network function virtualization organization, an orchestration effort—a whole bunch of stuff. All separate entities. I was like, “Let's just bring all these things together,” because the technology is now mature. We're taking all this money in, but we don't really need the resources anymore because the market's already mature.

So it took me a year to get all these companies to decide to bring all these things together and not pay all these separate fees and have all these separate organizations. I have a little folder in my inbox that says, “Convincing people not to give me money.”

But in this world, I think it's a different kind of audience. I think it's narrow enough. I think it's specific enough to agents that it merits its own entity. I think as well it dovetails somewhat with the earlier thought: there's a taste-making aspect to this.

For these organizations to be effective, they really need a focus—something that brings them together.

Ultimately, you can imagine an alternative where we snowball and there's only the Linux Foundation as this über-foundation doing everything remotely connected to a computer, and that wouldn't be that effective. So there's a taste-making aspect here as well: we want to be focused on agentic systems and how they connect together. Hence the Agentic AI Foundation.

But everything's about growth and evolution, so there's a possibility that later down the line we recognize some natural affinity. We have something new, something old, and then they can be brought together, but the focus helps at the beginning.

Host

What's going to be the actionable outcomes? Obviously, you have the funds to direct. I know a lot of the Linux Foundation does events. There's also, eventually, certification and things like that.

Host

What's the split of the foundation's investments? Is a lot of it going back to different projects individually? Is it about community building? And then, from people who have not been involved from the outside, it just seems like a nice blog post and a bunch of logos. In reality, how are things going to be actioned?

Yeah. I mean, 50 companies coming in to fund a bunch of blog posts seems like overkill, right?

Right, exactly.

So I think there's a couple of things. One, the intellectual property assets now are owned by this entity. That entity is responsible for making sure that IP is managed effectively, that licenses are complied with, and that intellectual-property problems are dealt with. Some funding goes to that.

There's a leadership function where, to help bring consensus across the industry and within developer communities, you have to have a special kind of person to do that. I think they need to be technically knowledgeable but humble enough to know that the community is the one that makes the technical decisions. So you hire some people to lead through influence and help people organize things effectively.

You hire people to do developer outreach and community engagement because you want more developers coming into the community. So funding goes to that. And then there's a huge convening function. The Linux Foundation hosts 50,000-plus virtual meetings a year. So we have this—I think we're probably one of the largest users of Zoom. I know for sure we're the largest Slack user in the world.

That convening function is critically important: make it as seamless and easy as possible to convene. And then we hold events because, to your point, developer engagement face-to-face, being the town square where you physically get together, means something. I think you guys have been to KubeCon. We have easily 10,000 people who come to that conference twice a year. In Europe this summer, there were 13,000 folks there who come in and exchange ideas; the core maintainers get together and make real decisions.

Then the last thing we spend resources on—and you can even just check these out for some of our other projects—is a whole platform that enables maintainers to look at their community and understand: What's our velocity? How many developers are we adding? What's the social-media scuttlebutt around this project? What are leading indicators of adoption? How's our security doing? Do we have good practices about application security?

Those are all things that we invest in to help make these communities more commercially adopted, so that we get that positive feedback loop of adoption begetting more investment in the form of developers providing input, and that virtuous cycle kicks off. That's where the funding goes for these kinds of things.

Host

I put that question into our doc because it says “directed fund.” So my cheeky question was, “Well, what are you directing it to?”

Yeah, so “directed fund” gets into the nerdiness of this. The reason we structure it that way is somebody has to own everything. The Linux Foundation is actually the ownership vehicle. And remember, we separate technical governance from the governance of how money actually gets spent because we don't want this sort of pay-to-play aspect of technology that tends to screw everything up.

The directed fund is really real stakeholders who care about this tech putting money in and using it in a way to help build the market and the community and all the things I just talked about. And just let developers do what they're super good at: get together, solve tough problems, and be taste-makers. That's something that we separate.

Host

Yeah. I think there's a great essay by Rich Hickey, who created Clojure, called “Open Source Is Not About You.” Just because something is in open source, I don't owe you a response to your issue or pull request.

I think some of the worries sometimes that people have about these groups are, well, if you're not part of this thing, am I supposed to also listen to your thing and implement the thing that you said? So I think that's going to be a super interesting thing in a technology that is so new.

I feel like everybody—because there's so much venture money in early-stage companies, and obviously the foundation-model labs have raised so much money—needs to be on top of it. There's a lot more pressure, I think, from the community to try to be a part of it and put their stake in and be like, “Yeah, we've contributed that,” or whatnot.

So I just think it's unique compared to the CNCF, for example, where the hyperscalers are kind of like around the clouds and we all know what those workloads look like. Nobody's really trying to influence them. There's not an OpenAI-preferred thing versus an Anthropic-preferred thing.

But it wasn't always so. When we started CNCF, I got a call from—I think it was Urs Hölzle and Brian Stevens, who were over at Google. It was 2014, I want to say.

They were competing—well, they weren't even competing; they weren't in the cloud business, and they wanted to be in that business. Amazon was hosting virtual machines on EC2, and they were the de facto leader. They said, “We will give away Kubernetes,” which was kind of the Borg, and they renamed it Kubernetes, to the Linux Foundation, and we've never run a virtual machine.

We think containers are a better way to scale cloud applications. We'll give you this technology, and it'll be helpful to us if the entire industry adopts containers and Kubernetes as the way to build and deploy applications. So that was the strategy out of Google. They contributed some serious IP that we all know today is awesome.

But at the time, remember, Mesos was still a thing, PaaS was still a thing, right? Heroku, Cloud Foundry, even OpenStack—virtual machines were still kind of a thing. It wasn't clear what the abstraction layer for cloud computing was.

But once the market started piling on to Kubernetes—like, oh, now Microsoft joined the Cloud Native Computing Foundation. They're investing in Kubernetes and creating Kubernetes services. Oh, wait, Amazon's now investing in this—then the consensus was really building up here.

I think there's a somewhat similar situation here, with the caveat of saying 10 times faster. Just day 1, there was so much momentum around MCP and so much interest in this. And then also, 10 years of CNCF to teach the developer community and the vendor community how to do this well, where investment is not mutually exclusive to great technical outcomes, I think has been super positive. So I think this is going to move super fast.

Host

Awesome. We don't want to keep you guys too long. I'm sure you've been on a media tour this week. What's maybe one thing from each of you that you look forward to in the new year from the foundation?

I don't really know what it's going to look like, but I really look forward to the next step. As David mentioned, it's been months of development and discussion to bring us to this. There's this sense of, I guess, relief and achievement: you made a foundation, we're collaborating, we created this open space. It's great. But what next?

I'm super excited for the next technical contribution, for the first AIF event or night or conference—whatever form that ends up taking—because there's another world where organizations and foundations are created and then eventually they get forgotten. This is not that. This is really a beginning, and so I want to see it be healthy and grow. I just don't know what comes next, so I'm most excited to see that in the new year.

Yeah, I think I'm most excited if I really take a neutral look at what just happened in the industry with creating this: you have Google, Microsoft, Amazon, Block, Bloomberg, Cloudflare, OpenAI, and Anthropic—all platinum members—create a foundation. I think it's quite cool and quite substantial.

And now we're at this starting point of what can we do with this? To Nick's point, there are a lot of things we don't know yet and things we need to figure out. For Anthropic, this is the first big foundation we're creating, and we have to learn a lot here.

But I think it's such an interesting starting point, and I'm super excited for these new things. When you start something new, what can you build with it? It's in a way of building something that I'm not familiar with, so I'm super excited to learn about this and see what we can do with this quite unique vehicle now.

I feel like it's really driving the agentic AI open-source community forward and focusing on what these companies, which are very competitive with each other, have in common and where we can build things together that benefit and uplift every user, developer, and builder in the market significantly. That's what I'm really excited to see.

I definitely agree with both. I think there's a lot of opportunity to figure out what the structure does. But let me give you something more specific that I think is already coming up: I want to see how agents become asynchronous.

I'm really tired of reading through chat sessions, and I want this to be a thing where I can go have 20 agents working for me and actually see that come together. So I think MCP is starting to approach that answer, and then we want to figure out how to make those reference implementations and show people how they can actually get another order of magnitude out of what AI can do for them.

Host

You don't enjoy pressing yes every five—

The approval every 3 seconds.

Bypass—

Dangerously skip permissions.

Yeah.

I'm with you on that one. I think what I look forward to is the success stories of the organization that's implemented agentic technology in that way and hearing how it really impacted their business.

I'm looking forward to stories about MCP startups that made a ton of money. I'm looking forward to stories like in CNCF this year: CVS Pharmacy joined the Cloud Native Computing Foundation. A pharmacy company that's really a user and adopter of technology, sort of the late majority.

I think we're going to start seeing organizations really use this technology impactfully, provide feedback back to the community, and just see the potential of the technology truly manifest. I don't need to tell this crowd how huge it is, but that is going to be cool.

Well, thank you all so much for joining, and congrats on the launch.

Thank you. Thanks for having us.