FastMCP with Adam Azzam and Jeremiah Lowin

22:29Jeremiah Lowin:Sometimes you just need Retool.

22:31Adam Azzam:It's funny, I actually have the counter factual on this one where there was like construction in the office where I normally work. And so like, basically to go build this thing, I had to go work off of whatever some random laptop I had at home. And it had a stale branch of FastMCP on it. Like I didn't pull main. And so I was working on a 2.x branch and I'm working with Claude and I'm like, all right, here's roughly how I want the API to look. Here's what it should do. I'm going back and forth with it. And it comes back with this like plus 4 ,000 minus 2 ,000 change. And I messaged Jeremiah and I'm like, I thought this was going to be such a straightforward change.

23:10Adam Azzam:Like I don't know what's going on. And then, of course, I push it to a branch, there's merge conflicts, and then that's when I realized that, oh, I built it on a 2.x branch. So then I go basically replay my whole session on a 3.x branch, and I think what did it end up being, Jeremiah? The tests are probably 800 lines of code, but the core feature itself is probably plus 500 minus 100. And so, yeah, I actually have the counterfactual here of just three definitely made it a lot easier to actually build these things at the end of the day. Not just more spaghetti tack on.

23:43Jeremiah Lowin:I just looked it up and net of tests, you were plus 1 ,200 and your tests were 500. So yeah, you got it done to a couple hundred lines of code. And that's why we built FastMCP3. We didn't plan this, I just looked it up right now, but that's why we built FastMCP3. So a feature like this, which is transformative, we're going to, after we record this podcast, we have to go in the world and tell people about it. Just shipped last night, but this is a transformative feature in my opinion, and it was a couple hundred lines of code. and that's if you can't innovate at that speed in this like ai crazy world i don't know what you're doing we had to create that opportunity for ourselves yeah so we're going to get on to code mode and it's incredibly awesome that we're speaking to you the day after this thing was created and as you say you're going to go off and tell people and we're doing it in real time so that's that's cool let's just talk about just before that was a thing kind of the i guess the of three pillars, if you like, of Fast MCP.

24:33Jeremiah Lowin:So basically on server, on client, and then the newest before code mode was on apps. So could you maybe just like walk us through those three? Like, let's start with just the one that most people will be most familiar with, which is on server. So servers is the meat and potatoes of Fast MCP. It started Fast MCP 1 is literally how you build a server. Fast MCP 2 is how do you compose a bunch of servers into an application. And now it's really with Fast MCP 3 that we're trying to take a much more opinionated framework approach to the entire ecosystem of MCP. And that's where we came up with these three pillars to organize our work, servers, clients, and apps, because they have very different, well, very different use cases and very different users.

25:12Jeremiah Lowin:And they all show up in this kitchen sink framework. And frankly, we just, Fast MCP is getting very big. We need a way to organize it. And so this is just a very natural way that aligns on, I think, the big initiatives in the MCP space. So when we talk about servers, which is where we focus most of our time on Fast MCP, What we're talking about is you, as the author of code, want to expose it to an agent. And the server category, I think, encompasses everything that could possibly fall in that with a big asterisk because we're going to talk about apps in a moment. So maybe a better way to say that is you want to expose it directly to an agent.

25:45Jeremiah Lowin:Apps will be how you expose it to a human. And what do you need to do? You need to authenticate. You need to authorize. You need to version. You need to maybe compartmentalize and build modular applications. You need dependencies. is you need latency, you need middleware, you need transfer, all this stuff that it takes to get it in the world. Can we as framework authors come up with a sane set of common sense defaults that let you ship a server as quickly as possible while still exposing all the knobs in the place you'd expect to see them on the control panel so that you can build your own? Fast MCP tries to expose as much of the configuration as possible, but it is not our goal.

26:23Jeremiah Lowin:If you really want to build this thing from scratch and exactly the way that you want, then you really should be using the actual SDK. Fast MCP is not trying to funnel you to the SDK. We have an opinion represented in code about what the happy path is for the vast majority of use cases that we are fortunate enough to now see in the world. And that's what Fast MCP is. And so that server bucket really encompasses, I think, the vast majority of that capability. The client bucket is probably not what most people think. And Adam, maybe I'll turn it to you. Although having said that like weird cliffhanger, I won't leave it to you to fill that out.

26:57Jeremiah Lowin:But what I mean by that is we're not trying to build an LLM client in Fast MCP. We're trying to make sure that you can interact with a server at all. So Adam, I don't know if you want to pick up there maybe.

27:07Adam Azzam:Yeah, so if a server is really like, how do I write business logic that can be exposed over the wire to an LLM to call, right? So like a server, you can think about as a big bundle of tools, data, slash commands, you know, that kind of stuff. It's a portable tool set, you can, if I take an MCP server, and I author that business logic once, then the promise of MCP is that it can be used wherever MCP is accepted. So that's Claude in the web for maybe technical, non-technical folks to use. ChatGPT for non-technical folks can be used in Claude code. It can be used in your favorite LLM framework. So clients then are really basically the means through which you can consume an MCP server.

