MCP servers on Cloudflare Workers

All right. Hello, everybody. Welcome to Cloudflare TV. My name is Brendan Irvine -Broque, Director of Product here at Cloudflare. And I'm really excited today to be joined by Hemanth from Paypal. Hemanth, do you want to introduce yourself real quick? Hi, I'm Hemanth. I'm a Senior Staff Engineering Manager here at Paypal. I'm from the check out R and we're doing some interesting things here. I would say very interesting. So Hemanth and I connected a little bit ago because we started talking about building MCP servers. And so if you didn't catch some of the announcements today, we've been talking at Cloudflare about MCP servers for the past couple of weeks, local MCP servers since early in December. But today we announced that our agents SDK supports being both a remote MCP client, so it can talk to other MCP servers, as well as being an MCP server itself. And so we had launched that initially a couple of weeks ago and the two of us got connected. I think this was like, was this on a Friday? We just jumped on a call and I think shout out to Sunil, Sunil Pai, who has been the wonderful creator of the agents framework. You and him, I think, used to work together and we started talking about building an MCP server for Paypal and took it from there. Yeah, absolutely. I think when MCP launched in November, I did try it on my official laptop and guess what? It failed to connect because, of course, security matters a lot in Paypal. We have a lot of guardrails around it and I was exploring that on the side and there are multiple teams who are also experimenting on a few many things like the SDK team led by Ryan, who also had an MCP server which you can run locally. But I was thinking more on, hey, how can we make this remote? Can we dockerize? And that's when kind of Cloudflare announced saying that, hey, now we support remote MCPs. And Paypal also is a customer for Cloudflare. I was thinking, hey, why not we do this? And it reached the ears of CTO Srini and he completely supported this. He got in like the SVPO for AI in Paypal. And all of it aligned. And I'm just an ant here on the hill. The effort has been across multiple teams. We had folks from edge engineering. We had folks from InfoSec, AppSec, legal, compliance, tech writers. So it has been an amazing journey in the past week and it's been one of the fastest launches that we have seen from idea to production. And it has been great collaborating with Cloudflare, of course. That's wonderful. And so can you tell me a little bit more about what drew you to think about building a remote MCP server and what kind of made you think about Cloudflare? You mentioned Docker containers and some of the pain there. What made you make that leap? Yep, absolutely. I think Cloudflare, personally, I've been a Cloudflare user for a very long time. And even my personal site runs on many aspects of Cloudflare. And the amazing part, of course, that Cloudflare brings in is the infra piece. Imagine us writing our own server, dockerizing it, hosting it on enterprise infra. Yes, it is possible, but at what velocity? And how can we scale and how can we have workers running? And everything is cooked in. You name what you need in terms of security or scaling. Cloudflare has baked in everything for us. So I think it was a no-brainer at that point of time in terms of velocity. How can we quickly get a remote MCP? Should it be just an experiment or should we take it to Prague? Let's get a feel of it. And it was super easy to kind of get started. And I know we paired with you for the OAuth flow. You opened up your laptop on a Saturn and said, hey, let me cook OAuth flow for PayPal. Let me try it on our end and see how it works. I think this kind of support and bringing in the Cloudflare's brilliant minds onto a Slack channel and trying to brainstorm, trying to solve it as a team was amazing. And we are seeing the fruits on how easy it was to kind of bring up an MCP server. And I think the Hello World MCP server was up within a day. And we were able to even try to bring in our very first use case from one of the payment folks. Vikram helped us to kind of get in the invoicing use case. So all of that happened so soon. And then we had to make sure all the security and infra scaling and all of it is in place. And we were able to launch mcp.paypal.com. So that speaks a lot. So I think the decision of trying as an experiment on Cloudflare to being on production was good and was fast. Yeah, I remember it was fun. I remember trying this in your staging environment. Maybe this was like on Saturday and it was like, okay, this thing works. It generated a real invoice. And I think by Monday, mcp .paypal.com was live. That was really awesome. I'm curious how you think as an engineering manager about kind of encouraging your team to take these experiments. Like, you know, it seems like some of these tools with AI and with teams are adopting them much faster than other types of technology. Like, what do you think is different? Or how you kind of manage that with your team? Yeah, that's a great question. I think I've been lucky to be a part of such a great organization and PayPal as a whole, because we have been representing in ourselves in TC39, ECMON, some of the bleeding edge conversations with what's the future features of like JavaScript or where is the web heading and likes. So always riding on the bleeding edge is fun. And it's a risky factor too, right? So you should be very cautious about what you're trying to bring into production. I would like to set the experimental mindset within my team saying that, hey, try to see what's new. And if you're curious about things, and if you're interested about what you're trying to do, always try to see what's new and try to experiment a lot. I think being curious and experimental is one of the key criterias to kind of bring in something new and at a good velocity. I think that those are some of the key factors I feel is important. It's not just running hackathons or trying to brainstorm and trying to see what to build next, but it's just being curious and trying to set something tiny on your own machine and try to experiment with and see how it goes. That's awesome. I'm curious, one of the things I noticed about what you launched was in some sense you kind of oriented it for developers, but I also know that you were thinking a lot about like the remote use case and people being able to log in and go to their PayPal account and generate an invoice themselves. It seems like the whole space around MCP servers has that like duality to it where everybody's kind of both building things for developers and at the same time, often in the same environment, even for kind of prosumers and consumers, businesses, like, how are you thinking about PayPal's MCP server? Yeah, that's a great question. I think it's also a bit of a paradigm shift for both developers and whoever is using MCP. Thinking out loud, I feel MCP would end up being more like a marketplace within all of these clients where I could do a just one click installation and I need not bother about cloning a GitHub repo, running the server locally. I think this mind shift is slowly going to happen because I feel from the enterprise world, at least on Cloudflare, PayPal is the very first one to launch a remote MCP, if I'm not wrong, right? When the blog posts came out on like, what, a Tuesday and I think by Friday we were launching, so you got into my DMs at least the fastest. Yeah, so I think that mind shift should happen because every time I hear about someone using an MCP, the first question that would come to me is, hey, can you pass me the GitHub repo? And of course there's a config on how do I run this? So I would say, hey, you don't need no GitHub repo, it's just the config. You set it up and here's the remote MCP and you can just connect to the MCP server. I think this mind shift is required and it would happen slowly. And it could be also other way around where people want to run it locally because they have few experiments on how to contract with the server locally or so. So PayPal gives both of the flavors, right? We have the gigantic toolkit with MCP and then we have the remote MCP sitting on Cloudflare. So I think people are not much used to the remote aspect of it and that's where we need to push a lot. Yeah, that makes a ton of sense. What kinds of tools are you thinking about building? I've only played, I think, with the invoice creation tool. I imagine there's so many engineers at PayPal who have all kinds of really interesting ideas. I'm sure some that you don't want to share, but what's on your mind? What do you kind of inspire next for you? Yeah, I don't want to spill the beans, but on April 28th, we have the Dev Day where we are going to bring in a lot, not many use cases, not only just MCP, but all the agentic AI stuff that's happening. So please do sign up for the Dev Day that's happening on April 28th. And if you ask me personally, I would like to see this MCP server to at least start with serving all the public-facing APIs that Checkout has, right? Which is vast. Made free, maybe from Checkout to what we saw on invoicing or peer-to-peer. We have tons of APIs, public-facing. I feel that would be a good first move. But how does the MCP server talk to some of the internal APIs? How can Cloudflare help us orchestrate? How do we maintain the security? All of that is still of an exploration. That's a really interesting topic to me because at Cloudflare, we obviously, we have a really big API too. And we face the same types of questions of should a company like Cloudflare or PayPal build one giant MCP server that's capable of everything? In which case, you probably have to ask for a lot of permissions from somebody, which I can't imagine a security engineer who logged into their Cloudflare dashboard wanted to give any right permissions. So we've been starting to think about like, should we build many different MCP servers? How are you thinking about that right now? Yep. I think orchestration of MCP servers, right? That would be interesting. The advantage I see of having domain-specific MCP, say for example, I come from the Checkout org. And if we host up a Checkout-specific MCP, we are responsible for the entire start of the MCP, maybe what APIs we want to expose, deployment. All of that is focused within the team. We can have a good sprint cadence and all of that and have the execution right in place. Versus we have one big MCP on the monolith sitting and there's a lot of PRs coming in. The team which is handling this mcp.paypal.com might feel a lot of pressure to handle all of this. Like, should we bring in a good inner sourcing model? So that, or should we bring in a good, like a self-paced way to set up tools? Or should we have an agentic toolkit that gets imported into MCP? So there are various flavors. We haven't like decided as a team, like, because it includes a lot of teams around, right? And as we evolve, I feel it would be more like MCP per org. And then there's MCP orchestration happening versus one single MCP, which owns it all. That can happen if we have a good model for it, right? Like, hey, here's the least path of resistance on how you could add tools and enable your services on like one single monolith, right? If that's possible, then that would be a good place too. So we are still exploring. I don't have an exact answer, but there are a lot of thoughts in our mind on how can we make this happen? Yeah, absolutely. I think that gateway in between, or what did you call it? You said something other than a gateway. Orchestration of MCP. Like an orchestration layer. I just see so many people trying to build interesting things in that space. And some companies where that orchestration layer kind of has direct access to a lot of credentials. Some where it's more of just a proxy in between. Some that are integrating with more of an identity layer so that there are like internal tools for enterprises. I think that's like a space that I just see so many people build in and I don't know what ultimately is going to end up working. Yeah. If you look into MCP itself, it was more influenced by other protocols like JSON RPC or the thing that Microsoft brought into for IDs, right? So I think it got influenced with existing patterns. I believe the same would happen as we start scaling with MCPs. We would come up with some of the existing patterns that evolved to fit into the new framework. That makes a ton of sense. It makes a ton of sense. Anything else do you think that other people should know who might be listening to this or learning about model context protocol and MCP servers for the first time? And maybe they're in your shoes from where you were. This is only two and a half weeks ago maybe. I think everything's moving so fast in AI. But what should people think about if they're going to go spin one of these up for the first time? They should not think that this is rocket science. It's fundamental networking at the end of the day. So set up a hello world MCP to start with. Get the hang of it. And then think about remote, right? Remote is the new kid in the block. So when you're building your MCP servers, think both local and remote and see which use case are good for remote and which is for STDIO, right? Having said that, the spec is evolving at rocket speed. You know that more than me. We have the HTTP streaming coming in. So that is something I feel developers should keep their eye on. With SSE probably getting deprecated, still the support would stay. We should look into... Did I lose you a bit? Yeah, that's okay. There was some network issue. So we should keep our... You should be mindful about both remote and local. Just start with a hello world and keep an eye on the spec. As it's evolving, it's bringing in newer aspects. And we also hit a roadblock in a few of the aspects that we are discussing on the GitHub discussions for the spec, right? So it's an evolving space. Have one use case to begin with. Make that happen on local. Make that happen on remote. And then you could see all of it in action. I think that's wonderful advice to end on. Well, I really appreciate your jump in on this with Cloudflare TV. And I'm looking forward to seeing what you launch next on ncp.paypal.com. Absolutely.