Agent ready episode 3 with Cloudflare: deploying remote MCP at the edge

The third episode in the agent-ready video series is now available! Featuring Lizzy Siegle from Cloudflare and Reed McGinley-Stempel from Stytch, this episode looks at deploying MCP servers at the edge and walks through a complete real-world agentic workflow.

Video overview

Agents need to do more than just chat. This video shows how to supercharge LLMs with real tools, built into remote Model Context Protocol (MCP) servers deployed at the edge. We’ll walk through a real-world example: a tennis court booking agent that impersonates a user, logs in, scrapes the local Parks&Rec website and completes a multi-step booking flow—check_tennis_courts, book_and_request_sms, enter_sms_code_and_complete. Along the way, you’ll learn how Cloudflare’s hosted MCP server and browser automation tools and Stytch-powered authentication make it secure and reliable. You’ll also take away practical guidance on how to design agent tools that are robust, composable, and production-ready:

You'll come away with an understanding of:

• How to structure tools with schemas (Zod!) to enforce validation and clarity
• Why avoiding ‘tool soup’ matters and how to keep tools simple and deterministic
• Treating tools like real APIs: clean inputs, predictable outputs, and clear behavior

The session includes a live demo and hands-on deployment, so you’ll leave with everything you need to build and deploy your own agent-ready MCP server from scratch.

Full transcript

Reed: Hi there. I'm Reed, co-founder and CEO at Stytch. And welcome back to the Agent Ready video series. Today we have a very special guest. We have Lizzie Siegle, a developer relations lead at CloudFlare, and we'll be going really deep into MCP servers, in particular, how to build a remote MCP server.

Reed: MCP of course, being the model context protocol, which has been really critical to a lot of the rise and attraction that we've seen in AI agents over the last few months. And so I'm really excited to have you and chat more through that, Lizzie.

Lizzie: Thanks, Reed. Excited to chat MCP with you.

Reed: Awesome.

Reed: Well maybe the first thing we'll start out with is just basic level. Obviously folks have probably heard the term MCP, but what is MCP? What is an MCP server and why does that matter relative to AI agents?

Lizzie: Great question, and I've watched so many YouTube videos to better understand this, and I know a lot of developers have as well.

Lizzie: MCP is a standard that lets agents have access to tools. It's exciting because these tools are programmable, they're portable. You build the tool once and then it can work across different LLM providers, MCP clients, hosts like Claude, Desktop, Cursor, or Windsurf. So you build once and then you're not locked in. You don't have vendor lock-in.

Reed: Awesome. Well, and one of the things I've found is, to your point, I feel like people have found so many different analogies to try to explain MCP, whether it's USBC or something else that tries to just make it concrete for folks. And I think probably, you coming from the dev rel background, but also for myself, as I've learned about it over the last few months as well.

Reed: Nothing really replaces seeing a demo, going through the internals of what's possible with this, what it takes for a developer to build this, and then what is that end state. And so maybe talk with the audience a little bit about what we're gonna be walking through today in order to exemplify and show what MCP servers do at work.

Lizzie: Yes. So I have a demo ready that will help me book a tennis court in San Francisco. I like this because one, it uses Stytch. Not anyone can book this court. Only I can book it for me and it will log in for me. It will act as me and it will take action for me using CloudFlare MCP, CloudFlare browser rendering to scrape the webpage and log in via our puppeteer fork.

Lizzie: And of course, Stytch to be like, who are you? So if you're not me, use your own MCP server.

Reed: That's great. Going from just an AI that might crawl information on the web for you to something that's actually taking actions on your behalf, I think that's one of the things that gets folks really excited about agents and obviously MCP in this use case.

Reed: So, super excited to dive deeper and maybe we can get started and just walk folks through a demo and understand what's happening under the hood afterwards.

Lizzie: Let's do it. I'm gonna open up Claude Desktop, which is my MCP host of choice, and we're going to ask “check tennis court times at Alice Marble for Thursday”.

Lizzie: This will convert. This is gonna take some time. It will parse out Thursday and it should know what day it is. So it can check, click the time clicker, the date clicker, and it's gonna scrape and select Alice Marble. It could have worked for, I've tried Dolores, but Dolores is pretty popular in San Francisco, so there's not many open court times.

Reed: Mm-hmm.

Lizzie: But it can work for DuPont, Alta Plaza, Lafayette, any public San Francisco tennis courts that are bookable on the correct US platform. They used to be spotty, but I think it changed a few months ago. So that scraping would have to change.