27:50Adam Azzam:And clients, for every protocol rule about building a server, there's probably like, or for every five rules about building a server, there's one for a client. So like clients tend to be very unopinionated or there's not a lot of opinions about how you should build clients. What clients have to do at the end of the day is they have to connect to the server. They have to go peruse what tools are available and then represent that somehow to your base LLM client. And so there's a lot more design leeway in how people build clients that really impact the end user experience. I'll give you an example.

28:25Adam Azzam:In Claude Web, that's an example of they have an MCP client. And when I log on to like Claude's web client, and I put in an MCP server, they will go and they will fetch every single tool. And on the first chat that you have with Claude in the web application, it will say like, Gregory, you'll be like, hey, what's the weather today? And every single MCP server that you have connected to, it will take all of those tools, all the different representations of them, all the arguments, keyword arguments, whatever. and then also go shove them behind the scenes into the context window of your LLM. That can maybe penalize or lobotomize whatever LLM that you're working with because you're stuffing it full of context that it may not be relevant to it.

29:08Adam Azzam:There are other MCP clients like Claude Code, which now dynamically searches across your MCP catalog. So Claude Code, you can go stuff it full of 100 ,000 tools. And if you say like, hey, what's the weather? Like all of us normally do with Claude Code, of course. instead of going and taking every single tool and putting into the context window, it'll actually do like, I think it's just BM25 search over all of your tools to go highlight like which tools are most relevant to this query. And so servers tend to, the business logic that you write, that is maybe like what informs the quality of a server.

29:44Adam Azzam:MCP clients tend to differ wildly in their design and quality, because MCP clients, they don't have to support the full specification, many of them only work with tools, half of them work with resources, which is another part of the spec, maybe another half work with prompts, maybe another half work with tasks. And so your mileage may vary with clients. And that's really where like, what I find are the distinguishing, that's actually really what drives my choice to use any one specific provider at the end of the day, like whether it's Claude or ChatGPT or something like that. So that's clients.

30:22Adam Azzam:Clients are really like, they own the responsibility of talking to the server, understanding what capabilities are available, and then choosing how to represent those tools to the base LLM at the end of the day. And then applications, maybe I'll tee up the first part and pass it back to you, Jeremiah, is like MCP apps at the end of the day, they're sort of born out of the following problem, which is, Gregor, you and I are going to go build an MCP server that it's a search over like restaurants in New York City or like Northern Scotland or something like that. And Jeremiah gets into Claude Webb and he says like, hey, I'm going out to dinner in Northern Scotland tonight.

30:57Adam Azzam:Like, what are the best places for me to eat? And what Claude Webb is going to do is it's going to call our MCP server that you and I wrote. It's going to get a big like list of restaurants and it's going to just render a long markdown list of like, great, here's the hundred restaurants that were returned to me from the server or something like that. And what MCP apps did is they said like, well, look, like we've got, I don't know, how long have we been making user interfaces? Like 40 years or something like this. It basically acknowledged that like, in the last 40 years, research did not conclude that markdown was the best way of presenting information to human beings, that there's better visuals.

31:35Adam Azzam:Like maybe I actually want to see a photo of the thing that I'm trying to buy. That helps me make a decision. Maybe instead of seeing like the number of stars in Markdown or seeing like a list of dishes they have in Markdown, maybe I want to give people the ability to like peruse through those photos or swipe on them or read reviews, that type of stuff. And so MCP Apps kind of was born out of this. We've spent a lot of time figuring out that there are better ways of presenting information to humans to make a decision. So in an LLM client, restricting ourselves purely to text in and text out really limits the interactions that we can have with a system through an LLM.

32:15Adam Azzam:And so MCP apps were really born out of this, like, what if the server, instead of just sending text that your LLM will render as Markdown, what if the server can send data and a representation of how to render it? And then the LLM client can take on the responsibility of rendering that in the way that the server is dictated. And so that's where basically you get a really, really cool design space that you didn't always have with MCP out of the box. Jeremiah, anything to add there?

32:46Jeremiah Lowin:I think if it's interesting to the listeners, we can talk about sort of our unique take on this and where I think we can add some value as a framework. Also in clients, right? So these are related. I'm just going to say like most MCP clients are terrible. They implement tool calling and they are probably solely responsible for most of the legitimate charges that MCP has failed to reach its potential. Because, yeah, you are correct. Most clients can't do the majority of the things that MCP is intended to do. And that's a real problem. And so even testing is one of the reasons we introduced Fast MCP's own clients.

