Developer Week Day 1: Cloudflare is where you build AI Agents
Presented by: Ricky Robinett, Dina Kozlov, Sid Chatterjee, Sunil Pai
Originally aired on April 7 @ 12:00 PM - 1:00 PM EDT
Welcome to Cloudflare Developer Week 2025!
Cloudflare Developer Week April 7-11, our week-long series of new product announcements and events dedicated to enhancing the developer experience to fuel productivity!
Tune in all week for more news, announcements, and thought-provoking discussions!
Read the blog posts:
- Piecing together the Agent puzzle: MCP, authentication & authorization, and Durable Objects free tier
- Introducing AutoRAG: fully managed Retrieval-Augmented Generation on Cloudflare
- Cloudflare Workflows is now GA: production-ready durable execution
- Welcome to Developer Week
Visit the Developer Week Hub for every announcement and CFTV episode — check back all week for more!
English
Developer
Transcript (Beta)
What's up, everybody? It is Developer Week. I am Ricky coming at you live from New York City and super stoked to be chatting about a bunch of the stuff we launched today with some of my favorite people, not only from Cloudflare TV, but from all over the world.
But we have a friend joining as well. Let's start off with some quick introductions so everybody knows who we're chatting with.
Dina, you want to kick us off?
Sure. Hi, everybody. So excited to be here. Happy Dev Week. I'm Dina.
I'm on the product management team working on developer platform. And these last few months, I've been lucky enough to get to focus on MCP and work with our engineering teams.
I will pass it on to Sid. Thank you, Dina. I'm Sid. I live in London.
I've been with Cloudflare for about a little over three years now. I am an engineer and I've been building workflows for the last year.
We just spent GA today.
Yeah, we're going to talk about that. Yeah. Sunil, you want to go? Hi, my name is Sunil.
I'm a principal engineer. I hack on AI agents and real time stuff. I've been around a grand total of about two years, but I had a little bit of a startup stint in the middle.
And I'm happy that we are giving out more free shit to our users today.
That's quite nice. Always, always a good day when we give out some free shit.
And Max, why don't you close us out? Yeah, my name is Max. I'm a software engineer at Stitch, where I work on our identity and access management products.
Lately, I've been looking a lot at the intersection of OAuth and MCP servers.
Super, super rad. And the theme of today is a lot around agents. I'm going to give this one to Sunil, but anyone can chime in.
Sunil, the billion dollar question.
How do you define agent? What is an agent to you? And you're muted, so if you're about to drop knowledge.
Sorry, I wrote that. I think it's something. Okay, so I think like LLMs do three things, right?
They convert unstructured data to structured data.
They convert structured data to unstructured data, and between different formats.
I think an agent is something that can take that and convert that into function calls and then loop on itself.
I think it's as simple as that. Like, it can take in some input either as natural language or some other data format.
It can say, oh, I have access to these 10 functions. I'm going to use this input to say, oh, scheduler task.
Oh, make a call to GitHub MCP server. Oh, to do a call to this, do a call to that.
And then after that's done, it can decide to do it all over again.
I think that's the most closest thing to everything agent that people talk about.
I like it. I can always count on you, Sunil, to explain it in a way that I can understand.
It helps when you're as stupid as me and you need to understand it as well.
There's a base level, hey, like, if I don't understand it, then there's no code happening on my side.
I'm going to let you get away with that one, but, you know, I don't know how true that is, but I like it.
Dina, Max, we keep saying MCP.
Can you give us a little bit of a take on MCP and how it fits into this agent conversation?
Sure. So MCP is the Model Context Protocol. It came out in late November.
It's an open source. It's an open protocol developed by Anthropic. But the way to think about it is if you've ever talked to a chat GPT or Cloud and you've asked it to help you with something, it can give you a lot of instructions, but it's still up to you to go and take those instructions and go and implement those.
So let's say I'm asking it, hey, how do I deploy a website for the first time?
It'll give you all the code. It'll tell you what to do, but then you've got to go and do the rest.
MCP allows your AI agents or AI assistant to now start doing things for you by being able to directly interact with the service that you want to use.
So more generally, it's kind of like function calling, but because it's a standard that is now being adopted by all the different players in the industry, it really is going to be the connecting tissue between agents and services and allowing them to actually do things for us and not just tell us how to do them.
I like it. Max, anything you want to add there? Yeah, yeah. I think what really excites me about MCP is previously we were seeing, you know, Cloud and OpenAI, they were letting their agents, you know, do things within the platform.
Like you could generate images and they had a bespoke integration so that, you know, chat GPT could call into Dolly and generate an image.
But MCP allows anyone to build an integration.
So me as a developer, I've got existing APIs that I care about and I want to make those APIs available to agents.
And MCP is kind of like a structured format for unstructured data.
So now I can connect my AI to any API that I have existing or any piece of data that I have existing.
And that's a lot of fun.
So much fun. So much fun. Let me pull in Sid for one last thing and then we'll dig into some of the stuff we've been working on.
Sid, tell me about, you know, durable execution, workflows.
How does this all fit into the conversation? Yeah.
So, you know, as someone who didn't really understand durable execution at all, about a year ago, and has had to sort of speedrun that, I can empathize with the fact that it sounds like a brand new concept.
It's really not. It's just the fact that when you're building agents and you're having things run in the background, or really any task that runs in the background, software is hard to build.
It never runs perfectly. Things break. You know, you want to retry things. Network failures happen, right?
And it's really hard to build all of that every single time you're building a complicated distributed app.
You don't want to have to do all of that boilerplate every time.
Durable execution platforms like Temporal, us, what these do is that they give you primitives that automatically retry and ensure that things, you know, eventually succeed.
They make your jobs run faster in some cases, because we can cache previous results of executions.
And I think, especially with AI, given how expensive a lot of these tool calls can be, durable execution feels more relevant than ever.
I don't know if that made any sense, did it? I thought it made sense, but I don't know.
The room, what questions do we have for Sid?
Now we can just like poke Sid on this. Give me like a good, what's like a workflows application you've seen in the beta?
Oh, and there's my doorbell. Someone's at the front door.
I don't know about that. Good test of Google's isolation.
Sid, give me a good example of like a workflows use case you saw in beta that got you really hyped.
Yeah, absolutely. Just today, in fact, someone tweeted to me about how they had a job they were running, which had to upload several gigabytes of images, you know, every couple of minutes and run some transformations on them.
And before, you know, before workflows, they were doing all of this on a server, things would crash, they'd have to start all the way from, you know, from the beginning of the list.
And it was really painful. It was painful to sort of catch every possible edge case.
And now they run workflows where if a failure happens due to an external API, it auto retries, right?
And it just runs forever in the background.
That's a great use case that I've seen. Another big use case I've seen is, again, running LLMs to sort of transform.
By the way, we just shipped Autorack today.
And I was going to describe that, but let me just say that running LLMs in the background to ingest a lot of files out of, like, let's say an R2 bucket, and then, you know, fine tune a model.
Workflows is perfect for that.
I've seen a lot of people in the world use it for that.
And now we built Autorack that's built on workflows. So again, another great use case.
Yeah, yeah. I love how we build on top of our own stuff, too. It's so fun for me to see internally and you hear the stories and the feedback.
It's awesome.
All right, let's talk about some stuff we launched today. Sunil, tell me what's new with Agents SDK.
And also, I bet some folks are watching who haven't even heard the Agents SDK pitch in general.
So, like, do the whole thing. Do the Sunil, you know, win everybody's hearts by being charming thing.
I should have had a haircut and a trim for that.
I'm way more lovable at that point. Before I talk about Agents, I want to tell you, so folks in the room might know, I worked in Cloudflare from 22 to 23.
So, 21 to 22. And then I left and I built a company called PartyKit for doing multiplayer real -time applications.
And it was built fully on durable objects, which is, if you take a scale of amazing tech and badly named, it is the worst named technology with the most brilliant execution.
The best technology.
I built a whole company on it. So, and when I got acquired last year, my number one request was, oh my God, we need to get durable objects into many people's hands.
It has to be on the free plan. And I thought it would be as simple as flipping on a flag.
But you learn when you're inside a company like Cloudflare, there's billing infrastructure.
You need to put limits on abuse. You need to do a lot of things.
And it has taken one year, but I think like a huge, because durable objects are the world's only implementation of the active model on infrastructure, it's finally on the free plan.
And suddenly, I mean, y'all know developers are cheap as shit, bro.
We don't pay for anything until like it's making like a bunch of money.
So, I think one of the huge announcements today are durable objects on the free plan.
Not just to make it cheaper, but it suddenly means that the number of people who are going to be using it and playing with it suddenly like 10Xs, 100Xs.
Yeah, yeah. Sunil, just like huge plus one, we were talking about this last week.
It's like, I think people who haven't gotten to play with durable objects yet because it's not on the free plan, like this week, your mind's going to be blown getting through it.
I'm so excited for people. Okay, now from that, what is a durable object?
A durable object, I like to describe it like a microcomputer or a micro VM, right?
Like it's a little thing that you can spin up and it stays around.
It's not, you know, like how serverless programming, I like calling it goldfish programming.
Like every time you make a request, it has to like look at a database, put together some context, return you a response, and then it forgets everything again.
And it does this a trillion times a second. A durable object, when it spins up, it actually sticks around.
It's like a tiny little server that you can connect to do web sockets.
The best thing about it is that it can run code even when you're not connected to it.
Like it can wake up on a timer.
Like, hey, every night at 10pm, do so and so. Okay. adding a couple of APIs to a durable object and say, well, I guess this is our agents framework.
And it turns out it works really well. Because you can build stuff like chatbots, which are amazing, by the way, I love chatbots.
100 times more chatbots, people will say that they're not good or stupid.
Add more chatbots, wire it up to your LLM so that he can talk to it.
And, and do like fun things like you can run agents.
So by the way, we just did this math. Matt actually just posted this tweet a while ago, which is on the free plan, you get about 846 hours of durable object usage.
So you get per month, you get 1.1 months worth of free durable object usage.
So if you run an agent running for 24 seven, which doesn't happen, the nice thing about durable objects is that they can hibernate.
It doesn't just keep running so that it burns through your thing.
But if you kept it running for 24 seven, it would still not exhaust free plan, which is like extremely quick to like know.
That's pretty cool. While we're hyping up durable objects, not to derail you Sunil, Sid, you had a fun fact you were going to chime in with on DOs.
Yeah, Sunil was talking about having DOs wake up later and and do some work and then wait.
And I can attest to that because we built workflows and almost entirely on top of durable objects.
Everything that he described, we do, and we do it using DOs.
If you've read my blog post from, I think, a little over six months ago, we described the entire architecture.
And I remember when we were exploring workflows and how we were going to build it.
You know, one thing that was very clear was that we wanted to invest in building Cloudflare on Cloudflare.
And I think it really helped us sort of push the limits, understand DOs better, fix some rough edges as well.
And yeah, to Sunil's point, I mean, durable objects are amazing.
I don't think I understood them really well until we built an entire product on them.
But they're wild. I want Dina to tell us more about what we did with agents today, what we announced, all that MCP stuff.
Because honestly, like Dina just knows this way more than I do. I just think taking credit for some of it.
That's all. No, Sunil is our expert on agents.
But in terms of MCP, so we talked about how MCP enables your AI agents or assistants to be able to do things by interacting with services.
And so within the MCP ecosystem, there's an MCP client and an MCP server.
The MCP client is usually, think of it as the part of the agent that is able to make calls to external services.
And then the MCP server is usually, if you think of a service provider, for example, Cloudflare, that exposes its API endpoints as tools that the MCP client or agent can then call to be able to interact with it.
And so we've been investing in the MCP server side since the launch of MCP and making it really easy to build MCP servers on Cloudflare.
We were actually the first to make it possible to build remote MCP servers, which means that you no longer have to run any of this on your device.
But now it connects over the Internet, which is what I think we all expect in 2025.
And today, one of the really exciting things that we've added to the agents SDK is the ability for you to essentially turn any agent that you're building on Cloudflare into an MCP client.
So now your agent doesn't just respond to things.
It can now interact with external services and be able to make calls to the tools.
Also, because it is a remote MCP client, you want it to be able to go through the authentication flow.
So if I'm connecting to an MCP server that requires a login and consent to be able to use the tools, then it can take a user through that whole flow.
And then a big part of just remote MCP is the transport layer of making sure that you can make those connections, making sure that the standard around server sent events is supported.
And so that's something that we support out the box for both the client and the server side so that you don't really have to spend time setting that up.
We do all of that for you.
There's also a new transport method that's coming out. It's already in the MCP spec.
It's called streamable HTTP. And we are working on adding support for that out the box for both the client and the server side.
But then one of the things that we've done for the MCP server is I brought up authentication and there's also the authorization aspect of it.
But we are going to eventually get to a world where, let's say, I'm just using some AI chatbot and I wanted to connect to my Cloudflare account or I wanted to connect to my Notion account so that I can ask it, hey, how's my website doing?
Help me deploy this worker or help me add some things to my to-do list and cross things off.
And in order to be able to have this smooth interaction as a non-technical user, what I expect is when I ask it to connect to a service, that it will then take me to the login page.
I can log in there. It will then tell me this is exactly what the AI agent will be able to do, which is super, super important because I know we are all very skeptical right now.
And then be able to consent it to be able to do those things so that it can go and start making those requests.
And so to make it easier to add authentication and authorization to MCP servers, we partnered up with auth providers like Stitch, where Max works, to be able to make it easier for developers to set this up, whether it's a brand new service that you now want to expose to MCP or an existing service that might already have its login page API endpoints off that you just want to now connect to the AI agent swap.
But maybe now I can pass it on to Max to talk a bit about the Stitch integration, what all developers should consider when thinking about auth and MCP.
Yeah, absolutely. So the cool thing about MCP is, I mean, there's a lot of new stuff going on, but there's also a lot of really old ideas.
And we've been sharing data between applications on the Internet for a pretty long time now.
And we know how we want to do it already. And we know that OAuth has kind of emerged as the default standard.
And the MCP spec is aligned on OAuth as the method for communication between servers and clients and the method for authorization and authentication.
And that's great, because that means that we can think about MCP clients the exact same way we think about OAuth clients.
And there's already a pretty rich history of how you want to manage consent, how you want to share your data, how you want to revoke access and manage these credentials.
And Stitch is a collection of APIs that helps you add authentication and authorization to your product.
And now we're also a collection of APIs that allows you to turn yourself into an OAuth server.
So I guess, is it demo time? It sounds like demo time.
Yes. Demo time, yes. I've been so stoked to get to demo time.
All right, I'm going to see how this goes. We're sharing the whole screen. So look at that.
You see my login screen right now? Yes. All right, so Stitch has two product verticals.
We've got a vertical for kind of consumer-facing SaaS products.
And then we've got a vertical for B2B SaaS products. And I'll try to run through both of them pretty quickly.
But here, I'm going to log in. And I've got a wonderful to-do app with some great data in it.
And I can go and add to-dos. And if I go and I take my server-side event URL, my MCP URL, and I drop it into the MCP inspector, then this is going to kick off an OAuth flow.
And I can come in and I can grant the MCP inspector access to my account.
And now all of those to-dos appear as resources.
And I've got different actions that the MCP inspector can take on behalf of me.
So I might be able to create a new to-do.
And that'll run and I'll get some output.
And this is exactly the tools that an agent will be able to invoke.
They'll be able to use the MCP protocol and list all of these tools dynamically and figure out what's going on.
And now the server knows that this agent is acting on behalf of me and I've granted it consent.
And if I come over here, I get to see my MCP inspector.
So that's great. That's cool. That's our consumer product.
What I'm really excited about is our B2B product. And so I had to make a B2B to-do app.
And the most B2B concept I could think of was objectives and key results.
So here's our objective and key result to-do app. And very similar as before, I've got a URL that I can plug in.
And let's see. So I'm doing it live.
Let's try resetting some stuff. That's how we know it's a live demo.
And so Stitch has an RBAC product that this ties into.
We're granting this MCP client specific scopes that tie back to specific roles and permissions in our platform.
And what's really interesting about this is it's tied into the logged-in members' permissions.
So I am right now logged in as an administrator. I have access to do everything.
And that means I can grant the server access to do everything.
So if I hit allow, now we get all of these objectives and key results in here.
And we also get a similar set of tools to create new objectives, alter key results, delete key results, and so on.
And now going back over to this member management screen, we see I've got different users in here.
I'm currently logged in as our CEO admin user. But if I log in as someone with a different set of permissions, I'm going to be able to grant a different set of permissions to the MCP server.
And if I go over here, that's exactly what I'm going to try to do.
So now I'm logged in as a manager. Managers have a different set of permissions from CEOs.
In our editor view, they can't create and delete objectives, but they can edit key results.
So they've got permission to do some things, not all the things.
And now when I go in through this OAuth authorization flow, then I see I have permission to grant some of these.
I can grant read access to objectives, and I can grant create, delete, and update access to key results.
But I can't grant the manager objective scope because I don't have that permission myself.
So when I come in and I hit allow, then we get back to the same screen. And now, oh, that's fun.
That's what happens when you run the MCP inspector a couple times in a row.
Yeah. Well, Max, while you're doing this, a lot of people may have never seen the MCP inspector.
Can you give like a quick because this is like this blew my mind. The first time I used it, I was like, where is this?
Can you give like 30 seconds on MCP inspector or two?
Yeah, absolutely. So it's a tool made by the MCP organization on GitHub.
It's an open source tool, and it's essentially dev tools for the MCP server.
And it allows you to invoke all of the tools, view the resources, the prompts, and get like a pretty low level overview and lots of interesting ways to debug the services you're making.
So over at Stitch, we're in the business of helping people make MCP servers.
And I spend a lot of my time in the inspector using it kind of the same way I'd use network tools if I was debugging a regular application.
So good. I don't know about you. Before this, I was just in Cloud trying to trigger my MCP all the time, which was like fine, but a little annoying.
And so if you haven't been using this and you've been doing what I did, it's a huge lifestyle upgrade.
And the inspector is really great for debugging purposes.
But also, if you want to try out a fully remote MCP client that connects to MCP servers, I highly recommend checking out our workers AI playground that we built.
This allows you, you can go there, you can connect to an MCP server, and it has different models that you can use when you chat with it.
And so this gives you a bit more of that experience where you can ask it, where you can integrate it with your Slack MCP server and then ask it, hey, what chats do I have in my channels that are waiting for me?
Can you respond to this? And if you want to take it even a step further and see what will it look like to use Cloud or Cursor or existing MCP clients that don't support remote yet, but to talk to remote MCP servers, we've actually built out a connector package.
It's called MCP Remote that allows you to connect any local MCP client to a remote MCP server.
And so that way you can see that end-to-end experience a bit better and see the power of it.
And it will take you through the authentication flow.
And what it does is it essentially takes the STDIO request and upgrades it to SSE when talking to the remote server.
But hopefully a lot of these local MCP clients natively support remote in the next month or so, which I think will be really exciting.
Yes. Huge plus one.
Sorry, Max, we geeked out. We derailed you by geeking out. You can get back to the demo, but it's just, it's so fun.
The only, this is going to be a fun transition because the one thing I wanted to show you guys was it not working.
Because now, so I'm still logged in as that manager persona with that limited set of permissions.
And if I try to add a new objective, then this should fail. This sometimes happens when I run the MCP inspector in multiple tabs.
It doesn't love that.
So we're going to try one last time. You're just really getting to show off that off flow too.
Oh, yeah. So we see that this member doesn't have the permission to do the thing that we're trying to do.
And because we know who the member is, we understand their identity. We're able to evaluate that even when it's coming through an MCP client.
So that means that we can make MCP clients and servers just as secure as we make, you know, classic REST APIs.
And we get to reuse all of the same tools that we already have.
And that's pretty cool. And Max, you've done something I personally thought impossible is you've demoed OKRs to me in a way that I found interesting and exciting.
So I feel like you get kudos for that. Max, I know you've been deep in the sauce of auth and MCPs.
For somebody building out an MCP server that wants to lock down access to different tools based on roles and permissions, what advice would you give to them?
How would you recommend that they build this out? I feel like you probably have a lot of learnings from everything you built.
Yeah, I think it's still very early days with a lot of things regarding auth that we'll see more stuff coming out.
My number one piece of advice is try to tie into your existing system.
You're already exposing your data in a secure way. The client is just a new type of identity that you're exposing this data to.
And use the same fundamental tools that you've been using and you're going to be OK.
Try not to invent anything new on the data access front.
Where we should be trying to figure some new stuff out is how do we expose clients to how do we let clients discover data?
Dina, I remember you talking about the Google Docs sharing experience before.
I think that's so interesting.
How do we give a client access to a single instance of a doc in a way where that client doesn't know that that document exists before it gets access?
I think that the UI and the UX around that is something that we have to figure out.
But the underlying security primitives of how do we share data, it's exactly the same as a classic REST API.
Amazing.
I'm going to keep, we'll see. Sid, I'm going to keep pulling on the thread of demos and see, do you have something to show us?
Am I making that up or do you have a demo for us?
I do, actually. So, remember when I was talking about transforming images in workflows?
It turns out we have a demo of just that. It's actually looking at the LLM program, by the way, before anyone was talking.
This is all super cool.
It's so good. It is so good. I didn't know you could do this stuff.
This is incredible. Thank you, Max and Dina for that. So, we have a small little demo, really.
And what we're trying to show off is the fact that workflows, as of today, can now support human-in-the -loop tasks.
We can wait for events. We have a new API called WaitForEvent.
And we can wait for an arbitrary event that the user can define.
This demo is going to use that to show off how we can use a workflow to transform images.
I think it uses an AI to tag it. So, let's go ahead and upload an image.
I'm going to upload this image of some stairs. I had this whole architecture and design phase in between.
I was looking at a lot of stairs, clearly. I was going to ask, Sid, are you a huge stairs fan?
Can you review these stairs real quick before we do the AI thing?
Absolutely gorgeous stairs. I love those stairs.
I mean, if I had to build stairs in your apartment, I would build them like that.
And if you notice here, this, I haven't hit yes on.
So, it's sort of, you know, cute, so to speak.
It says running because the workflow has started, but the workflow itself is waiting for this end user event.
And the event in this case is me proving whether we want to generate tags or not.
I'm going to hit yes here. We'll see what happens.
It's sending an event. The event is sent, as you can see. And there you go. I found a staircase with some wood, some steps, stairs, and thread.
That seems quite accurate.
But what's happening behind the scenes, really, is that you'll notice that this is our cool.
Sid, can you make it bigger? Absolutely. There you go. How's that?
Yeah, looks great. Yeah, that looks good. And if you notice here, the first thing it does is that it stores the name of the image into a D1 database.
But after that, it sort of just waits for a human to come in and approve the workflow.
If we didn't approve that workflow within five minutes, it would just time out, right?
So, you can set a configurable timeout. This could have been 10 years. Sorry, I'm not sure what happened there.
It turns out you can't just edit unless you fork.
But you could change that timeout to 10 years or infinity, really. It doesn't even have to have one.
And in this case, we don't exactly show off the fact that an event that it's waiting for can have a payload.
We can have an arbitrary payload that your agent can send back and forth, an agent or a user.
And, yeah, that's the new wait for event API.
Check out the blog post on how to use it more.
One thing I want to also quickly mention is that you're likely to write workers and DOs and other workflows that sort of send events to each other.
So, you might be wondering, okay, cool, I can wait for an event, but how do I send the event?
And while you can use a REST API, an HTTP API, we also added a new function to our binding.
And it looks a little like, I believe it's somewhere down here. Or maybe not.
Maybe it's somewhere else in this repo. Let me look for that right now really quickly.
I'm going to search for send event.
Aha, we did not find it.
That's all right. Well, the API looks a little like, I'm going to show you the example from the blog post.
There you go.
And if you want to send an event to a specific instance from your worker or your DO, you can simply go ahead and run a function that looks like this, where you can await sending an event to a specific instance.
Make it bigger again, Sid, but I like this.
Absolutely. Good call. There you go. How's that? It looks perfect.
So, this is how you would send events from your other DOs or your agents or your workers or even your other workflows.
And now you can have multiple workflow instances running that are sort of waiting on either humans or agents or other sort of events that could occur in external systems.
And this brings a whole new sort of level of control flow that you can now do.
Yeah. So, you can build a workflow, you can have as many steps that are happening as you want, and then at any point, you can say, hey, wait on this next step until a human does something.
And the thing I like the most about a lot of these APIs, and so much of this has been opinions for so many people, including Sunil.
I think he's had some really solid opinions on this stuff, is that if you look at any of our APIs here, like WaitForEvent, I'm going to have to bump this down to score for a second.
Give me a minute.
If you look at our WaitForEvent API, much like our Step2 APIs and everything else, they all just return promises, which means that you can do anything you can do with promises with them.
You could wait for an event and race that with a sleep.
You could wait for two different events from two different systems and do a promise or race between them.
And if one event comes in before the other, that promise will resolve.
We've tried not to reinvent the wheel there. You could have events that could have any type you'd like.
You could set up the type based on your use case.
In this case, we're waiting for an incoming Stripe webhook, so the type is Stripe webhook.
And that's a type that the user can define, and it needs to be unique across their account.
And, yeah, that's the new WaitForEvent API.
I am so excited about this one specifically. And in the true spirit of what it's like at Cloudflare leading up to Developer Week, Sid knows this.
We were talking about the launch last week, and then you were like, oh, and we have this WaitForEvent thing, too.
I'm like, wait, what? And so, you know, I feel like we get surprised and excited by new stuff that we've been wanting to.
Things move quickly.
I love that about Cloudflare. Yeah, me too. Sunil, I feel like, do you feel left out?
Do you have anything you want to demo? No, I'm actually just chilling watching all of this.
I was just thinking about a couple of cool things that have happened, especially the auth demo.
I was thinking that Cloudflare doesn't own the auth layer, which is very cool.
That you can build an application, an agent or anything else, but agents are the interesting ones.
And have a service behind the server that has an authentication layer.
And have a client from outside, literally a browser, just go through, pick that up, come back through.
And Cloudflare doesn't own this. Anthropic doesn't own this. It's not like we showed a Cloudflare bandit page there.
It was the Stitch page. I thought that was particularly special.
It's moved so quickly.
I think the first version of MCP happened in Q4 last year. And then it just took off early this year with Cursor going so big.
And it's kind of now mainstream.
Well, it's mainstream with nerds like us. I suspect everyone else is going to be using MCP on the backend for a lot of stuff.
I think that's particularly cool.
The other thing, and I don't know, Dina, if you mentioned this, but we're not yet in a place where we have stateless MCPs.
It's still kind of stateful stuff. What that means is that when a client connects to an MCP server, it establishes a connection and it stays alive.
So now if you do this on normal infrastructure, you would basically spin up a VM and it would stay alive forever.
And that gets expensive.
But durable objects hibernate. The nice thing about our MCP agent, which is built on the agent's SDK, and it can be an MCP server, is that it makes the connection.
And because, actually, shout out to Jeremy, who implemented this. It can make the connection, but the durable object can actually go to sleep while there's nothing happening on the wire, like while no commands are being set.
Did we announce this in the blog post?
Well, if you haven't, you should check it out. Sorry, am I just repeating things you already said?
I thought I was paying attention.
But I thought that's a particularly interesting application of our technology.
Thanks to Kenton for inventing durable objects and letting us play with it, I guess.
I was just thinking that that's quite unique, that it's let us move so quickly here.
Yeah, it's amazing. So we have our remote MCP servers. I don't know if you guys are hearing this, but I'm hearing an echo.
Cool. And the remote MCP servers that you build on Cloudflare, you can build them using the MCP agent class, which is an extension of the agent's SDK.
And out of the box, it allows you to build a stateful MCP server.
And that can have a lot of benefits where you can keep track of the conversation history and be able to just have a more personalized experience for users by keeping track of their preferences, what they like to do.
And now, especially with hibernation, you can have it maintain these long lift sessions.
But when it's not in use, it can go to sleep.
And then as soon as somebody needs it, it can wake up and it will maintain the state so that it can continue using it.
And you no longer have to pay for all of the time that it's idle. And especially with today's announcements of durable objects being available in the free plan, this just opens up so many doors to developers that want to start building this right away.
You don't even have to add a credit card. You can just start building.
Can I just jump in and say how much I love the fact that we only build for CPU time?
I think that's honestly, I mean, the first time I learned about that, I was like, what?
We've only been for three milliseconds across however long this could have taken.
That's insane. That is so cool. Yeah, it's amazing. And I have my personal Cloudflare account and I do the paid $5 plan.
And I just am amazed how I never have to worry about it, even when something gets a little bit of traction.
So a huge plus one.
And Sunil, you touched on this. Well, I'm distracted of like, what do you call something that's mainstream with us nerds?
I'm like, is it nerd stream?
Like, what is it? But MCP has gone like, you know, nerd mainstream a little bit over the past weeks.
Dina, Max, do you have any thoughts? I remember when the Sam Altman tweet came out of like, you know, they're going to support MCP.
And everybody's like, what?
How are you all thinking about this? I'm very excited. I was every service had an MCP server, even something that you wouldn't expect.
I was talking to my friends who are not in the tech industry.
And they were like, man, I wish I could use this to figure out like outfits for the next week.
And imagine it integrates with a service like different online stores or Rent the Runway or whatever have you.
And there's just so many creative ways that you can use it. But I think especially with opening eye, adopting it, and then we already have remote MCP servers from Sentry and PayPal.
And if you use the PayPal example, you can see how you can generate an invoice by just asking for it.
And so I'd love for the day when all of these exist as remote MCP servers.
And I can show it to somebody like my mom and be like, what do you want to use?
Go talk to it. It will get it done immediately.
It strikes me that if you want to be successful in the AI space, you need to have really dog shit names for the things you invent.
Viewable objects, MCP, Autorack.
Autorack, again, amazing, but like weird name. I think that's the move. I had to go to my mom and ask her about MCP servers and she'd be like, what are you talking about, bro?
What's going on? I made a video on MCP in like the early days and I had to reshoot it like 20 times because I'd finish it.
And then I said MPC like three times because I think of like NPC and yeah.
Though, Sunil, new show idea for us.
We're just going to have you roast product names for like an hour a month. You know, just like have you go in on that.
If it makes you feel any better, I'm pretty sure I heard someone called chat GPT, chat GTP earlier today.
Well, I was going to say it makes me feel better until I'm like, was it me?
Because then it made me feel worse.
My favorite thing is you can ask any of the AI assistants what MCP is and none of them are going to get it right, including Claude, which sometimes I'm like you invented.
This comes from your parent company.
What do you mean you don't know what it is? So I think the day will be truly mainstream is when I can ask any of them what is MCP and they'll know from the start.
Yeah, so true. All right. We got a question from X for Max, actually. So, Max, what is the current standard for exposing the scopes that Stitch endorses to make the stuff explorable and discoverable?
Also, is there a way to get info about the tools of the Cloudflare Remote MCP through a discoverable file?
So I guess that first one for you, Max.
Second, maybe for Dina. Yeah, so that's a really great question because the way scopes are handled by the MCP protocol is actually not fully defined yet.
They just don't have anything in the spec about how to think about scopes or requesting scopes.
I actually have a pull request out on the spec right now just to say, hey, let's request all of the scopes that we can and let the user, you know, confirm or deny what scopes they want to share.
But it's still very early days in figuring out both how the agent should request certain types of authorization and how the agent should even discover that that authorization exists.
The spec is built on top of existing OAuth specs. And the one that's most interesting for this particular use case is the OAuth authorization server config.
And that OAuth authorization server config payload contains a bunch of information about the server, you know, what the issuer is, where all the URLs are.
And it also contains a list of scopes that the server supports.
So I think that's probably what we're going to end up using in the short term for figuring out permission.
Just server says, here are the scopes, please request them.
And then the user says, oh, I want this scope, this scope, and this scope.
But we'll see. Awesome. And Dina, you want to take the second part of that one around understanding the tools through a discoverable file?
Understanding the tools through a discoverable file.
So today, as an MCP server, you can expose all the tools, or actually you can even dynamically choose to expose different tools based on the scopes that are allowed.
I think to add to what Max was saying, one interesting improvement I think will be that even if from the start you grant your agent read access, for example.
If you do have the ability to give it greater access, you should be able, there should be a flow where, for example, I ask, hey, can you send a message?
It says, hey, I don't have permission to do this.
But you can upgrade my permission so that I do have the access to do that and making it smooth so that they don't have to go through the whole thing from the start.
But it's very clear what they are consenting to. Awesome. All right.
We've got 10 minutes. I'm going to close this out with a free-for-all of just agents, MCP workflows.
We've had some of this stuff floating around for a while, done a lot of launches.
What's the coolest stuff you've seen getting built with all of this over the past handful of weeks or months?
My favorite agent so far is that dude, I forget his name on Twitter.
He has a scary avatar like a lot of these people do.
He left an agent running overnight to delve into the intersection of math, computing, AI, and some crypto shit.
And it came up with this huge post-futurism view of the world of what it'll look like.
And that was basically one agent conversation running overnight.
That video is a weird one. We should probably share it.
I think that was one of my favorite ones. The other one I like is someone made a sous-chef agent by themselves saying, hey, I have these ingredients, what should I do with it?
And basically a cooking helper. And that's awesome. And it looks really pretty.
He did a really good job of it. A lot more stuff is happening in the Cloudflare Discord in the agents channel.
You all should go check it out. I would love the chef one because I was at a hackathon like 12 years ago and it was a food hackathon.
And someone kind of as a joke built this application where it's like, oh, you take a picture of your refrigerator.
And then the app tells you what ingredients you have and it tells you what you can make.
And everyone thought it was very funny and they went to Costco or whatever and bought a mini fridge to demo it.
But it did not work. It was science fiction and kind of like a little bit of a gag.
And now that we live in a world where that application, is it just possible? It's like basically possible for anyone to build that application.
And it blows my mind.
So, yeah, I love those examples, too, that just seemed like science fiction a bit ago.
I'd love to see something like that integrate with like Instacart or Amazon Fresh, MCP server, where you're like, oh, that's a cool recipe.
Go order those ingredients for me, have them show up at your door.
Next step is having a robot that can actually cook for you.
But till then, got to do that step. Yeah, agreed.
Dina, Max, what's cool MCP stuff you've seen? What's some of your favorites people built there?
I'm, linear algebra was never my strong suit. So anything where it's like games programming or graphics programming always blows my mind.
And there's so many crazy cursor vibe coding demos on Twitter right now.
And I look at those and I'm like, oh, my God, I, you know, not never in my life could I consider, you know, making a game until like the last month.
And now everyone's doing it.
And it just looks like a ton of fun. There's a blender MCP server example where you can directly from cursor, you can tell it, hey, this is what I want to draw out.
These insane 3D models for you. Which is so cool, because if you've ever tried to figure out how to work one of those programs, it probably takes weeks of just learning to get started.
Yeah, I have a 3D printer in my basement. I feel like all nerds like at some point got a 3D printer like that was like, yeah, Sid, I know you've got one.
And then it's like, you realize you can't actually do like anything with it.
That's not just like downloading the model that already exists. And I, the blender one, Dina, I was also excited about because I'm like, maybe I can use my 3D printer for something again.
Or even the Sigma one. I'm very excited, especially as a PM.
I have all these diagrams and sometimes I don't want to bother our design team because I know it's just like patience.
And we have all of the elements being able to draw like a simple thing on paper, taking a picture, sending it to it and being like, hey, draw a Cloudflare style diagram of this.
That would be amazing.
We'll save so much time. Love it. Sid, I saw you about to unmute. Oh, I was I was gonna I wanted to shout out Brandon, who previously co-founded Outerbase, who we, you know, we just acquired them.
So this can be fun. But Brandon actually built an entire UI on top of workflows several months ago.
And I want to show that off because this was really cool.
And now that he's joined the company, I think there's there's lots of interesting things we can do here.
But his tweet from several months ago was about.
Oh, I'm sorry. His tweet from several months ago was all about building this brand new UI on top of Cloudflare workflows.
And it's really exciting to see this come up as a primitive where people are building tooling on top of it.
Yeah. We can't see your screen, by the way. I can see it.
Can you? Oh, then I can't see it. OK, sorry. Never mind. Yeah, I love that one, Sid.
And yeah, I feel like we had so much news today, we didn't even get to all of it.
But yeah, the Outerbase joining Cloudflare, super exciting.
And one of those companies that I feel like there's so much cool stuff they built that we were all like, just like, no, this is cool.
This is cool. And so whenever those people become part of the family, it's just so awesome.
All right.
Before we wrap, where can people find you all? Y'all are building cool stuff.
How can they follow along? Max, I'll let you share your details first. Oh, I don't have personal details yet.
There's the Stitch Twitter account, and then I'll sometimes post on LinkedIn.
And then there's the Stitch LinkedIn account. But I guess I got to make my own now.
No, you're like the Banksy of MCP. Like, you know, no one can find you.
You're like behind the Stitch stuff. I love it. Dina, what about you?
I'm on Twitter, dinasaur underscore 404. Or you can also find on Discord. We now have an MCP channel.
We also have an email hotline, 1-800-mcp-Cloudflare.com. So email us.
Whether you're getting started or you've already started setting things up and you're running into issues, please send us an email.
We will help you out.
We had a few remote MCP servers that we were able to get to production this weekend through the hotline.
And otherwise, the Cloudflare Dev Twitter channel.
And, yeah, I'll pass it to the rest. Yeah, well, and Sid, the question, can we fax requests for MCPs?
So, you know, maybe the next weekend project for one of us is the MCP fax line.
Sid, where can people find you? I'm on Twitter. I'm at chat, Sidhartha on Twitter.
I put in the chat because it's a little tricky to spell, isn't it?
You will see me on Discord from time to time. We have the Cloudflare community workflow section.
So if you have anything interesting or a question, you know, ask us there as well.
And, yeah, also the Cloudflare Dev handle on Twitter.
I mean, I think that's a great way to get to any of us. So, yeah. Awesome.
Sunil. You can find me as East Dakota on Twitter. I cosplay a billionaire in Utah.
And I occasionally go skiing and talk about my ravine. So it's East Dakota. Thank you, Sunil.
That's very good. We will keep an eye out for your latest tweets.
All right. Let me wrap this up. First, thank you all. You all are amazing. It's a privilege to get to chat with you.
Come hang out with all of us. Everybody called out the Cloudflare Dev handle on Twitter.
Definitely reach out to us there. Discord.Cloudflare.com to join on the Discord.
Community.Cloudflare.com. We've got meetups in London, in Austin, in San Francisco this week for Developer Week.
A bunch of us on this call actually will be in London, I think, for the one on Thursday.
So if you want to see me and Sunil and Sid and Dina, are you going to be there?
I will not. On my behalf. Okay. Well, we will pass any messages to Dina. And Max will have to get you out to the next one, too.
So, yeah. Please come hang out with us.
Otherwise, we're going to do these throughout the week. So the next one will be tomorrow with Craig Dennis as the host.
So have fun and can't wait for you all to see what else we launch.