Lizzie: Okay. So it says, Alice Marble Tennis Court has availability on Thursday, August 7th at 12, 1:30, or 3 o'clock, and we can check that in the browser.

Lizzie: 12, 1:30, 3. Ninety-minute sessions. What time should we book?

Reed: Let's see. Maybe make it a lunchtime, noon reservation.

Lizzie: Book noon please. And it should parse out noon and pass that text to the LLM and it knows that noon means 12:00 PM.

Reed: And presumably, I noticed when you showed up to the office today, you had tennis rackets in your bag. So presumably you play tennis a lot. This is something that you would've otherwise had to go to the user interface every single time. There's a ton of convenience that you're getting just from this ability. Everywhere that you're starting to centralize other work, like Claude or ChatGPT, whatever it is, you're able to bypass those steps that you otherwise wouldn't be taking.

Lizzie: Yes. So I could do this in Cursor, Windsurf, Claude, ChatGPT now, and you can automate this process as well programmatically. And now it's asking for authentication. Thank you, Stytch. Gonna click that. I think I'm already authenticated 'cause I tested this earlier. Yes. Choosing my personal Gmail.

Reed: Wow. Look at that. Authentication. So smooth, so seamless.

Lizzie: Very smooth and seamless. And I say authenticated. And then here is, I would like this to be automated. I used to work at Twilio. And it's gonna text me a code and I do not have a Twilio phone number anymore that can respond to text messages.

Lizzie: So that is a work in progress. Okay, so I'm gonna get this text message, my personal phone number, and then I'll paste it in. This triggered the booking request SMS tool. So now that it's authenticated, it can finish booking for me. It will request SMS of any human.

Lizzie: If I were to go into the browser and try to book it by hand, I would still get a text message.

Reed: And so this is for the SF Parks and Rec. They typically log you in with email and then make you do an SMS as well to make sure you're a human, right?

Lizzie: Yeah. Sometimes that times out.

Lizzie: Looks like there was a timeout, but it will try again and it checks the authentication status. I like Claude as an MCP host for this reason. Some of these use the Claude LLM playground, but it's not as smart.

Reed: Yep. And it gives us a moment to think about, if I were the Parks and Rec website and I wanted to make this… think about what you're doing today where you're putting engineering resources within the city of SF into building and maintaining this website. A lot of consumers are starting to vote with their feet that they'd probably prefer to use something like Claude, Cursor, or ChatGPT.

Reed: The ability to start exposing your application so Lizzie here can authenticate, show that it is a real citizen of SF, but maybe making it easier for them. Maybe not always requiring them to do the SMS verification, because there are other ways to verify without making you jump through those hoops.

Reed: Really promising, ideally, in the way that no longer does the city of SF need to think about building out and maintaining this really robust website. You can start thinking about a lot of the work being done for you by the LLM interfaces, and you just have to expose the right routes and tools to them.

Lizzie: Yes, and I wish they actually emailed, because I could use Google Gmail. They have an API to check your inbox and then get that email. I'm gonna try that again.

Reed: And we're at the vanguard, the cutting edge of MCP, which is why of course live demos don't always work exactly the right way.

Lizzie: But glad it's live. I feel like I've seen a few videos where you're kind of hiding something.

Reed: Yeah. This is good for folks to understand that as they're starting to play around and build these things themselves, you're going to find, because of the probabilistic systems or different things you haven't thought about, and latency elements like that, there's gonna be some iteration you have to find in order to get it deterministically acting the way you want.

Lizzie: And web scraping was hard for this because some buttons might not load in time. There are quite a few timeouts, so a lot of retries.

Reed: And for the web scraping, you're just using Puppeteer for that?

Lizzie: Yes. CloudFlare has a Puppeteer fork called browser rendering.

Reed: Okay.

Lizzie: Using click buttons, fill in text inputs, text boxes.

Reed: Oh, excellent. Look at that.

Lizzie: And I just got sent this code. I'm gonna type it in.

Lizzie: If the VPN came on, I would cry, because the VPN would restart the process. Typed in the code, and now it triggers the enter SMS code and complete tool that takes in that code and inputs it in the text box. Booking confirmed Thursday for 12:00 PM under my personal email.

Lizzie: And now if we were to check—I’m not gonna check my email—but I should get an email and it says reservations. Oh, can you block out my address? This always happens.

Reed: Post production.

Lizzie: But I have a court booked for Thursday at noon and a lot of canceled courts because I keep booking and unbooking.