33:17Jeremiah Lowin:So we could just have good deterministic fast tests of our own servers. And so that's really an angle we're pushing on. I'm very concerned that apps, which I think are a phenomenal innovation for MCP, will also be left by the wayside by most clients. And so I think it's even worth shouting out a few of the ones we like the most. Goose is a phenomenal client. VS Code is a phenomenal MCP client. Cloud Code is a phenomenal MCP client. MCP Jam is a phenomenal MCP client. There are probably others. I don't mean that's an exclusive list, but those are ones that I use regularly. And I use them because I can test the entire range of MCP and I can do cool things.

33:49Jeremiah Lowin:And one of those cool things is build apps. Adam and I were chatting on our podcast, which compared to SE Daily is like a digging next to an ocean liner. But nonetheless, we were shouting into the void about apps and talking about how it's a little dismaying that the first crop of MCP apps are basically SaaS applications stuffed into a chat window.

34:09Adam Azzam:The promise of MCP was like, you don't have to go browse people's SaaS apps anymore. Instead of 12 SaaS apps, you get everybody's SaaS data inside of one LLM client.

34:21Jeremiah Lowin:I think it's good. It's useful for all the reasons Adam said. But is it really the promise of the user experience that we can deliver right here? And so when I think of where things break, and Fast MCP's roadmap is primarily defined by what is hard. Building service is hard, we make decorators for that. Authenticating service is hard, we make one-liners for that. right? Deploying service is hard. We built a product for that. Everything is dictated by what's hard. What's really hard right now is working with large amounts of data, which is a world that we know intimately from Prefect and from our professional histories.

34:50Jeremiah Lowin:If I go off and I run a SQL query or something against a database and I get 10 ,000 rows back, what are we supposed to do with that? Either that's going to be stuffed into my context window so the LLM can tell me about it, or we're going to have to now go write some summary of that, which is going to take time and latency and tokens and maybe not be what I want. What I really want when I make a query against a database and get so much information back is I want to probably either browse it myself or plot it, get an impression of it and go on and do that in an interactive way. And so that's the type of thing where I think MCP apps almost, I've been calling them mini apps.

35:23I don't know if that will survive as a vocabulary, but little discrete interactive experiences that

35:28Jeremiah Lowin:let me step around the context window and not pollute it with all this nonsense, but just let me access the result of something. So I think showing charts, showing data tables, and showing forms, I expect to be something like 80, 90 % of all of the MCP apps use cases, because it exactly satisfies this idea of let's exchange information interactively between the MCP server and the user who's interacting with it. And let's not force the LLM's context window to be a part of that conversation. And so when I think about this, I'm a Pythonista, Python guy, whatever. I don't know what the term these days is.

36:08Jeremiah Lowin:I love Python. I think it's a phenomenal language. Thanks to Claude, I probably can write in any language I want, but the language I know and have opinions on and know how to think about idiomatically is Python. And so when I think about the opportunity that there is to introduce these interactive applications as MCP apps, But then for obvious reasons, all of the weight and gravity there is in the JavaScript and TypeScript, MCPSTK in particular. It made me wish that there was a way to do that in Python. That's a very dangerous wish, right? We are not trying to port front ends to Python. But the other thing that's been on my mind is generative UIs.

36:45Jeremiah Lowin:So what if the agent just wants to show me something, but I haven't bothered to pre-program it as an MCP application? And so another late night conversation between Adam and myself led to the idea of a JSON protocol that itself could compile to a limited but highly functional React application. And now all of a sudden an LLM can write JSON, a human can write with a nice little Python DSL, and you can quickly compile these restricted but functional web applications. And so this is another thing that we have not really talked about publicly except kind of cryptically. So I guess this is the first real time.

37:20Jeremiah Lowin:But we've been building this in the open and, you know, folks have been kind of drive by and peering in and saying this is interesting. And it is interesting because, you know, like some of the cases, admittedly, I don't use MCP a whole ton. Just going to put that out there, but that's not any shade against MCP. That's just purely my functioning professionally, etc. But when I am using LMs, which I do use a lot, and something vaguely complex has to be given back to me and in an interactive way, it then just becomes a entirely written React app. And I'm like, there must be a better way than an LLM just going from scratch on a React.

37:56Jeremiah Lowin:And I hit the stop button and say, no, no, no, no, you're not going to create a React app to show me this, I don't need that. But there has to be a better way. That's exactly it. And so my dream is that as an MCP author and fast MCP, if I know that I'm getting a bunch of data back, I want to return a bar chart in the same way that I would return a dictionary or a Pydantic model or something like that. That's what we have been building. It's called Prefab. It's in the universe as an open source project. And it is a very simple DSL for building these interactive applications. And we're building a native integration into FastMCP so that you really can import the bar chart component and return it.

