Ep. #35, The Evolution of MCP with Den Delimarsky of Anthropic

Brian Douglas: Welcome to another installment of Open Source Ready. What's up, John? How you doing?

John McBride: Hey, I'm doing good. How are you doing, Brian?

Brian: Good, good. I'm doing great. I heard you started a new company, I saw on LinkedIn.

John: I did, yeah. Still in Stealth. I had some funny people reach out to me and be like, "what is this Stealth company that you've started? There's so many people that work there."

Brian: Yeah, funny. The GitHub CEO used to work at Stealth up until this morning, so yeah, it's a common practice on the LinkedIn.

I guess we'll talk about that in the Reads, but actually we don't want to talk about any of that other than, let's talk about MCP, because we've got Den. Den, say hello. Tell us what you're doing. Why are you here?

Den Delimarsky: Hey, folks, I'm Den Delimarsky. I'm a member of technical staff at Anthropic and I work on things that have three letters in them, like MCP, SDK is, API, CLI. Anything that has to do with developer experiences is near and dear to my heart.

Brian: If you say one more acronym, I'll have to give you a pre-seed check.

Den: Oh yeah, yeah, yeah, no, that's exactly how it should go. But yeah, no, I love my job at Anthropic. I'm good.

Brian: Yeah, excellent. So, you recently joined Anthropic. Congratulations. I know you from Microsoft, but also you took a quick tour at Netlify, which is my former alma mater as well.

Den: Yeah.

Brian: But why don't you catch us up on like who's Den? And how did you get here?

Den: Yeah, so let's see. Who's Den? That's a long story. You know, it's interesting. I started my career as an engineer, so I used to write a little bit of code and then I just decided that, you know what, I actually like talking to people like folks such as yourselves and help engineers do more.

So I switched tracks to product management. And that was like a decade ago. And I kind of stuck with it since, but I still stuck to the field of basically anything that has to do developers or developer experiences. So I worked at Microsoft on DevTools as well as dev documentation. Like if folks remember MSDN.

Brian: Oh yeah, yeah, yeah.

Den: So you had MSDN and then we rehashed it into Microsoft Learn. And then I worked at AWS, so I was a tech-- Well they call them "Product Manager-Technical" because Amazon likes creating their own terminology for things. But basically it's a super technical product manager, I guess.

And I did that for a little bit, went back to Microsoft, spent some time also in kind of the developer relations ecosystem and then got an opportunity to go to Netlify where I helped craft some of the integration story for Netlify. And that was also super fun.

After that, I came back to Microsoft to work on security pieces. So I worked on authentication authorization libraries. So if you've heard about like MSAL, I don't think a lot of people would hear that. It's a very obscure name. But regardless, I worked on that for a little bit and then I switched to what's known at Microsoft as the Core AI division, which is responsible for things like GitHub, Copilot and Azure AI foundry and all these pieces.

And through that work, as I was kind of ramping up, MCP was ramping up at the exact same time. So folks think MCP is just this thing that existed forever. It only existed since like November 2024. So like it's not that long ago. I t's a fairly young protocol.

So as I was picking up traction, one of the things that I noticed was like, hey, there's pieces that are being written around authorization, which I've been doing for the past few years and they could be just a little bit improved to make the protocol a little bit more suitable for the general use case. So I just reached out to the MCP team, David Soria Parra, and asked like, "hey, is it okay if I contribute? Like, I have some ideas." And that's kind of how it all snowballed from there. And that led me to Anthropic. Now here I am.

Brian: Yeah yeah. And actually, we'll put in the show notes because it's linked there. But I found your earliest RFC, which I opened up, its: "Update the authorization specification for MCP servers."So you caught us up to what you were doing that led up to this.

John: Yeah.

Brian: But I'm curious, was this the first touch point or did you actually talk with the team and then you sort of opened up the RFC and then it got off from there?

Den: No, I'd say, like, it's kind of the first touch point because it's the first official RFC that I submitted to MCP. But the conversation even happened before that because there was a desire to basically make sure that I didn't want to rock the boat and come in and be like, "oh, I have ideas, I'm going to like, help you rewrite stuff."

No, no, no. I'm sure they have a good reason why the protocol was built the way it was built. And it's just I had some idea based on my experience for what that should look like in the future to make this more scalable. And also, again, I'm not taking credit by myself. That RFC was just me tossing an idea out. And if you look through just the sheer amount of conversation that is there, there's a lot of folks that contributed from Amazon and Okta and Keycloak and a whole bunch of other folks. Arcade.dev, right?

Like there's a whole bunch of really awesome, really smart people that contributed to that. And it became a very organic, "hey, we're all here trying to help the authorization story be better."

And that was kind of the point for me to get involved a little bit more closely because I saw how the process works, what are the things, how do contributions work and how we can get the community to help build stuff.

Brian: Yeah, yeah. So there's a foundation today, but this is like pre-foundation days, which, I don't know if the foundation even changes the process at this point, which we can get into. But what is the process? RFC gets open, we get a lot of feedback. Does someone at Anthropic say, "okay, cool, what's this? Like, etch this in stone and move forward," or how did that sort of work out?