Reed: Oh wow. Okay. Great. Awesome. And out of curiosity, to put ourselves back in your shoes—when you're starting to think, here's a task that I do all the time, I would love to make this easier on myself—what was your process pre-MCP server? Obviously MCP servers have their own rough edges that you're building on top of, but what would you previously have done? Would you have gone to the site? Does this change how you think about scheduling, like having it recurringly look for things in the future? What conveniences do you imagine you'll get from this in the future?

Lizzie: I was gonna build this in a CloudFlare worker.

Reed: Mm-hmm.

Lizzie: And just set a CR job. You can still do that with the CloudFlare MCP as well, but with MCP servers, it made me break it down into tools. It was like, what were the steps?

Reed: Yep.

Lizzie: And then you think about the steps you take as a person and also the steps that the computer can take.

Reed: Okay, great.

Lizzie: So it's very composable and it's neat to think that those tools are reproducible across many different MCP hosts and clients now.

Reed: Yep. And now that folks have seen this remote MCP server use case in action, there's a concrete example. Talk a little more about what went into that building process with CloudFlare. What were the different tools that you used in order to create this under the hood? Maybe talk through some of those in a bit more detail with the audience.

Lizzie: Yeah. Great, let's dig into some code. First off, I initially started in the CloudFlare docs here where I clicked to deploy, and that gave me a GitHub repo that I could clone.

Reed: Mm-hmm.

Lizzie: And then it gave me some tools to start with, like an addition or some math tool. Then I added my own tools. This was off list to not have authentication, and then I added auth later. Not saying auth was an afterthought, but click to deploy is very fun, very easy.

Lizzie: And as was Stytch—adding that once I realized I don't want other people booking for me.

Reed: Mm-hmm.

Lizzie: Scrolling in the docs, here's how you would add authentication. My MCP server has a Ringo.JSONC file. If you know CloudFlare workers, this is where you add bindings, and bindings are connections to other CloudFlare products.

Lizzie: Many of these were already included when I cloned the repo that was generated for me. But I did add the AI binding so I could use Workers AI—open source models hosted on CloudFlare Workers. I can run inference with a few lines of code. I could pass the scraped website data to an LLM and return a message that's more humanlike sounding.

Lizzie: And then here's the browser binding, so I can use the browser rendering to interact with interactive web pages, log in, and take steps for me. KV Namespace is a key-value store so I can save key-value data.

Reed: Mm-hmm.

Lizzie: And Index.ts is the heart of the CloudFlare MCP server. I'm gonna go initialize tool—where we, you guessed it, initialize our tools. In computer science, some things are hard, such as naming things, but not this one.

Reed: Mm-hmm.

Lizzie: Tool one: check tennis court availability. This tool does not have authentication because anyone can check what courts are available. Takes in date, court, maybe time—these are optional.

Reed: Mm-hmm.

Lizzie: Then it checks the browser, goes to the website, navigates to the specific court. If someone said Alice Marble, Dolores, it handles the date. There's a function that gets the current day, loads selectors, waits for available times to load, makes an availability object that has the court, date, available times, requested time, total slots. Then it passes that to a CloudFlare Workers AI call to return natural language.

Lizzie: System message is like: you're a helpful tennis court booking assistant. Convert this availability data to a friendly conversational response.

Reed: Hmm.

Lizzie: And I used Llama 3.1. There are other models to use.

Reed: And that's through the AI binding?

Lizzie: Yes. And then book and request SMS—this one needed to be authenticated because not just anyone can book and request SMS on my account.

Reed: Mm-hmm.

Lizzie: We have my login information as secrets, and then we connect, log in, and fill a lot of the text boxes. Looking for the Stytch part, we have our auth endpoint that connects to the front end. For that tool, it returns a CloudFlare Pages URL.

Reed: Mm-hmm.

Lizzie: And that's where you authenticate with Google Auth via Stytch.

Reed: Mm-hmm.

Lizzie: And then it confirms or denies that you are authenticated.

Reed: And for the SMS requirement on the site, is your guess that that's intended to prevent bots booking up the courts?

Lizzie: I think it is. That is a problem.

Reed: It's an interesting point. Websites and apps need to think about this balance as they're becoming agent-ready. There's a reasonable motive for why SF Parks and Rec may not want bots historically to submit claims for courts. Imagine somebody could write a very simple Puppeteer script, they could book every single time, and then only show up to the ones they wanted. My guess is they don't charge you when you book, is that correct?

Lizzie: They don't, but they are going to start charging for some courts. Mainly because Parks and Rec is in debt, I think.

Reed: Okay.

Lizzie: I think also because people just book and then don't come.

Reed: Yep.

Lizzie: But in San Francisco, I think quite a few engineers I know have automated this process.