38:32Jeremiah Lowin:You can import the data table and return it. You can build forms from Pydantec. You can do all this stuff. And the goal is, yeah, someone is using, say, the Superbase MCP server and they want information. 10 ,000 rows come back. The LLM can decide how to present it. The MCP author can decide how to present it. It's all possible. And we don't need to go to a different ecosystem, which aside from just being different, which for someone like me is going to be a pretty big friction, a big hurdle to actually bundling an app. It also means that you have this weird tight coupling where how do I know that my app and my MCP server are in sync?

39:06Jeremiah Lowin:What if I change the name of a tool on my MCP server? Do I have to remember to go to my other application now that's tightly coupled but independent? We don't like that. We want it to be one place, one happy path. And so we're trying to solve for that without re-implementing the front-end world. And that's been a real adventure. That's probably one of the crazier projects I've ever worked on that has now really overspilled its bounds. And we'll really be talking about that a lot in a couple of weeks when it's more ready than it is now, I guess. Let's talk about Codenote then. So this ultra new flavor, like you're clearly very excited about it.

39:37Jeremiah Lowin:So I want to hear more about it.

39:38Adam Azzam:So we talked earlier about like MCP clients and their relationship to servers, right? So an MCP client takes on the responsibility of getting all the capabilities that are available on the server and then choosing basically what to do with them. And the default for the longest time was go get all the tools, present them all to the LLM at the same time. This is where you get like context bloating that, you know, over the last few months. And then you also have this pernicious problem where the LLM will, if you pass all those tools to an LLM, the LLM will invoke those tools serially. And so it'll call the server that you and I authored, it'll get restaurants in northern Scotland, and then I'll say, okay, this restaurant looks great, and it will go fetch reviews.

40:23Adam Azzam:And then after I say, okay, it's well reviewed, then it will go and it'll fetch the menu items. And then that's when we discover that like, you know, I don't like the food or something like this. But you'll notice that the LLM is invoking one tool after another. And if you take a step back and you think through like mechanically what's going on, it's, you know, you're taking a conversation up until, you know, end messages. You're invoking a tool. You're appending that. You're shoving that back over to your server. comes back, you append another tool, you shove that entire thing back over to the server, it means that unless you're managing caching yourselves, then you end up having this quadratic number of tokens as you keep having a conversation, one message over another and shoving it back to the server every time.

41:11Adam Azzam:And there were a couple of swings at how to solve this problem. So it starts off with the team at Block, who a few months ago, I think actually was one of the folks who pioneered this pattern of, well, if you've got like a thousand tools on the backend, you probably don't want to like just lobotomize your agent with a thousand tools. You should probably give it access to search and then you should give it access to execute. So instead of giving it a thousand tools, you give it a tool to search over your tool catalog. And so it's going to, you know, return the three tools that are most relevant.

41:47Adam Azzam:But where block stopped is block was like, great. And now you've got those three tools, and then Claude will execute those tools one after another. The company who kind of said, like, all right, hold my beer, like, I'm going to check raise this idea, was Cloudflare. So Cloudflare came out and they said, like, that's actually, I think Kenton Varda is his name. I might be butchering his name. But he basically, I mean, this is somebody who's been working on just like RPC for a while. And he was basically like, well, look, I'm glad that block was able to reduce context bloating with this search tool.

42:23Adam Azzam:But the idea that it still has to call tools one after another, that kind of seems goofy to me. Instead, the key observation that I think that team had was most LLMs are great at writing programs. So instead of forcing it to execute a program of call this thing, then pause, then call this thing, then pause, why don't we give it the ability to author a program in the actual tool set that's been provided to it? And so what this means is that in code mode, you give your LLM client, you basically give it a search tool to search over an entire catalog, and then you give it the ability to write basically a program in your MCP tools.

43:02Adam Azzam:And so what that program is going to look like, it's Cloudflare, so it's TypeScript on their end, where they're like, great, first, I'm going to, in parallel, go get the top 100 restaurants in Northern Scotland. Then, iterating over all of those, I'm going to go fetch their reviews and go fetch their menu. Then I'm going to take this data, then I'm going to go do something with it. And so if I wanted to go get 100 restaurants, and then for each one of those restaurants, go and get their reviews and menus or whatever, in traditional MCP clients, you're making hundreds of tool calls, which means you're making like, you know, n squared number of tokens you're submitting back and forth to the server.

43:41Adam Azzam:And so it's really, really cumbersome. and so they basically on the client side a few months ago were like great so i'm going to show you in an mcp client how to to author this so i can execute a program against the server and it was a hit and it sparked a lot of discussion but ultimately it was a client concern which was tough when something is a client concern think about it from the perspective of an author i've

44:07Jeremiah Lowin:got to interject for one second listeners know me as living in singapore which i do but i happen to be Northern Scotland when we're recording this. So that's why Adam keeps talking about Northern Scotland. We would be talking about Singapore a lot, but we're talking about Northern Scotland, which I love, which I love. But that's why you need to know about the restaurants because you happen to be. I don't have as much knowledge up here of the restaurant scene. So this is, keep rolling on it because it's good. It's good.