Den: Yeah, so back in the day it was kind of what you just described. It was very ad hoc where like somebody opens a pull request or like an issue in GitHub and says, Hey, I found this problem, let's go review this. And yeah, somebody from Anthropic though is basically because Anthropic is the one that came up with the protocol.

Like there's a bunch of folks that like again, DSP or David Soria Parra and Justin, Justin Spahr-Summers were the ones that co-created the protocol. Right? And they were basically in the middle of triaging and kind of shepherding the protocol from the very start. And there's a team around it, there's like more folks involved of course, but it was very much ad hoc-ish, I want to say.

Like there was no formal process. It's more like you try to outline an RFC as you would outline an RFC saying, "I'm trying to build this. This is why here's the use cases." If you're a product manager, you know exactly what I'm talking about. So that's kind of the lens that it took shape in.

But as the protocol evolved, as it gained more traction and more visibility with it, and especially involvement from other companies that started adopting it, that became a non-scalable process.

Right, because you can no longer rely on just random pull requests coming in. And this is kind of before that there was what's known as an MCP steering committee. And those are just a bunch of people that are trusted by the folks at Anthropic to also help contribute. So we had folks from different companies that were part of the steering committee and then that got formalized into this entire maintainership structure.

So you might have heard about the term core maintainer. So like I'm one of them. But I believe there's like nine of us total representing different companies and with different backgrounds. Like my focus is a lot on like security auth. And there's another like core maintainer that I work with, Paul Carlton, who's also super deep in the security and auth. There's other folks that are interested in transports and they're contributing transports.

These are kind of the main shepherds of the protocol. Then there's maintainers and they're responsible for various areas of the protocol, like sub areas. Right? There is auth pieces, there is transports, there is primitives, there is extensions, all these things and they basically like SDKs and they shepherd those pieces of the protocol themselves as well.

So there is this kind of it's not really formally hierarchical structure, but it is a structure that allows a more robust way of scaling the contributions. And when we launched that, the other pieces that we also added was known as the SEP process or the Spec Enhancement Proposal. And it was modeled a lot after the folks that have done this for Python and Pytorch with, you know, like PEPs in, in Python. So you have SEPs for MCP, there are spec enhancement proposals and it's more formal.

We have to submit a specific set of requirements, how it's formatted, where it's done, and then who's going to sponsor it. Right? Because you have to have somebody from the maintainers that says, yes, we actually want to pursue this whatever endeavor, you know, either like adding transports or changing how auth works. And yeah, so it's much more scalable, much more robust.

It's still a lot to learn like we're learning as we go, of course, because again, as, as MCP grows and matures, a lot of the things, we kind of start seeing the rough edges and where things work and where they don't work. But ultimately it's much more structured now than it was back when I first wrote that authorization RFC.

John: One of my main questions, because I actually participated quite a bit in the MCP community with the SEPs, and I was part of that whole kind of moving from the steering committee, which was the ginormous Discord, to all the senates, the SEPs and PRs are in flight and in vogue and all this stuff.

How have you seen that adoption curve into this new model of contributions? Have you seen contributions continue to be adopted and people doing this? Or is it whittled down to people who have the time, energy or effectiveness really to go and see this through?

Den: No, I think the contributions volume actually went up. And also I want to say, like, it is easier for the team to also look at them because now there is a predefined structure around it. So if I look at a SEP, I have an idea of like, what am I actually looking at and how it works behind the scenes. Like there's requirements for SEP now that you have to have a reference implementation.

It's not just you're coming up and like, oh, you know, I want to rewrite the auth to be like X, Y and Z method. Instead it's like, okay, like how does it work in practice? Who's going to be adopting it? Who's going to be the customer? So that has helped kind of shepherd this to less, I want to say like drive by contributions of like, oh, I just had this random idea, let me toss it in the repo and see what happens versus somebody that has actually committed to pushing that forward and advocating for it.

And this is where also the governance structure that is put in place for MCP that David and team have put together is actually super, super helpful because then you end up with folks on the maintainer side that are acting as more, I want to say autonomous sponsors that can make a judgment call based on, because they are trusted maintainers in the MCP community already, they can help make a judgment call saying, hey, we have this proposal that is trying to, I don't know, rewrite the transport layer. Is this something that's actually fitting into the vision of the protocol, yes or no. And help us kind of navigate that process end to end and help contributors understand that as well.

John: Right.

Den: So.

I don't think the volume of contributions decreased. I think the contributions became much more intentional and much more high quality because then with the structure now you have to kind of put an explicit effort to add value to the protocol and explain it versus just tossing an issue with 17 paragraphs and hope for the best.

John: Yeah, that's fascinating. I think I've seen both where you know like Kubernetes with the KEPs, which is Kubernetes Enhancement Proposals. I think they saw like a decrease in contributions as you know that obviously is much longer and storied project. But yeah, it's fascinating to see that that's picked up and continued to keep a lot of steam.