Reed: Yep. That's interesting, and it makes sense. The motive is similar to when Nike drops a new sneaker—there are sneaker bots that try to buy all the limited editions and then resell them. You might have people that try to resell courts if they all got booked, or people just not showing up after booking every slot.

Reed: So it makes sense why historically they'd start with SMS, something that proves a human is in the loop with phone number verification. What's interesting is that you mentioned they might start charging for courts. This is clearly still a human on the other side of the interaction. Yes, it's an AI agent taking action, but there is a human in the loop—it's just a different interface, a conversational interface making your life easier.

Reed: Still, SF Parks and Rec likely wants a human with agency behind the AI agent. The reason I mention that is there are going to be different motives and incentives apps need to think through. I'd say it's a little clunky for them to still require SMS in that context, where you get the SMS and have to input it. Obviously this was a great demo to show they don't support remote MCP servers and how to build it. But it would be nice if instead they did something like send an email verification you could click. Or if they start asking you to pay for the court, put down a $5 deposit that you get back if you show up.

Reed: Those are different ways to incentivize good AI agents, or agents with a human behind them. Then you can add bot protection, bot mitigation, etc., to stop malicious cases. I mostly wanted to flag that—it was interesting to me because I had not been through the Parks and Rec flow myself, but it makes sense why they've landed there.

Lizzie: Yeah, that makes sense. And so we check for authorized emails: is the email that you log in with one of my authorized emails? Here is an authenticate function in the front end. We have the front end and then the server.

Lizzie: At this front end, this function is the authentication callback page that handles completing the login and flow after OAuth. Then we authenticate—the token should last 60 minutes, set some items locally, and notify the MCP server about that new session with the user ID and their email. If they were verified, send that session token and Google token to the MCP server.

Lizzie: And then the other tools are pretty similar. I think it helps when you go through the flow yourself, because then I knew what buttons to click, what selectors to expect. I could say: click this, do this.

Reed: And that became your guidance for which tools to outline. Yeah. Okay. Cool. Awesome. So now we have a good sense of both the code that went into the remote MCP server itself, how you built out the different tools that you wanted to expose the AI agent.

Reed: Where do you think is the most natural next element that folks start to unfurl in their mind when they go deeper into building remote MCP servers?

Lizzie: I think a lot of people have been saying MCP servers are not that big. Why are people so excited? It's just a wrapper for an API. And a lot of MCP servers are wrappers for APIs.

Lizzie: But it's exciting that it's a way to give LLMs tools and they can take action for you like this. They can pretend to be you. In the past, pre-MCP, you would have to program or set up that connection between Windsurf and a tool, Claude and that tool. And I think now LLMs are going to get a lot smarter because of it. It's a great time to be a builder—there’s so much to build and it's really fun.

Reed: That's great. Awesome. I'd love to hear more about the experience of building this. What are some of the tips and lessons you’d share with developers to help make this more streamlined, improve their ability to build remote MCP servers? Maybe some interesting takes you had—how would you advise developers going down this path?

Lizzie: Using schema is very important. This MCP server uses Zod as a TypeScript library for validating schemas. Your inputs should be set and your outputs should be predictable. That makes it more programmable—if you can expect the output, you can predict or program what to do with it. You can use LLMs to format that, but I think Zod is a great library for it.

Lizzie: And it's not just for validating schemas, but also for clarity. That will give you better LLM output.

Reed: Could you expand on the clarity piece?

Lizzie: Yes. With schemas, it's like making the output more digestible for LLMs. I saw a tweet—I don’t want to say a study—but that LLM output is better with schemas.

Reed: Our modern version of studies, right? Peer-reviewed tweets.

Lizzie: Yeah. You should avoid tool soup—don’t overload a tool function. Keep it fairly composable, one tool per responsibility.

Reed: Okay. What would be an example of tool soup? If you had applied tool soup to the example we walked through?

Lizzie: Having it all be just one tool maybe.

Reed: Okay. Yeah.

Lizzie: Like don’t mix read and write, or logic and UI.

Reed: So if you had made the tool “book a court,” then that would have to include looking at the times it's available, actually clicking through, and choosing which time.

Lizzie: Yeah. Like Claude does check. When I say book a court, even if I know what time it is and that it's available, Claude will still run the check courts function.

Reed: Okay.

Lizzie: So Claude is smart enough, but that is a separate tool.

Reed: Okay, great.

Lizzie: Do not blindly use tools. There's something called tool poisoning now, where malicious users can put instructions into the tool description like “hack this person” or “leak their SSH key or API keys.”