44:28Adam Azzam:Okay. Okay. But think about the experience of you and I writing this server. So like you and I, we both quit our jobs. You and I go write this like restaurant MCP server and we're going to stake it all on it. And then what happens is like we start going and we share this thing. And the feedback that comes in is people say like, oh, man, this is amazing. I use this in Claude and this was the best experience ever. And then somebody uses it in chat GPT and they're like, this MCP server sucks. Like I can't get it to do anything. And that's infuriating as a server author because you're implicitly depending on separate clients to all have the same behavior.

45:03Adam Azzam:And so Cloudflare had this great idea, which was how do you let clients author programs against servers, but where it kind of failed to get adoption was like, all right, that's cool, but I'm never going to be able to get chat GBT to know that it has to write a program. I don't have access to that client. I can't go request that it operates in code mode. And so I think it was about three weeks ago that Cloudflare was like, well, why did we need this thing to happen on the client. And it was because, well, the client has its own secure runtime. And so we can author a program. And we don't have to think about the security of like, executing untrusted code.

45:49Adam Azzam:But as I'm sure folks listening know, is like, there's also kind of been another separate renaissance in, let's call it AI infra the last few months. And that's really been the focus on, let's call them code sandboxes, remote sandbox execution. And so Cloudflare was like, well, look, we can actually take this thing that you had to be lucky if a client implemented it, and we can actually make it happen server-side, as long as that server is equipped with basically a secure primitive to go execute that untrusted code. So Cloudflare has its own sandbox runtime, So it was also a good advertisement for Cloudflare.

46:28Adam Azzam:But the real excitement from us came from is like, well, now you and I, again, you know, we go to jobs, we build a server. Now what we can do is we can say, hey, on the server, I'm going to just expose two tools. I'm going to let people search over this giant catalog of tools behind the scenes. That's always existed. But now I'm going to let my clients submit code. And then I'm going to take on the burden of securely executing that code against all of my backend tools. And so that's code mode in a nutshell. Code mode started as a client concern where you had to be very lucky and fortunate that you were using a client that could support it.

47:05Adam Azzam:And then now where Cloudflare, I think, really pushed the envelope was saying like, well, you know, now that sandboxes are pretty good, we can actually, in a very low latency way, go and execute untrusted programs that are written in your MCP tools. And so last night what we did is we basically shipped, you know, hey, in a line of code, like, you know, this MCP server that you used to ship that had like 300 tools on it, just enable this option. And what we'll do is we will expose it, a search tool over your catalog of tools, and we'll give you a means of executing code written by your clients that connect to it.

47:46Adam Azzam:And so you can bring your own secure sandbox runtime. You can use Modal, Daytona, Cloudflare, whoever you want. But what we ship with out of the gate is a secure local sandbox environment that was written by Pydantic. It's a new project that there's called Monty. And so they basically allow you to, a handful of microseconds, spin up a secure local runtime, basically like a subprocess but safe. Like Samuel's going to kill me. That's not the right way of describing it. And so we finally, I think, have a really happy with what we got out, which is basically now your clients can submit programs over your MCP tools.

48:29Adam Azzam:You can spin up a local sandbox thread that executes that program. And that little sandboxed thread only has access to those tools. So it can't go do funny stuff. You can make sure that it only has specific resources. no other connection to the internet. I mean, we've run a bunch of tests on it. We've run it in our own MCP server, and it's been great. The downsides are when it's sideloaded against a bunch of other code mode servers. If the Supabase one is running in code mode and the Prefect one is running in code mode, Cloudflare is running in code mode, what does Claude see when it opens its eyes?

49:06It sees like, oh, should I call the search tool

49:09Adam Azzam:the search tool or the search tool? And should I call the execute tool execute tool or execute tool? And so there's still some namespace collisions. I'm sure that that'll evolve a little bit. But for a single server, it's definitely a huge improvement.

49:21Jeremiah Lowin:Amazing. This will get released probably a couple of weeks after we've spoken, but this is available kind of now. Is that right? That went out last night as we were recording this in Fast MCP 3.1. And what I'm super happy about, aside from the fact that it works really well, is it makes the bet we made in the 3.0 re-architecture. So Visceral, I already mentioned that Adam's PR itself was small. But for example, one line of code, add code mode to your server. Two lines of code, add code mode to somebody else's server because we can proxy it so quickly. Three lines of code, add code mode to somebody else's server and customize the search tool because you know that they have a ton of tools and you need to like that sort of progressive incremental complexity where you only need another line of code to add one more feature is what we're trying to achieve in building a really effective toolkit and framework.

50:09Jeremiah Lowin:And so I'm just very happy with this as like a proof point of a lot of decisions we made over the last few months. yeah and as you said i mean like the sandboxing part that's super interesting and you know we're seeing a lot of players go the sandboxing route now and well pydantic being kind of what what was