Den: Yeah and also like as we went through the evolution process there's also things that the team realized that need to happen to, I want to say, make the protocol sustainable for the future and evolve with new scenarios while still providing the simplicity and stability that people expect from MCP. So this is kind of, I alluded to it earlier but there's this concept of extensions, right? Where basically you have customers that come in and say look, I want to deploy MCP for my fleet of internal services. I use Kubernetes. And your spec says I need to use OAuth 2.1 with a bunch of authorization stuff that requires interactivity. Like I as a user need to go to the browser, log in, you know, put my credentials, do the 2FA dance and everything else.

And this doesn't work because if I have a deployment like a fleet of microservices, like how do I actually, like if they're all MCP servers and they talk to each other, how do I do the auth? Right? And in this case the spec acts as that minimum bars the least common denominator. But it doesn't preclude you from going in and saying actually there's extensions to MCP. So now we have this concept formalized. You might have heard about MCP apps that launched just a few weeks back.

It's an extension to the protocol so the core protocol stays the same. And on top of it we're building this ecosystem of capabilities that allow you to add more functionality to MCP without breaking the core protocol. So if you have enterprise customers that come in and say I need special auth for Kubernetes, you might have a Kubernetes auth extension that allows anybody to then say oh yeah, by the way, I am big retailer that also uses Kubernetes and MCP servers in my deployment. I can use that extension to now make this possible to use MCP in my workload. But I'm not necessarily asking that to be part of the core protocol.

And that actually helps improve the velocity of a lot of the contributions too because then the protocol itself has to maintain a level of stability, a level of rigor where you can't necessarily break it, you know, like, or bloat it at the same time. Because like we know that like Kubernetes ought is a problem, but it's not a problem for everybody using MCP. Why put it in the core protocol?

So a lot of this evolution happened like through the past year and again kind of like it's learn by actually doing the thing, seeing the rough edges and then saying okay, what are we going to do about this, to not make this a problem down the line?

Brian: Yeah.

John: I think though you bring up an interesting point around some of the main criticisms I've seen of MCP which is that it's in the last year gone from a protocol that was essentially JSON-RPC 2.0 wrapped to then enable tool calls. Now it's got authorization, it has long term tasks, it has this whole apps abstraction extensions to be able to bring it further and further into different scenarios and enterprises. Where does that end? Where does some of the capabilities end, where we kind of say okay, MCP is not going to be doing those things?

Den: Yeah. So I'll say first of all what you're going to hear next is Den projecting his own opinion on MCP. It's not a statement that's definitive of the future of MCP. But the way is generally seen is that MCP as a core protocol, the core pieces around it are more or less there, right? Like you have authorization, you have long running tasks, you have transports, there's work that's being done by the way, by core maintainers and a bunch of folks from across the ecosystem to make some of the stateless transports happen.

So that's going to be part of the protocol soon. But with a lot of those changes, like the core fundamental building blocks are there, right? And to get to a lot of them it took a year or a year and a half, two years. But ultimately like the core is there. Like if you want to ship an MCP server that requires authorization, like, you can do that. If you want to ship an MCP server that requires elicitations or asking for user input, like, you can do that.

But beyond that, the moment you start thinking about like MCP apps, it's a good example, right? MCP apps adds, it's not a lot of complexity, but it adds another layer of like, well, okay, but MCP can now render UI. Like your, your service can now return interactive results. It's not part of the core protocol because we still want to make sure that it's a thing that people can do, but it's not fundamentally piece of this-- The MCP kernel, if you will, right?

If we draw the analogy to like the Linux ecosystem, right, you have the kernel that is like super, I don't want to say like heavily controlled, but it's like it's managed. You cannot just put everything in the kernel, but around the kernel you start seeing a variety of distributions. You see a lot of like desktop managers, you have GNOME, you have KDE, like all these things. So you can imagine MCP the same way. There's the kernel and then there's a set of things that extend the kernel to provide the experience that you want.

And some of them are broadly adopted. Like we are working on making sure that MCP apps are the standard, which is actually like really cool to see like how that adoption has been happening. Because when MCP apps got announced, we got support from major IDE providers that support for MCP. apps like VS Code already shipped. It it is supported in OpenAI's ChatGPT. It's there, it's in Cloud AI, right?

Like it's an extension, but it's integrated across the board now. And it's going to continue growing and we hope to see that this adoption model continues evolving. So as more capabilities need to be added to MCP, it grows to this ecosystem of extensions and not necessarily the base protocol. You're not going to expect JSON-RPC to start breaking with every protocol revision. That's just not going to scale.

John: Right. On the authorization piece, I do have a burning curiosity on how you, or I guess the maintainers in general, or I guess even the community at large is thinking about authorization. Because even in the last year, the original intent was this whole like human in the loop, that the human on the MCP client side should be enabled to push that button to say like, yes, I want to authorize and authenticate myself to then let the agent go and do that on the MCP server to call those tools essentially.

And we've seen sort of a wild ride of like OpenClaw and all these other like autonomous tools start to remove that human in the loop.

Den: Yeah.

John: Where are y'all thinking about authorization and that authorization story now?

