🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Browser Power: Building MCP Tools That Do Real Work (AIM224)
In this video, Patrick Gryczka, Senior Solutions Architect at Cloudflare, presents on building MCP (Model Context Protocol) servers using Cloudflare's developer platform. He explains how MCP servers enable LLM-based agents to interact with siloed data across applications like Slack and Jira. Cloudflare worked with companies including PayPal, Stripe, Webflow, and Atlassian to launch production MCP servers, with PayPal achieving deployment in just three days. The platform uses Durable Objects for serverless compute with stateful storage, offering horizontal scalability where each conversation gets its own sharded resources. He demonstrates an agent making bookings through browser rendering services, showcasing interactions beyond traditional APIs. Additional features include dynamic worker loaders for executing agentically generated code with near-zero millisecond cold starts.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Introduction to MCP Servers and Cloudflare's Developer Platform
Hello. Very nice to meet you all. My name is Patrick Gryczka. I am a Senior Solutions Architect at Cloudflare, specifically covering our developer platform. Our developer platform is essentially focused around offerings like Workers. It is a serverless edge-based compute offering that gives you both storage as well as workflow and compute primitives.
What I'll be presenting to you today is essentially a session around building MCP servers. We have worked with a lot of companies to help them bring their first production MCP servers live this year. We worked with a large batch of companies earlier in about April or March of this year to push things forward in a nice wave. We'll start, I guess, at the very start in terms of what is MCP.
MCP was defined late last year by Anthropic. MCP is Model Context Protocol. MCP servers essentially are acting as almost similar to what you might have looked at for APIs in the past as a means of allowing interoperability between siloed data among different applications. What MCPs now serve as are essentially an interface that allows for your LLM-based agents to interact with that otherwise siloed data.
So if you want to have an agent be able to update a Slack message, update a Jira ticket, update any of this content that's available across specific services, an MCP server can act as essentially that interface for providing tools. A tool will be, depending on the complexity of it, something as simple as surfacing up an existing API, but it can also be more complex. It can have more custom logic, and it can also have more flexibility because you can still rely on an LLM to not only call an individual API, but to actually make plans and to really execute more complex tasks.
So we believe that we have a pretty compelling offering and way for you to launch MCP servers that allow you to both move quickly, maintain developer velocity, while minimizing operational overhead. I think there are some varying opinions in terms of what the future looks like in terms of how many MCP servers organizations may run. Just of our own kind of Cloudflare remote MCP offerings, we have, I think, about 13 of them that run the gamut from observability MCPs that surface up your logs to your coding agents to documentation ones, to ones that even offer up some of our services like Radar as availability.
And I think there will be an aspect where giving customers the ability to make granular choices in terms of what features and functionality they want to incorporate into their workloads is probably going to be a bit of a winning strategy there. Touching back on our initial demo day earlier this year, companies like PayPal, Stripe, Webflow, Block, Atlassian all worked with us to launch their first MCP servers. It's also why we feel very confident saying that we're one of the fastest places where you can build an MCP server.
PayPal worked with us to within three days go from a concept of what can they deliver to essentially having a production-ready MCP server for their invoicing scenarios. In terms of what you get with an MCP server on our platform, you can use our Agents SDK. An MCP server is not a kind of packaged product. It is built on top of our primitives.
So essentially your MCP server will be an abstraction on top of services like our Durable Objects. Our Durable Objects offer serverless compute tied with stateful storage. So that allows you to have both scale-to-zero compute for the actual calls that are made to your server, while still maintaining a stateful backend that is able to maintain both your short-term and long-term memory for your ongoing conversations.
This also runs on our distributed architecture, so you get the benefit of having a single global data plane. So regardless of if you have users coming in from the United States, Europe, Asia, without having to manage separate control clusters, manage separate updates across regions or availability zones, you get the benefit of having localized compute for each of them and localized storage for their conversations without operational overhead.
MCP is, well, many of you probably already have many conversations around MCP, but part of the reason for the excitement is that this feels like a new channel. This feels like a means of now making services available through essentially agentic interactions.
It feels like if companies, whether those are public services like public sector interfaces, or even if those are more like e-commerce interactions, it feels like if companies aren't surfacing up their products, their offerings, their means of completing conversions and completing transactions and surfacing up information through an MCP server, they may be passed by. Because to a degree, this feels like how information is going to be surfaced up through this interface that seems to be kind of encroaching on what search has traditionally covered.
Live Demonstration and Technical Architecture of Durable Objects for MCP Implementation
So here, I have just a simple chat interface that plugs into one of our MCP servers. What this MCP server is doing is it is interacting within the durable object. It has access to all of our services, so it is able to make use of services like our browser rendering services in order to actually interact with web pages.
Your agents may not always have clearly defined APIs that they can call and interact with, but using options like essentially browser rendering, which gives you a headless browser and allows you to then both scrape content from it in HTML, Markdown, JSON format, but also have puppeteer-style interactions in terms of clicking buttons, entering text content, you're able to actually interface with pages and allow your agent to plan interactions without needing to beforehand fully have API key access to the system you're interacting with. Here, specifically, I'm just going to go ahead and ask it to make a booking for me for a given time slot. So this interface is just meant to be a little showcase of court availabilities across courts, let's say one, two, three, four, five, six for a given park. I'm just going to go ahead and ask it to.
I can do a little bit of a showcase here, so here we can see that it's passing in the information that's available. So that should finally come through. In terms of interesting bits, that largely just is meant to showcase that you can have these interactions not just go through tailored paths, like a path that's well defined through an API, but you can actually have your agents dynamically pull in what is the structure of a page and make it actually interact with a given UI interface.
In terms of underlying value that you get from the solution, it really does in my mind come down to the fact that a durable object is going to be able to offer you remarkable horizontal scalability to where each session, so each of those interfaces that come up for a chat is tied to a single durable object instance. A durable object can instantiate across IDs, so programmatically, every conversation that we're having gets its own sharded compute, sharded storage,
so you don't have to worry about suddenly scaling that out when there's more traffic coming in. You don't have to worry about scaling out your memory and storage when the millionth conversation has started, because that is automatically horizontally scaling across your newly instantiated resources. It also gives you a decent bit of flexibility where that memory is still tied to that individual Durable Object instance. So if you're looking to have conversations tied to a single user, you can have that easily implemented by having them tied to a single ID, but you can also have multiple individuals interacting with a single agent conversation just by tying their conversation back to the same ID.
So you get the ability and flexibility to have various interaction patterns, while also having an easy routing method if you do decide to make multi-agentic interfaces for having them interact with separate instances. If there are any questions that come up throughout implementation or approach, there's quite a bit of content that we have regarding various SDKs and various tooling that we have to improve agent workloads.
So beyond just browser rendering, we now also have dynamic worker loaders. Dynamic worker loaders allow you to dynamically provide, whether it's JavaScript or TypeScript code, that is ideal for scenarios where you may be actually generating code that you want to execute yourselves. That can be provided to a dynamic worker loader and have an execution with, again, the same performance you get from a Worker. So near zero millisecond cold start times, to the millisecond compute billing, so very attractive for both sandboxing use cases, but really that execution of untrusted, agentically generated code.
Thank you so much for your time, and let me know if there are any questions about our offerings.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)