50:24Adam Azzam:the name of the pydantics version it's called called monty monty there we go i had sam on for

50:30Jeremiah Lowin:an episode not that long ago so yeah go check that out listeners if if you're interested to hear sam talk about all things pydantic ai but yeah monty great choice so it's a nice segue though when we talk about sandboxing because what is not sandboxing is OpenClaw. So I think this is perhaps what some of our listeners might be thinking now and sort of as we go into our vaguely landing the plane phase of the episode, I want to just talk a little bit about OpenClaw and I want to also just talk about MCP's current and future state when it comes to what some developers might be thinking right now. So let's just quickly touch on OpenClaw.

51:06Jeremiah Lowin:What were your reactions and did you ever look at that and think oh like this is going to have an effect on sort of how mcp is is viewed or anything like that i'm just curious like because it had such an explosive landing in the for us as developers and even non-developers who come across it but like from your perspective what did it look like and feel like i love it i think it's phenomenal i've now deployed three iterations of my bot where i've slowly trusted it more and given it more capabilities But I'm still a little, you're always a little nervous when you have something like this, right?

51:40Jeremiah Lowin:But it's been an incredibly useful thing to me. I actually started as a family-focused bot because I realized every company in the world is trying to sell me productivity software at Prefect. Nobody seems to be trying to sell me productivity at home. And I have a lot of kids. My wife and I both work full time. And there's a lot to do there. And so I actually started it just at home, managing, like keeping an eye on my school calendar and what the kids need. And it's been phenomenal. and so I've been slowly trying to find a role for at work. MCP shows up because we have to wonder how do we give it new capabilities?

52:12Jeremiah Lowin:And that's sort of the promise of MCP. Now, OpenClaw doesn't ship with a native MCP integration. Pete has a tool called MCPorter, which is a tool that converts an MCP server into a CLI. Fast MCP has a similar functionality. It's very useful in a lot of different cases. I think what it is proving out there for is the need for something like MCP, whether it is MCP or not, which is a weird thing to say. But something Adam and I spend a lot of time discussing in these arguments is forget MCP. Let's just say that we want to add capabilities to an agent. Someone somewhere needs to define how those capabilities are accessed and what they look like.

52:50Jeremiah Lowin:And if you want that to be a CLI, that's fantastic. Let's make it a CLI. So now I need human written natural language help docs. I need a way to discover the commands. I need a way to discover the arguments. and before you know it, you end up inventing some sort of protocol for communicating this information up front. Today, that protocol happens to be called MCP. And if you want to implement MCP via CLI, that's great. If you want to implement CLI without the MCP, that's great too, but do expect your agent to spend a lot of time discovering it. So my open claw manages to kill itself about every hour because I ask it to do something.

53:23Adam Azzam:How bad is your calendar that it kills itself when it looks at it?

53:27Jeremiah Lowin:What I'm trying to do is I'm trying to get it to install some new audio transcription software, and it keeps hallucinating a CLI argument that there's an output directory. This just happens to be what I was struggling with this morning. And it keeps adding this into the OpenClaw config, and then it keeps restarting the gateway, and then it keeps killing itself because that doesn't exist, and it keeps making an illegal call. And so this is where I feel the pain of, oh, if only I had a tool that just broadcast exactly what was available and how to call it instead of having to write everything from scratch.

53:56Jeremiah Lowin:Now, is that a reason to use MCP servers? No, MCP servers have other baggage that they bring, that they're not as easy to install, that they're not just written out as text, that they have to be hosted. There's all this stuff. So I'm not trying to make a strong argument that OpenClaw should or should not embrace MCP, but I am trying to make a very strong argument that no matter what the technology and the transport is, we will need a protocol by which people who write software and people who consume software, in this case, agents who consume software, agree on the contract of that software. What is the UI, so to speak, the AI, I guess, to use a bastardization of that initials, of using this software?

54:33Jeremiah Lowin:And that's not going to sound as good to anybody, but MCP happens to be the prevalent way of doing it. And so what's been really fun is we're focused mostly on how you build the MCP servers. You want to deliver them as a CLI? By all means, go ahead. I think that's fantastic. I think it gives you as a server author a way to know for a fact that your software will be used with, you know, first try in the correct way. And it's our obligation to make that as easy as possible. And so I keep bolting new MCP servers onto my agent because it's easier to bolt someone else's hard work to build an effective server than have my agent write a wrapper script around a CLI to make it comply with what its expectations are.

55:10Jeremiah Lowin:But I also use CLIs. I think at the end of the day, we're just trying to give our agents superpowers. And that's also a nice segue into, in terms of when we're recording this, this was one day ago quite sort of high up on Hacker News was an article, when does MCP make sense versus CLI? Very timely. So rather than go through the whole thing, we're not here to dissect a Hacker News article. But at the end of that article, the person says a plea to builders. It says, if you're a company investing in an MCP server, but you don't have an official CLI, stop and rethink what you're doing. Ship a good API, then ship a good CLI.