Den: Yeah. So from an MCP standpoint, again, the authorization spec, the authorization part of the specification itself is the least common denominator. It's the minimum bar. Like if you are building an MCP client that wants to work with every MCP server imaginable, that's how you do this. It doesn't necessarily stop somebody that wants to do an autonomous MCP server that is used with a myriad of agents to do self auth with whatever identity solution you want, whether you want to use client credentials.

When I used to work at Microsoft, some of the teams that I collaborated with launched agent Identity and Entra. You could use that, you could use workload, identity, federation, that could work as well. Anybody can implement any set of custom solutions that they want for auth for MCP. The protocol itself is not prescriptive about how exactly you do auth. Like you could extend it in whichever way you want.

It's just it, depending on where you use it. If I build an MCP server and I want to connect it to Claude AI and I use some super custom auth protocol, you have to be ready for that to just not work because it's not common. But if you're building like your own agentic system and like an orchestrator or of agents that does things and you need those agents to talk to each other and log in or auth, and then you check the auth pieces or like scopes or whatever other metadata, you can do this already. Like the spec doesn't tell you that you can't.

John: Interesting. I admittedly have been very deep on the MCP authorization in a past life. So I have so many technical burning questions that I could spare our audience from but--

Den: Welcome to the MCP Auth Podcast, folks!

John: I know. It's a central thing that a lot of people talk about. I am surprised by you saying that because from my read of the specification, OAuth 2.1 implementation is a must.

Den: It is a must, but again, for what? For MCP servers, like if you want your MCP server to be globally available to any MCP client like Claude, Chatgpt, VS Code, Cursor, then yes, OAuth is the way if you want to build custom solutions for your own enterprise. And this is something that actually like was fascinating to me that there's a lot of enterprise pool behind MCP and there's a lot of invisible MCP fleets that we do not see from the outside because like folks just use MCP servers internally for a whole bunch of things and those MCP servers do not use the same auth as an external facing MCP server would.

John: Interesting.

Brian: Yeah. I wanted to quickly butt in and ask some more questions around the foundation that was announced a few months ago. So I think we actually ran into each other at that event.

Den: Yes.

Brian: And then that's when I sort of pitched you on coming on this podcast and I was like, "oh yeah, Den, actually we've been looking to like have a sort of roundup of MCP. So you'd be the perfect person based on--" Like, if I was thinking of a DevRel person for MCP, like I think I see you a ton--

Den: I post too much on LinkedIn.

Brian: Yeah, yeah, you're owning the term for sure. But yeah, I actually want to find out your take, the sort of experience at the running up to the foundation, like what's the purpose of the foundation? What can we expect from the foundation looking forward? I know it's still like pretty rough and new, but also was like super fresh two months ago and like no answers were provided.

Den: Yeah, no, of course.

I think ultimately what the foundation allows is a much more sustainable growth for the protocol and much more formal growth to it. It's no longer just an open source project.

Like I mentioned earlier in the podcast, MCP has seen a massive growth in the past year alone because every single company that you can possibly talk to that is in tech, there's companies in all sorts of fields that are adopting MCP. And at this point there's a lot of questions like, well who holds the keys? How do we make sure that this doesn't just disappear overnight? If anything, that there's some level of support, and I think the foundation adds a level of those guarantees. Right?

Like there's a level of support for events, there's a level of support for MCP related infrastructure, there's a level of support for sponsoring like the security program for MCP. Right? And a lot of these things stem from the fact that they require explicit funding, they require explicit formal governance boards that assure a lot of the companies that this is not just an Anthropic effort, this is an effort that is spanning the industry.

And I think this is where the foundation is essentially a de-risking mechanism in this context because it allows this project to grow, it allows it to flourish, allows it to get the support that it needs from across industry and not become a little gated community that happens to exist on GitHub.

Brian: Yeah, we first started this conversation around your RFC and like someone from Anthropic would come in and like etch it in stone once a lot of conversation happened. So there's now the expectation RFC foundation or is it there a steering committee still around, sort of figuring out features?

Den: Great question. So those two are somewhat disconnected in the sense that, intentionally so, where the technical governance board is still within what is referred to as like the BDFL Benevolent Dictator For Life, which is David Soria Parra. Right?And David essentially is the tech lead for all of MCP and he will be the tech lead and it's essentially etched into the governance model that the technical pieces are separate from the logistical pieces.

So the foundation is helping a lot of with the logistical pieces but they're not necessarily involved in the technical decision.

So somebody from a major sponsor cannot come in to technical committee and say, "you know what, we are this company and we really, really want MCP to support like some like custom protocol that we just invented on a blockchain. And by the way now all of you have to go and build this."" Like that's just not like it, it doesn't work that way.

So the technical committee is separate and then there's folks that are helping with kind of the logistics and the budgeting and the events and all this stuff around that.

Brian: Yeah, I even noticed a new, the event that actually coming up in New York is actually, it's a Linux foundation event now. So it seems like it's already starting to get some investment or investment of time from the Linux Foundation or the proper AIF? But, yeah. Do you have a role within the foundation?