Reed: And if I’m trying to follow that guidance of don’t blindly use tools, what should I be looking for when deciding whether to use a tool?

Lizzie: Probably where it's coming from.

Reed: Okay.

Lizzie: Who built it, and how many people are using it. If it's reputable.

Reed: Okay.

Lizzie: Design tools like you would design endpoints. Validate inputs, predict outputs, and document edge cases. For example, this MCP server—the tennis booking one—some tools might not work if the website is down. That is something to consider.

Reed: And when you write that down, is that so it handles the error and returns it back to the user better? Or is there another purpose?

Lizzie: It tells the user. It’s a better user experience.

Reed: Okay. Great. And how should people think about descriptions on tools?

Lizzie: Good question. You’re not trying to sell this tool—don’t make it flowy or salesy. Don’t oversell it, because this is how the LLM knows what to expect and when to run it.

Reed: So like—

Lizzie: Keep it simple, understandable to the LLM, and be honest. Don’t oversell so that the LLM doesn’t oversell it or misuse it. You want the LLM to know what to call, so you just have to be blunt, upfront, and clear about what it can do.

Reed: That's really interesting. I’d never heard anyone make that recommendation. And I think it’s a helpful one to highlight, because effectively you're saying rather than marketing a product as “this is Wonder Bread,” you’re giving the LLM the ingredients of what’s involved.

Reed: So it is very literal and exact about what it could be doing. Okay. That's very helpful, analogy for me. Thank you. And then as you're working on this project, I'd be curious to hear more about what other things you had to keep in mind for this specific project. Whether it's your first MCP server that you're working with or your hundredth, what are the things that developers should keep in mind?

Lizzie: For this project, I had to debug in prod. I had to use a real website. I had to click real links, type in my real password and username programmatically, and do a real text box. So it was testing the real thing, and I was afraid the website would start suspecting some things. Earlier this year, I tried automating NBA All-Star voting, and I was able to do it via CloudFlare browser rendering for three days. And then after three days, they were like, you're a bot. And I could no longer do that.

Reed: Who were you voting for, by the way?

Lizzie: Steph Curry.

Reed: Okay.

Lizzie: For years, fan. For this project, it was also hard to keep track of layout shifts and button loads. Some text boxes and buttons did not always load in time, so there were quite a few timeouts. I had to have retries and fallbacks.

Reed: Mm-hmm.

Lizzie: And sometimes the tool doesn't work, and then I'm just like, cry again. Like, it works. You have to keep DOM interaction as minimal as possible. You don't want the website to know what you're doing, and you also don't want to overload or confuse the host or the server. Honestly, both probably.

Reed: Mm-hmm.

Lizzie: This is a headless browser and it's not the same as headless logic. We can control our headless browser, but we should program the logic. We should not leave the logic to the LLM. By that I mean, don't code “click the third button from the top.” Instead say “click the submit button.” Be specific, explicit.

Lizzie: And to the LLM, pass off things you don't need to rely on as much. Not quite an action like “click the button.” Programmatically, you're saying “click this button.” But that's not AI. Something like you can trust or don’t need to trust as much, I guess.

Reed: Okay. Great. And then what would be next with this project?

Lizzie: CloudFlare workers has cron triggers. So you can automate the booking of a court. You can say, run this tool every day at this time. When court bookings open, you can say, book this court as soon as you can, and then you'll beat people out.

Reed: Great. And if folks want to learn more about remote MCP, follow you, follow more of the content you put out there, where would you direct them? And if there's anything else you wanted to wrap up with, would love to hear any final takeaways for folks.

Lizzie: Yes. With MCP, I think LLMs can definitely go from text prediction to task completion, and that's exciting to see. You can chain together LLM calls, function calls, and different steps broken down into tasks.

Lizzie: You can find me online at Lizzie Pika, L-I-Z-Z-I-E-P-I-K-A, and lizzie@cloudflare.com. I will drop some links in the video description for CloudFlare Playwright MCP, browser rendering, and using Stytch to authenticate your MCP servers. I can't wait to see what you build.

Reed: Great. Well, thank you so much, Lizzie. Really appreciate you walking through that. I think one of the things we get really excited about is showing the power of putting something that maybe is a small everyday task or common weekly task into this AI interface.

Reed: It really allows us to get away from users having to relearn a UI across every single site and application. That's one of the things we're really excited about at Stytch—in terms of apps becoming agent ready and CloudFlare providing the tools to allow people to host remote MCP servers, seeing that entire flow. Super helpful here. Excited to add this to the Agent Ready series, and we hope you'll join us next time as we dive deeper. Thank you.