55:45Jeremiah Lowin:The agents will figure it out. And I guess you've kind kind of semi-answered that already, but I mean, I think it's just interesting to hear what you say to that. Adam and I have a hard-won opinion that really affects how we view arguments like this, and it has to do with where MCP is being deployed. The vast majority of MCP use cases are inside companies for that company's own employees. The vast majority of MCP use cases that the average person is aware of are when companies release an MCP server for the use of their customers. We call that external MCP as opposed to internal MCP. If you are a company who is deploying an MCP server internally, you absolutely should not make it a CLI.

56:23Jeremiah Lowin:You absolutely should make it an MCP server with a tight contract. You control the server. You control the client. You don't have to waste time building a client that knows your CLI. You get all the benefits of MCP and it's fantastic. And that's more than 80 % of the use cases that we see every day. And at this point, FastMCP, I think it was downloaded like 2 million times just yesterday. We see the market. We know how people are using the software. With that said, I also understand that for the average person, they see MCP through the lens of a restaurant browser for Northern Scotland, and they may say, you know what, this MCP server could have been a CLI, and they may be right in that instance.

56:59Jeremiah Lowin:And so this debate has taken on a very weird tenor where the median person doesn't see the median use case in a really interesting way, which I think there's probably some statistical paradox name for that, that I don't know, but I probably should. And as a result, we find ourselves arguing strenuously to companies to take advantage of all the contracts that MCP affords them for these internal use cases, where we see, you know, if the long tail of MCP servers, I'm going to say finger in the air, there's 20 or 30 MCP servers in the world that are popular, and then a long tail that have zero or one users.

57:30Jeremiah Lowin:But inside a given company, some of the enterprises as we work with, there are hundreds of MCP servers that are heavily used by only the, say, 5 ,000 employees of that enterprise. That's where we are focused on MCP as a primary and enabling technology. And all of these arguments sound ridiculous in that setting. And so I think it's a really complicated thing where I see these arguments. They make sense to me as a consumer. Give me the easier thing. Give me the more flexible thing. Just do the thing that is the most fungible. But inside an organization, I don't think that makes any sense.

58:03Adam Azzam:Yeah, maybe two things I'll add on this is just like, I think CLIs are probably a good MCP client. Like if you squint your eyes, which is like, they can be good at consuming an MCP server at the end of the day. I think that a lot of the appreciation for CLIs is just that like MCP clients tend to be really bad. But if you go like actually introspect the tokens that are sent to the LLM at the end of the day, great. Take a CLI. What's the first thing an LLM is going to do? if it can even discover that it has that CLI available to it. It's going to call like CLI dash dash help. And what's CLI dash dash help going to do?

58:41Adam Azzam:It's going to render all of the options that are available to it in its CLI. That's going to be more or less the same amount of tokens as rendering the list of tools that are available to it. That gets shipped over the wire. Then what happens next? Then it says, great, CLI Supabase create. I'm going to just whatever. or a CLI restaurant finder find or something like that. Great, cool. And then what it's going to do is it's going to add an argument that's maybe of the wrong type. The server is going to reject it because you built that great API on the backend. You're going to get a 422 error also shoved into your context window that's going to say like, you formatted this request wrong.

59:20Adam Azzam:And on the MCP side, you pay that tax upfront, depending on your client that says like, by the way, here's the JSON schema of like how to format your data so that the LLM has better type hints of the type of data that's going to be accepted by your backend server. And so like, I think that just empirically, the amount of, like I made a bunch of CLI requests and I had to guess at what the signature it is of the backing thing, that can be pretty tough. Or you go and you include all of that in your CLI anyway, and then you're just consuming just as many tokens. And so like, I find those kinds of arguments on like a token consumption business side, kind of pretty unconvincing.

1:00:00Adam Azzam:I'd say the second bit, this kind of fits Jeremiah's picture of like inside of an organization is like, I'm not trying to be like a merchant of complexity here. But genuinely, like, when I say the word governance, I don't mean like, you know, some bureaucrat sitting in a company that's like, trying to make up weird data rules. But genuinely, if I have an MCP server, there are going to be tools that can mutate and destroy data. And there's going to be some that I can just read data. And even if you built an API for your company, everybody can internalize the fact that, Gregor, you should probably get read access on Prefect's MCP server, like if we gave you access to it.

1:00:38Adam Azzam:You should probably get read access to data. You probably shouldn't get delete our internal data tools. And so what that means is that I have to have some backing server that looks one way when you access it, and it looks another way when Jeremiah access it. Jeremiah is my boss. So when Jeremiah sees that server, he should probably get some extra super special tools that I don't get access to. And so this idea of how do you get this many faced API that represents itself one way to different people, depending on their permissions, that's like a thing that's somewhat inexpressible through classic REST.