Den: I do not, no. I'm sticking with the technical stuff. I'm sticking with the stuff that I actually am good at and enjoy. Like, there's people that are absolutely phenomenal on the foundation side that are much better than I am at all this logistical stuff. So, yeah, I'm on the technical side and I'm planning on sticking to that.

Brian: Perfect. Yeah.

John: Another question on that technical track, how do you, or I guess, the maintainers, I keep referring to y'all as the maintainers-- How do you think about Skills as a thing that, you know, is now in the ecosystem, another Anthropic thing that works in Claude Code and has been adopted, also, and really I like to think about as kind of the more like CLI wrapper thing. Like, I could just give it a Skill to go run some Python or, you know, run a CLI pretty effectively.

Den: Yeah.

John: How do you see MCP and Skills coexisting in an ecosystem together?

Den: Yeah, no, that's a fantastic question that actually came up in one of the core maintainer meetings, I want to say, two weeks ago. And you heard it here first, folks. We're actually working on documenting that difference and making sure that it's clear. But I think they're actually complimentary. Like, they're not a replacement for one another.

There's things that Skills are fantastic at. Like, I use Skills for so many things. I'll give you an example. Like, I edit my own podcast as well, and I just delegate so much of the work to Skills where, like, I need to generate a transcript, I use some local transcription models, I toss the audio, the WAV file, and with Skills, I can just tell it, like, here's the tools. Go like FFmpeg, go figure out what the parameters are. I don't know, just, just do this. There you have access to FFmpeg. Do this.

And Skills can enable a lot of these scenarios where especially they're like heavily CLI based that are local, uh, based on your machine, or even in some cases for, you know, even a web request. But you're going to be hitting a wall for certain things, like enterprise auth and observability. Right? I am somebody that now needs to manage who can access my API and who can invoke a specific tool. How do I do this with a Skill?

Like, yeah, I mean, I could write a markdown file and just hope that the model actually understands like, but do you want to encode RBAC policy into that? Does anybody? Like, I don't know. I don't think so. Right? So this is where a lot of the benefits of MCP come into play, where you have that ability for a unified interface for how tool calling works, for how authorization works, for how observability is set up, how role controls are implemented.

It's not necessarily, again, like, it depends on a scenario. I want to tell people that use the simplest thing that actually gets your job done. Like if you have an FFmpeg CLI on your machine and you just don't want to use a Skill, like, you don't need an FFmpeg MCP server, just it's-- Why? Right?

At the same time, if you're like, oh, but I need to get live stock prices and for that I need to auth with OAuth, like, oh do I need to explain to a Skill like how to do the token exchange and where to store it? Or I just connect an MCP server that does this for me and handles it for me as a regular connector. Right? So it depends, it really depends on the scenario. And again, we're aware of the confusion and there's work that's being done on the open source model context vertical blog to kind of help explain some of this and say, what are the Skills good for and what is MCP good for?

John: Yeah, I think it's a fantastic answer. From my past life, my last company was building a lot of these like MCP API wrappers and it was sort of the only way to scale MCP in that way. Like, unless that company went and built all of that that you just talked about, like all the OAuth exchange and all of the CLI capabilities into a bespoke CLI or just ship MCP and then it just like works across those APIs. So yeah, I think it's a good way of looking at it.

Den: Yeah, for sure.

And again, it's not necessarily something that you can very much paint it like one or the other. It's not a binary. You can use Skills and MCPs. You can use Skills that actually reference MCP servers and say, by the way, for this, you can invoke this tool from this MCP server. Right? So they're complimentary.

Brian: Yeah, I was going to say that I spent a lot of time with the GitHub MCP last summer and felt like I knew the CLI super well from my times of being on GitHub and seeing that things get shipped. Like, there's very few times I'd needed to like reach for a GitHub MCP.

Den: Oh, a hundred percent. Yes.

Brian: Yeah, I don't know when I would actually use the GitHub MCP over just like a GH auth login.

Den: Yes.

Brian: And at this point the Skill could just do that.

Den: You're another person that has the exact same mentality as I did. Because my first hunch is like, I don't really need a GitHub MCP server. Like I have GitHub CLI that does everything. Not only that, but Opus 4.5 and now 4.6 are freaking excellent at understanding how the GitHub API works. So because the GitHub CLI has, I think it's GH API, I think that's how you call it.

And you could, like I had a problem where I was going to, I want to auto label all of the issues in our repository for like MCP with a new GitHub issue type. You know, not just a label but the issue type. And they have not exposed an actual interface through the CLI. But Opus figured out it's like, oh, I'll just use a GitHub API for this and I can auto label this. I didn't need an MCP server for that. Like it just, it just went and figured out and the CLI does the job just fine. A nd I'm happy. Like I don't need it.

At the same time, if I want to say, okay, here, here's an example. I actually love this because I find this particular one something that's near and dear to my heart. Like I'm a reverse engineer in my free time. Like I don't have that much free time, but when I do, I use a tool called Ghidra. It's a tool released by NSA and it's actually, it's open source, but it allows you to reverse engineer binaries. Right?