1:01:14Adam Azzam:The other bit of these, MCP tends to take on longer running tasks by virtue of just the types of things we're trying to get it to do, which means that sending progress notifications tends to be a thing. The reason why I bring this up is great. We have REST APIs. Fantastic. Great. So we have REST. We want it to be stateful, identity aware, so it can reveal different interfaces to different people. it should be bi-directional so that I can give people progress updates on long-running stuff. Okay, call an MCP or go implement that. You're like, you're inventing a protocol either way. And so I think that I don't want to forgive the sins of the current state of MCP.

1:01:55Adam Azzam:I actually think it's pretty tame at the moment. I think there were some legitimate gripes over last summer. But maybe what I would pose to folks is just whether it's an API or a CLI, like you want to represent different capabilities to different people. You don't want to have to give everybody API slash V2 slash safe slash Gregor slash Scotland slash Singapore V3 final final. You want to just give them like superbase.com slash MCP or something like this. And once you commit to that as a design philosophy, which we can debate is a good philosophy or like a good design goal or not, then to what Jeremiah said, all right, you either get MCP or you're inventing a new protocol or you're trying to get like hypermedia as the engine of all state, but trying to get people to adopt that.

1:02:41Jeremiah Lowin:You get into this place real fast. I like what you just said there, right? It's much more fun to debate the design of it than the implementation to transport of it. Like that's ridiculous. And a lot of the critiques that you levied, they have solutions. A lot of them are solved by skills. And people also say, well, skills versus MCP. I'm like, no, skills with MCP. A skill helps you learn how to use a CLI. A skill helps you learn how to use an MCP server. Or skill helps you decide if you even need an MCP. Like there's all this wonderful stuff in the ecosystem for enhancing the context of your LLM.

1:03:11Jeremiah Lowin:I think at the end of the day, the most important thing is just do it in the way that the LLM understands. I think MCP is more LLM native than not. So I would do it with MCP. But they're powerful little creatures. They can figure it out. Maybe we can give them a hand. Yeah, well, I don't want to say a convincing argument because at the end of the day, it up to the developer to have figured out what they need. But there's clearly a massive use case for MCP. I think the thing we could agree on, like indisputably, is that you should always build a product for its user. That is one probably the most true thing that I believe in my career is design the product for the user.

1:03:48Jeremiah Lowin:CLIs are not designed for agents.

1:03:50Adam Azzam:So... Well, no, no, but CLIs are designed for like terminal agents. And I think that that's fine, right like fair fair fair get chat gpt to use your cl like if i went to chat gpt and i was like all right go call the github like now i'm depending on this one client to have a a little vm that actually has any of these clis on it and it's just like i get it if you're a developer a cli is a native thing for your clod code client to to call out to i get that so we're gonna leave it

1:04:20Jeremiah Lowin:there i must make sure that my colleagues are happy with me we're all in on mcp as a base and it's mcp.superbase.com so i will oh that's sorry oh you were so close yeah yeah yeah but we're all on on it and i know we've got users absolutely loving superbase's mcp but i'll stop plugging

1:04:35Adam Azzam:superbase there yeah i really enjoyed collaboration with superbase on launching the while we're doing a superbase commercial the 2.1 oauth support yes that was huge yeah yeah yeah yeah that was a fun

1:04:46Jeremiah Lowin:collaboration and as i was we were talking off audio before the episode i discovered you guys in our Slack, which is always fun when you're about to speak to someone and then a colleague says, oh, you know, go over to this channel. They're in there, which is always, I love that about Slack that you kind of have all these intermingling or company to company. But I digress. Fortunately, we do have to wrap up. There's so much more we could have talked about, but as is always the way. In terms of classic kind of where to go up and running and also just contributing, do you have like quite a large contributing community or what does that look like?

1:05:19Jeremiah Lowin:We do. I'm really proud. I think we have 200 individuals have contributed to the FastMCP code base at this point. Another eight joined the ranks last night in the 3.1 release. It's just, it's really cool to see. Anyone who wants to get involved, we do welcome it. The repo is at github.com slash prefecthq slash FastMCP. That's where you can find us. I already mentioned, I think in this conversation, I get a notification on everything. I can't quite keep up the early Prefect 15 minute response SLA, but I do do my best and would love to collaborate with folks to make the framework as great as possible.

1:05:53Jeremiah Lowin:Docs are at gofastmcp.com. You can find Adam and myself probably on your favorite social network, wherever that might be and Prefect at Prefect.io. Amazing. Well, Jeremiah, Adam, thank you so much. We've heard tons today and yeah, this has just been a really fun one. Always fun to have two guests, not just one. So yeah, thanks for coming on and i'm sure we'll be catching up again in the future thank you so much for having us thanks for having us see you in singapore yes yes cheers