And for those, there's not really a good like CLI or anything, but somebody built an MCP server that actually controls the app. It allows feeding a lot of the inputs and outputs and then Claude can analyze them and provide like inputs like, "oh, I'm going to go now we need to go and jump to this part of the binary. Now we need to go jump to this part."

Could I write a Skill for this? Maybe. Kind of. It'd be very tedious. Or I can just like hook into some like websocket connection to the Ghidra plugin and just have the MCP expose a number of tools that says, like, get input, get output, whatever, and it works great. Right? So it depends.

Brian: Nice. So I do want to transition us to Reads, but first I wanted to ask the question, if folks wanted to keep up to date with MCP, you had mentioned a couple different places. Could you give us, like a verbally give us the links and we'll drop them in the show notes?

Den: Oh, for sure. Yeah. So, first of all, we have an official LinkedIn page for Model Context Protocol. I'd say start there. We're planning on growing it. ModelContextPortocal.io is the latest place where you can just find all the docs, all the references to your repositories, SDK, tools SEPs or the spec enhancement proposals. Like, all the stuff is there.

Blog.ModelContextProtocol.io is another resource where we announce all the big changes. You'll see them there, as well as tips from folks in the community. And just generally, I'd say, like, those are the places and you'll know about them when they happen because we're very active in the community.

There's also a contributor Discord. There's, uh, folks that are on Twitter and tweeting like David, who is, I believe "DSP_" is his Twitter handle. So you can just go there and follow David as well. He highlights a lot of the stuff, and we have a lot of folks from the MCP engineering team who are also on LinkedIn and sharing their insights.

Brian: Cool. Well, thanks for the insights on MCP and what you're working on, the team, the maintainers are working on. I have a question for you, Den, which is, are you ready to read?

Den: Let's do it.

Brian: Excellent. So, John I've got one pick, you got a few. I'll jump in with mine first. David Crawshaw, who's the former CTO of Tailscale. Now he's running a new company. Well, the project that he's running is called exe.dev. But he actually did a blog post on eight more months of agents. And he sort of just summarizes the last eight months of what's been happening in agents.

And some of the Cliff notes is we might be in the sort of cusp of the death of the IDE. So everyone's really gone down to having your harnesses run in the terminal. I've heard both cases, but I'm happy to chat with both of you about that. And then the frontier models are also like, that's where it's driving all the innovation, which, like you just mentioned 4.6, which I think was released within a week of this recording.

The question I sort of proposed to this in the conversation is like, how long will frontier models continue to drive innovation? Or are we going to get a peak where we sort of take a breath and then we see other things like MCP advance and other tools like Skills and everything else, like sort of like take the brunt of the work. So, yeah, thoughts from both of you on eight months of agents. John, what do you think?

John: It's a good question. It's a very good read. I definitely encourage the listeners to go check it out. The part where it was like, VI is turning 50 this year. Like, oh man. It really made me feel crufty for still using Vim and Neovim, but I think it's fascinating. I'm not certain I can be down with the arguments though, if that makes sense. I feel like I'm still having to go in quite frequently to scale the code bases to be able to get to the place where agents can continue to tack on things.

I don't know, it seems like it's a lot of pieces that maybe don't stick quite right, but then I go in with the trowel to smooth out a little bit. So maybe not so much the year of the IDE, but definitely the year of crafting and making sure things are smooth of the IDE. But even still, eight more months, a year, two years, three years. Who knows, we could be in a place where, yeah, that stuff that's getting stuck on is nice and smooth and wouldn't need this stuff to go in and actually smooth it out. Den, what do you think?

Den: Yeah, I don't know.

Given the trajectory, I'd be hard pressed to guess anything at the scale of like six months at this point.

But judging from my own experience, like I have not touched an IDE, like a proper IDE like Visual Studio, for I want to say like a good chunk of the year, which is new to me because before that like I would, I maintain, I help maintain some of the tools in the open source community that require like Windows builds and all these things, like your typical stuff that Visual Studio was very, very good at.

And after Claude Code, and I'm a heavy Claude Code user, I just use it for literally everything. I almost entirely live in a terminal now. I'm running Linux on almost all my machines because at this point I don't really need an IDE because before I'd stick with Windows cause like, oh, I need an idea and Visual Studio, you don't want to run in the VM because you want to have the bare metal performance, but it just going to fell off.

I use Visual Studio code and Zed as basically a diff viewer. I'll open them because sometimes as John called out, there's things that you notice that are like, "oh yeah, this auth piece here, I think I need to rewrite a little bit." How do I get to that? You just pop VS Code, go edit it and then back to Claude. Yeah, it's fascinating.

Like if you would have asked me like a year ago, you're never going to need Visual Studio again. Well, never say never. But like I was like, yeah, right, whatever. I'm in the terminal only now.

John: Yeah. There are a few cases that I will bring up that I think and they are such edge cases. So maybe it's like not even worth like hinging an argument on or dying on the hill of. But you know, one, for example, I had to compile a bunch of CGO stuff recently, which for anybody that's built a big Go thing knows is absolutely disgusting because now you're bringing in a bunch of like you know, GCC and C to you know, compile against the tool chain on that computer.

And that's disgusting. So I was having a weird header issue during like the builds. I had to use Delve, which is basically a Go build time and debugger system to like step into that to see like what header file it was actually looking at, which I really don't even think I want any other way to do that besides using an actual debugger in the system. I don't know how Cloud Code would use it unless Delve has an MCP server, which is the thing that immediately comes to mind because you brought up a great example with Ghidra.

It works really well with that and reverse engineering that. So maybe there's a place where the tooling catches up to have MCP servers or capabilities that plug better into those. Another one that comes to mind that I was using a lot that was unlocked by MCP was the Playwright tool set. Where like, you had to use Playwright in these like kind of weird and wonky ways for these like steppers and stuff, right? But then as soon as I could just plug the MCP Playwright stuff into Claude Code, It just basically nailed it every single time.

So maybe that's the unlock. Maybe we just make tools more ubiquitous with like, agentic ways of working.

Den: That's probably what I would bet on is that a lot of tools, like debuggers and stuff, because they were previously visual, now you're like, well, you kind of have to have a CLI for it to work properly.

John: Yeah. Interesting.

Brian: My only use case was I still write my blog post on the editor and I have to see the words because like, it's still kind of wonky writing in markdown for like your blog. But I have kind of moved to like just straight GitHub for some of that stuff because at this point, all the agents and the co-pilots just get in the way and I'm just like, please let me just type.

Den: That's the thing that I've done recently too is I've actually integrated Claude with my GitHub repos. And now when people submit issues, I just ask like, "Claude, go fix this."

And Claude does it. And I look at the diff and again, because I know what the library works and how it operates, I'll be, "Okay. This, this is reasonable. Yep. Oh nope. This here, like, we're not doing caching properly."

So I still apply my expertise to it, but I just like, I don't use an IDE. I have CI jobs that test the stuff, builds. Claude goes and builds it, validates the test, pass, and like, I'm golden.

John: Yeah. Where would you put this with like, writing? Because I still-- And maybe this is, you know, not the thing to do, but I've really held on to writing as something that I don't let agents or I'll do like a final review for, you know, an LLM or whatever, like, throw it in there, be like, "hey, does this make sense?" What prose errors do I have?"And it'll just like fix little things.

But you know, that core, like beginning to end, I still hold on to that as, you know, the writing harness to actually think through problems and things. And I know that some people don't do that. I know Mitchell Hashimoto recently had something where he talked about like, always having kind of a side research agent that will inform some of the like, bigger chunks of quote unquote research or something that he's doing for some big feature sets in Ghostty.

And then I think he'll execute it on that, but have other agents doing other things on all that. So, yeah, where do you see writing in some of this? Which is maybe higher above code, I guess.

Den: Yeah. I have an interesting workflow. So I also, like Brian, I love writing my blog posts and I think I'm very, very attached to the fact that I want the writing to be human and mine because it's a representation of my brain dump process, whatever you want to call it. But I have an interesting workflow. I actually use Wispr locally, so I talk because my-- The bandwidth of your voice is just higher than I can type on a keyboard.

So I would just like, for example, if I'd be writing about MCP, I'd be like, okay, it's like we are building this new MCP extension called MCP app and I would just narrate it and just have like the stream of thought and transcribe it. And then I'll have like this 15, 20 minutes of me just talking about the stuff. It's like all my thoughts are not structured. And then I would ask an LLM to like, break this down into themes and sections and make sure that it's a cohesive narrative.

So just break it down into sections. And then for those sections, it's still the stuff that I narrated. But then I just go and clean it up and I amend it and I'd be like, okay, like, let me rewrite the section to make it a little bit clearer and make sure that I explain a little bit better. And then I ask Claude to go in and be like, "now imagine you are Jeff Atwood. You're reading this blog post, criticize it for blind spots."

And then it would pop in and be like, oh, you're using too much of a cliche terms like "synergy," like, okay, yep, okay, I'll clean that up. So the writing is still mine, but I started leading a lot of these AI tools to operationalize it. I don't know, for some things it works like, it doesn't need to be done for everything for the record.

John: Yeah, interesting. Well, I'll give us one read to wrap us up here. Speaking of Mitchell Hashimoto, who friend the pod we should have on again soon, he released a very interesting project called Vouch, which is basically just a bunch of scripts, a bunch of new shell scripts, but that can read a file in a repository for distributed trust management.

Basically a way to say, like, I vouch for this person or I denounce this person, which feels like a very like video game thing, like you're playing Civilization 6 and you know, denouncing the nation of you know, wherever. But basically Mitchell is using this in Ghostty to prevent or I guess combat AI slop PRs that show up and then he could denounce them and then those essentially get auto closed as they come in from that same user.

So fascinating to me. Brian, you and I could honestly do like a whole hour on this alone because this is very close to something that we built at OpenSauced around this time last year that was like a contributor score essentially.

Brian: Yeah.

John: That we thought of as sort of a like credit score for your open source contributions. Mitchell's take on this is very, very binary. It's either you're denounced and you're out or you're vouched for and you're in. Our take on it was much more I guess gray in the middle like a credit score. If you're like in that 600s range, you know, maybe you had a misstep or maybe you're like up and coming and your credit score is getting better and better and better. It's fascinating. Yeah. Brian, what do you think of this?

Brian: Yeah, yeah. So for listeners it was OSCR (Open Source Contribution Rating) and we sort of had four different pillars to identify like your sway, like how often you leave commentary like on RFCs and stuff like that and conversation generation obviously code quality and like two other metrics that were based around code.

So vouching is really interesting because I think we need something strong and stern because I think we do need to like basically say hey, if you're not really, if you're not meant to like put the work in, we probably can't take more of your slop. And I think it also helps folks to educate the system because a lot of folks are new to open source. I have a twin brother who just recently started getting into coding through Claude Code and Replit so his upstream contributions are going to be wildly inappropriate and just not even needed.

And I mentioned there's a ton of young college students or earlier career devs that will have the same problem. So I don't know, I feel bad for the folks who just don't know how to engage in open source and this is the way they're going to learn. I would like to see more of like a OSCR type rating where like okay, you like just like karma, you can get a hit with a negative 50 karma but you could also get like +200 because you provided some more value on another post.

So I think there needs to be a different spin on it. But I think we can kind of see like water find its own level today. And I think that's where the industry is kind of prepared for that.

John: Yeah, my very hot take is that this is because GitHub hasn't cut a feature for banning people from repos or from orgs. Like it's the same thing. Like basically it denounces a ban from the repo or contributing to the repo or commenting in anything or creating an issue or whatever. And my base assumption for a long, long time was that GitHub was going to have to ship a ban feature. I think it's something that people have been asking for for a very, very long time.

Brian: Yeah.

John: But Den, I'm curious, you know, you're working in a huge open source project now. How have you all thought about AI slop or spam or whatever else comes in that you might need to get rid of?

Den: Yeah, thankfully for MCP itself, we have not had that big of a problem with a lot of the AI driven contributions that contribute nothing. There is a few and we actually on the basis of that we did update our contribution policy. If you're using AI you have to provide an explanation of what you did and why you did it and you should be able to defend what you're contributing and it cannot be like, oh, we asked you to defend it. Like let me feed this into Claude Code and see what Claude Code says about this. Like for those we would just like auto close it and not even bother with it.

But I do agree though. Like we have not had that problem at that scale yet. Mainly because of also the project is very specific, like it's spec enhancement proposals. Right? Like you're not gonna like, not a lot of people wanna just spend time just like let me write and explain how the transports work. It's a little bit easier to do in a project like Ghostty, like because like anybody--

"Oh yeah, like I fixed a typo in your function here. Some or I added this another function to test this other function." So a lot of these drive by contributions become easier and I see why they had to do this.

But I'm with Brian on this. I feel like that nuance is important because sometimes you just have new people that never contributed to this and this is their first time and they're like, "ah crap. I didn't realize that like you don't want me to actually submit like doc comments because they're auto generated. I did not know that. But now I'm banned from the repo." Right?

Brian: Yeah, that's the kind of thing that I remember my first contribution to a Ruby project, I had probably 15 commits and then the maintainer was like hey, can you squash these commits? And the one I was like dude, I have no idea what you're saying. I didn't say that to them directly but this is like man, 15 years ago had no idea what a squash commit was, barely knew what a GitHub issue was, but I was able to navigate to make a contribution.

So luckily that person actually was super helpful. Yeah, ironically Katrina Owen is actually the person that did this for me. She also interviewed me at GitHub. I wouldn't be here if she wasn't so helpful in telling me how to squash commits. I think she actually did it for me, to be quite honest.

Den: That's awesome. And I mean--

It always takes somebody to take a chance on you with these kind of things and help you navigate this. My spicy take here though is that there are projects where I think the maintainer has a prerogative to say I do not want inexperienced people contributing here.

Like because we're, I don't know, working on like shader language, like Linux kernel, right? Yeah like I keep bringing it up because it's an example of like a very major project where like do you want somebody random just coming in? Like I don't know like I don't know, you probably want somebody that's a little bit more experienced with kernels and kernel design and architecture and not just somebody that does drive by, like "I updated the doc comment here."

So I totally envision a world where there's projects where you can say yeah, like this might not be the best place for you to get started with contributions. Like there's other projects that can, but this is not that project and that's okay.

Brian: Yeah, and I think having a historical record of like where you've been denounced or vouched, like just like if you like missed a payment on whatever student loan or whatever, like it's in your record. You can basically like, if you had to like rebut that while you're trying to get your house loan, I think the same thing for contributions at least you have a story you can tell. And I think what we need is more humans to be able to humanize the contributions, whether the AI or whatever.

But with that said, Den, I've got to bounce. I really enjoyed the conversation. We should do this again. Let's catch up in a year and see-- Actually in six months. You said you can't see past six months, so let's meet in seven months.

Den: Absolutely. Let's do it.

Brian: Yeah.

Den: All right, folks, it's been awesome. Thank you for having me.

Brian: Yeah, likewise. And listeners, stay ready.