AIDD Day: MCP Edition - Garrison Snelling - From The Edge and Back

So today we're going to be talking about From the Edge and Back. This is a Tolken twist. I don't know if anybody is a Lord Lord of the Rings fan, but um I was like, you know, it's let's let's let's let's go with the Tolken reference here. So from the edge and back. It's like there and back again. Um, but this time instead of it being uh about uh a ring of power or one ring to rule them all and a volcano and Sauron, it's about turning any REST API into an MCP server. Very similar. Uh it it's almost a uh Middle Earth is really going to be decided by the fate of this REST API and MCP servers. We can all agree on that. Um but uh so yeah um the next thing that we're going to talk about so I guess kind of kind of go through what what we're looking at here. We're looking at a REST API that we've made. It's going to be a custom one that it's very simple. It's not complex. It's just it's not nearly as ambitious um as the Twitter API that Justin worked with which by the way I rewrote my whole talk um to follow all of Justin's best practices. Don't worry guys, we're going to be completely congruent. Um, I I I originally wrote this with standard out and I was I had to rewrite over HTTP because Daniel's talk was so good. I'm totally kidding by the way. I actually did choose the correct protocols though. Daniel and I were or Justin and I were super aligned on that. So that was cool. Um, one thing that I would do want to mention is that we have a ridiculous deal. It is a Black Friday super early bird. You're all birds now. We've just decided it. And there's 45% off. You can scan the QR code. Get your phones out. Come on, people. Scan the QR code. AI-driven development master class. You can write AI powered code you can trust. Really a lot of good content in here. Justin, Daniel, and I and many and a few others have done a lot of hard work to kind of do a lot of the um pre-work to understand exactly what the future of AI-driven development looks like. Uh my my lessons specifically are focused on how to tool your team and that looks like custom tools. I think in the age of AI, what we're looking at is a lot of custom tools. We all have our own specific workflows. It was super cool to see um Daniel's talk and how he was generating images on the fly. I was like, "Oh, I want that. That's really cool." I was really appreciative that he showed that. That's what all this stuff is filled with. So, go ahead, check it out. I can't wait to see you over there. We have a community. We can all chat. Um if you like chatting with me, you'll like chatting with me there. Straight up.

All right. What we're building today, we're going to be building a real world example. We have a products API and an MCP server. U what you're going to learn is how the MCP protocol works in this little environment. Um, it's not going to be as broad ranging as Justin's. By the way, I just want to call out Justin literally went into the MCP spec. We're not doing that today. We're going to just focus on a few little details about how you could take a REST API and make it an MCP uh protocol. This is really interesting. I think that this is going to be a lot of use cases for us moving forward. When you look at what people are primarily using MCPS for, they're really using it for tools, right? And so what that means is that we can take a lot of our existing REST APIs and we can just convert them just straight up. And that's why I think you're seeing so much rapid adoption. When Justin showed that chart, I think that's exactly why, which is great. Um, and so I think a large portion of the work that we're going to be doing is probably going to be getting our REST APIs working with MCPs. An example of this is Laravel and uh, um, Cloudflare. They have MCPS for their docs and I think this is a common thing for everybody. It's just that I've used both of these and they're super amazing. Nux has one too. We we saw that they're super amazing to be able to work with them and I don't think it required much work because they're converting what they already have to work with this protocol. So, it's super interesting. Um, we're going to do a little bit of edge deployment. We're going to look at a dual interface, one API, two protocols. Um, it's all going to be one codebase kind of nicely bound together. And we're going to look at some real code. I have slides just to help us get through. Uh, but nonetheless, um, it it should be a lot of fun.

Um, the problem, why wrap a REST API with an MCP? I'm glad you asked. AI agents need context. When you look at the traditional approach, you have a fetch, right? API.ample products you would fetch it in right it's all HTTP HTTP itself when you look at the protocols is a standard it's very it's not it is a standard in that and it relates to MCP in that way as an MCP is a standard but in any other way it essentially is not relatable um HTTP is very uh fluid you can use it for a lot of different things you essentially have a body for all the different requests and then you can put whatever you want in it um it has no uh conceivable like schema built into it. You know, you think of all the work that we as developers do to get uh our rest APIs to have schema validation built inside of them. Um MCP kind of has that already built into the protocol itself, right? It does a little bit of schema validation so that it can understand which call back call call backs it's going to get all that sort of stuff. And they're very different things. And so um the what we're going to be looking at today is how to interrupt them, how to how to or rather how to integrate them. Um, if you look at the traditional approach here, manual integration for each API, no standardization, limited discoverability. There is no discoverability in REST APIs, folks. Um error handling varies. Uh we all handle errors differently. Can we go ahead and acknowledge this? I just want everybody to go to Twitter right now and acknowledge that we as an industry do not handle errors consistently with REST APIs. We all act like we do. We all want to act like it, but we don't. um even even within frameworks not all of us use the the framework specified error handlers um MCP approach here we have you know a list of tools right this is kind of like almost like an index dot an index inside of like a folder system right it's listing out all the tools um and then we have the ability to call those specific tools with the proper uh schema we have it's a standard protocol it's self-describing http is not self-describing folks that's why we have docs um it's type safe http is type safe, folks. That's why we have Zod. Um, it produces MCP produces consistent errors. This one's probably a little bit more uh nuanced. I'm not sure that it produces consistent errors. Uh, but it does produce um in a very similar fashion is is the better way to say this.

Our example, what we're going to be starting with, um, we have a REST API. It has a product interface. You can see an ID, a name, a price, description, in stock. Um, and then we have just an array of those products. Wireless headphones, $99. Not a great price. Hope it's uh hope it's the AirPods. Then it is a good price. Um, we have rest endpoints for these things. Get uh the products to list products, get a product ID, get the products themselves, etc. Uh, we can test the API. I'm I'm just kind of going through this to un for for us to kind of get a shared perspective on what what what REST APIs are. Primarily when you're interfacing with REST APIs, you're doing it via code. But you know, if you wanted to do it via curl request, this would all work. Right? We here we have three get requests and one post request. And this is all very simple. It's coming from a coming from the actual CLI. But MCP doesn't have that, right? There is no I mean they can do cur curl requests but um curl requires a sandbox um to some extent.

Now let's add the MCP wrapping at rest with the model context protocol. What is MCP? We've talked about this a little bit. I'm going to just kind of go back to it just for a second. The model context protocol is a standard uh AI API for communication. Here you have an AI agent clawed in this case um using the MC protocol to talk to an MCP server. This is our Cloudflare worker um in this case and then from that Cloudflare worker it makes an internal call to a REST API and then sends the response and then the MC MCP server can then return the structured result. I think of this u as somebody who's kind of struggled to get their minds wrapped around get their mind wrapped around MCP. I think of this as being a pretty solid understanding, a a great first look into what MCP is. Um, because you can essentially start with a REST API, say, "Okay, I know what a REST API is. I can figure that one out. How does that connect to the MCP concept?" And when you connect those two dots and then connect it to the agent, I think it really helps you understand, it gets through the noise of the magical kind of bits of uh AI. And you know when we think of magic inside of development magic is sometimes a good thing if you don't want to think about what's happening right when you deployed a railway or versell there's some magic that happens there where you're not thinking about the build anymore and that's nice because you don't want you didn't want to think about the build but there are other times where the magic hinders you from learning and so I think in in in many case this simple example is not magical it is meant to kind of build on understanding understanding to help you grasp what the MCP protocol is kind of specifically for. Uh MCP has tool definitions. This is the best thing for it. Again, if you remember Justin's uh chart of all the people who have implemented MCP tools, um this is this is the primary thing. I uh joked on Twitter with Justin is that, you know, maybe instead of simple MCP, we should have just tools because that's realistically what we all want is just tools. That's it. Um thoughts uh each each MCP tool definition has like a name a description. These are these are meant for the a for the LLMs to be able to understand and deduce um what which ones they should use, right? And so it's important that these are well documented and not just like uh you know nothing. So as developers this is kind of an important detail to us um because we always love writing documentation. That's a joke folks. We don't always love writing documentation. You notice that we have an input schema. Next, it has type, objects, properties, category, instock. These are all um properties that you can actually input and parameters is what you'd call them in HTTP land and be able to configure um the MCP, right? Or the the actual what do you call MCP requests? MCP request. We're going with it. Um and that makes up the MCP tool definition. Um we have more tools here. We have a git product. This correlates to um you know list products or or get individual product create product. All these correspond to a rest API um executing MCP tools. You'll notice that we have a classic switch statement here. This is kind of the primary method. Uh the nice thing about in my opinion the nice thing about rest is you can get each file into its own specific like file. In MCP you get a switch statement um most of the time because you have to have slashmcp you have one internal you have one internal call right and so you end up having to kind of cascade them out and route them to the specific calls which um is fine we've all used react router before it's great here you can see you know the the actual um here you can see list products for the case and then I referenced this the parameters what we're doing is we're converting the input schema to parame parameters in HTTP land. So they have like a onetoone relationship. Um and you can see that we're also building URL and then we just do a fetch, right? It's pretty pretty simple here. Great product is very similar. the MCP request handler. Um, the this is kind of where the bulk of the magic is happening where you have uh you know a MCP call and you'll see this in the codebase once we start to go through it come through it identifies what the body method is tools list tools call um and then does some stuff with it. The execute tool um method is Oh, sweet. I have highlights. Yes. Um the body equal tools list. This this is uh returning just a JSON um object of what the tools are. Very simple. Uh the tools call is actually calling the tool. I know that's surprising to you. Um and it uses the body.params to do that. Um it then calls the execute tool method. Um, and this is kind of I mean this handler is is where the bulk of the swap the switching is is uh kind of happening which is really interesting. We have a main application. I'll show that to you in the codebase. It's using Hono. Um, if you uh don't know Hono, it's really cool. I can actually show that to you um later as well. Um, see project structure. We have a source index.tx ts api.ts s MCP um all those sorts of good things.

Testing the MCP server. We talked about how to test REST, but how do you test the MCP server? Um we have a protocol test that you can use. We're not really going to mess with this. Um it works. You can see the curls coming through, but what we're primarily interested in is does it work with cloud code? And that's what we're going to see. You can see here that on local we can add in the um HTTP products API, which that's exactly what we're going to do. And then um we can also after we get it deployed to Cloudflare, we can add that in and then we can verify it's connected with MCP list which is nice. Um key patterns that we want to look at and this is this is I I really liked this slide because conceptually it helped me grasp exactly um where how these things correlate. This this seems nice to me. So in classic land, forget about AI. It's it's before AI. We have an API with API/proucts and it's a get method. What would you expect it to do? Well, ironically, you'd expect it to list the products. And then the next one, API/proucts ID. What would you expect that to do? Well, get a product. Um, same thing with the post API products create product. Right? We have all these mappings. Okay? And what you're seeing here is that on the REST side we have a traditional API and on the MCP tool side we almost have like this like um TRPC gRPC style methods that are allowing for remote procedure calls right um which is pretty nice. Here you can see how the query parameters directly correspond to MCP tools. We have a category in stock um as parameters in HTTP land and then they correspond in MCP land to being input schema properties category in stock. Beautiful. I love it. Again, path arguments and this is the thing. This is where I don't love the correlation. Let's be honest. Um ID in restland is obviously required. If you don't have an ID to get the product, it is incredibly hard to get the product. Um, and so it's not quite, you know, it is a parameter, but I think you understand what I'm saying. It's not, it's not the same as a query parame. Sorry, folks. Um, and so the way that MCP handles this though is that it handles it as the same input schema properties with an ID, but then you set it as required. And so I'm trying to think about like if I was making the MCP protocol, I think that that probably is uh probably what I'd do. But when you think about converting it from restland, uh I I wish we had maybe more of like a reserve field, but probably wouldn't have designed that if I if I did it to be honest. Um the request body, um this one also input schema. And so all of this is using, you know, it's al it's all has some sort of schema to it as opposed to HTTP, HTTP land with a payload, which is the wild west. We all know that you can send anything you want in a payload. Um, boy do I. Sometimes, uh, if y'all have used or Firebase, sometimes you're just jamming stuff in key value pairs. We'll save it later. We'll figure it out. We've all been there. Um, MCP tool, you're not doing that. What you have to do is you have to define the input schema with the properties, name, price, description, category, and then put them as required fields if you want them. We are gone are the days where you're just jamming stuff into a fire fire store uh table. I forgot what their nomenclature is there. Have to figure that one out. Um pattern five, the response format. Um, it's uh you know a little bit it's not really that much different. Um, but but most of the time it it needs to be machine readable to some extent. Um, it always returns content and array with type and text. And so you can see here that we have type text and has a few different protocols. You can go look at the spec just like Justin did to see what exactly it is, but I'm just showing you what we're using today. um error handling um we have we're using JSON RPC that's required um by the by by the spec and so you can see that we're doing that here um deployment we're going to the edge today and I hope you're ready u not the edge of the world by the way um I don't think the earth is flat that's a funny joke um we're going to use Cloudflare workers um to actually push this to deploy it rather to um the internet and that's going to give some that's just going to be really cool because you're going to be able to take an API and then get it get it working on on the uh on the internet. If time allows, we may even try to ditch our custom API and move on to a public API. We'll see. We'll see. I don't know. No promises. Let me check time. Okay, cool. U local development will do mpm install all that stuff. Yep, you get it. Deploy to Cloudflare. We're going to test the MC MCP server with um Claude and uh it's going to be pretty magical.

The request flow, you can get a sense here. We have a client. Um this would be Claude in this case. It's not like a browser. We have a client. It's going to call out to the worker. Um well, I guess in this case, this is the rest flow. So the client is actually in fact um the browser. So it's calling out to the worker. It's going to get to the API. It's going to send it back. Filter products JSON true send it back. Right? But this this one makes sense. Um with the MCP flow, it's a little bit different. Um you have claude, it calls out to the worker. The worker routes to the MCP which is actually inside of the worker. So kind of a nesting doll which is one time um calls out to the API which is also inside the worker. So um really what the flow would be is like if you want to just ditch the worker concept it would be claude MCP API and then you would wrap MCP and the API with the worker because they're both running there. Um so you route to the MCP handler parse tool name and args. It does an internal fetch to the API the rest API itself wraps it in MCP format and then sends it back as an MCP response.

Straightforward architecture diagram here we have a client browser. We have a claw desktop. Actually, in this case, we're not going to use desktop. We're going to use cloud code because um it's inside of my VS Code. By the way, hot take. I switched back to VS Code, folks. It's pretty awesome with cloud code and VS Code. It's a game changer. I know everybody's using cursor windsurf, but cloud code in VS Code. It's amazing. Uh we're going to call it the Cloudflare worker. We'll use the router. We'll keep calling the real word real demo. Let's take a look at this. Okay, now it's time to actually look at some code. I hope this goes well by the way. Sometimes working inside of the actual codebase live is a scary thing. Okay. See if I can center this. Oh yeah, there we go. Look at that. Isn't that pretty? Let's look at our index. index dot Oh, I'm in the prompt mode. Sorry, folks. index.ts. All right. Here you can see that we're using Hono. Um, Hono is really interesting, by the way. Um, I know you don't need another JavaScript framework, but I'm about to give you another JavaScript framework. Um, I was talking with a dev recently and I told them that I was using Hono and their exact response was, "Please, no, not another framework." But here we are, folks. Isn't it great? Isn't the world just wonderful? Let's look at Hono. So here see here here you can see HONO. It's a very simple um framework. It's unlike all other frameworks in that um it's simple. They all say they're simple. Um with Hono you just have to import Hono and then you can do this is this is all you need just to return a hello world which is really nice. Um I'm really appreciative of it and it works inside of Cloudflare really really easily. Actually it works in Cloudflare Fastly Gob AWS or Node. Um, so yeah, it's pretty pretty pretty wonderful. And then they also have a hono tiny if you're interested in that. Um, I like to write performant systems myself. You may not. That is your prerogative. Um, that that that's on you, not me. Um, so we're using Hono. And here you can see that we import Hono, we start a new app. Um, we say that we're going to enable cores. Um, that could bite us in the butt. We'll see. Um, and then we have an API. And then we have the MCP handler. And then we also um for this for this we're we are documenting MCP on the root um endpoint. So we're saying CFM MCP REST API plus MCP server. The endpoints are these and then MCP here. Um, so pretty pretty cool. Uh let's see if we can just pop this open real fast. http localhost. I can't remember if it's 8787 is it? Let's find out. >> Hey Garrison, uh do you mind zooming in on the code editor a little bit? >> Oh, thank you Daniel. >> Thanks man. >> There we go. I think that's better. Yeah, I can see that. Great, man. >> Awesome. Thank you, Daniel. >> Ominous voice. Yeah, >> let's go take a look at this. So, you can see the actual JSON out output here, which is nice. Self-documenting just like MCP. All right, we solved it, guys. Rest can be self-documenting. Time to switch away. Um, so let's take a look at our API here. You can see that we have the product interface with an array, all that good stuff. We saw a little bit of this here. You can see the routes, which is new hono. We export this route. Um, and then we do get products, products ID. All this is very, you know, this is not not complicated. Um, we have a we're returning a product here. We push the products, all that sort of good stuff. Um, all this is using just our in inmemory data structure not complex. Um, from here we have our MCP handler. The MCP handler is where the magic happens folks. Um, this is where we go to Middle Earth. We see what's happening there and we destroy the ring of Sauron. First we have a list products. You can see it lists all the products. get product, create products. Again, it's using all the different REST APIs, input schema, everything has to be defined just right. So, AI is pretty useful in writing this stuff if I'm being honest. Then we have an execute tool. Actually, let's go look at the MCP handler first because that was ref, excuse me, because that was referenced inside of our post, right? So, the MCP handler, it does a we get the body and then the request ID and if the request ID is undefined, we actually just give it a one. I believe this would be a bit of a cheat, but for demo purposes, we're rolling with it. Uh, we define the base URL from the request itself, which is handy. And then based on the body method, whether or not it's a tools list or a tools call, we direct it to where it needs to go. And so in this case, what we're doing is we're we let me actually collapse this. So collapse that as well. And then that. So based on this, we have a response that we define right here. And then we let each one of these if statements do magic to the response. I shouldn't say magic. It's not magic. It's just code. We let these if statements update the response and then we pass straight up the response and if there's an error, we return that error. Okay. What I'm getting at here is this is a very simple protocol. This is not uh this is not magic. This is essentially a one route rest API whether you're using HTTP which we are in this case or even SSE which you would still have one route and so kind of Justin's paradigm what he was talking about as far as having HTTP maybe with SSE as well as the transport protocol um is a very simple concept in terms of getting the request into the machine itself. From here it becomes a little bit more complicated in the confines of code. So you can see the first if statement, we have the response set up here as just returning tools. Let's take a look at that. See what that does. What tools do you have? I probably should have hid that. It's not deterministic, so it may not produce the results that we want. Let's see. There it is. So you see here you can see that it's picking up on our MCP product management tool um from your connected MCP server. And so it has all these tools and that is you know doing exactly what you'd expect it to do. It is calling the tools call um and it's uh or not tools call sorry lost my place. It is calling the tools list and then just returning that JSON. Very simple. From here what we can do is we can do a we can try and use one of these methods. So let's trace through it. Okay, let's do a list products. Okay, perfect. List the products for me, please. Let's let that noodle. Do you want to proceed with MCPCF? MCP products list product. Yes, I do. Thank you for asking, sir. That was very kind of you. You can see that we got back a response. And you can see that now we have here are the products currently in your system total products three. You can see the bash um I think this is bash the output rather JSON. Uh so what that did just to trace through and see exactly what it did in the code right it goes through and it goes to method tools call that's the request that comes through in this proper protocol right you can see these are these are the these are the tools and then list product would be the name in this case we did a yeah we did list product that's exactly right and so if we go down here what it's doing is it's then going to execute the tool so let's go take a look at execute before we take a look at execute actually it returns the result and then returns that result JSON stringify so um exactly what you'd expect from what we talked about earlier go to the definition open this puppy up now we have a switch here we have a switch with a case of list products get products and you're starting to I think I think at this moment this is where when it became very clear to me okay okay so this is a wrapper around a REST API And that is exactly right. It is a wrapper around a um so what you can see here is that we're building the URL. This isn't magic. This is just a wrapper around a REST API. And many times, it's not to say that every time that you interact with an MCP, I think but many times I think that you're going to see a MCP as a wrapper around a REST API. Um, when you look at the methods that we're using here, um, we could definitely open this up and just do business logic inside of here, right? We could take we could literally cons take what what's happening inside of this API if we wanted to and put it inside of the switch and then wrap it around a in a function. Yeah, that that that could work. But the primitive of the web is is um the REST API. That's it. We we we've tried GraphQL and you know there are some people that are still using it but it is still not mainstream. REST API is built into the browser itself. It's what it's it is um fundamentally it's not going anywhere and that's um even when you look at GraphQL to some extent it's actually kind of a wrapper around the rest API. Don't tell your graphical friends I said that. Um let's look at git product. Git product is also very simple. Um it's just doing a fetch with the args has an ID good to go. Uh let's see now from here what we can do is we can take a look at our file tree over here and we can see that we have a wrangler.yaml and we can see that we can take this and we can have a sourceindex.ds which is our main file and we can take our wrapper and we can just straight up deploy it to Cloudflare. Um, before we do that, I want to show you that we're using the local one. So, let me pop a new terminal instance up here so we can all see it in all of its glory. Clawed MCP list. You can see that we're using localhost 8789. Um, so from here, what we want to do is we want to do mpm run deploy. We're going to deploy to Cloudflare. We're going to get a URL back. Hopefully Cloudflare doesn't go down. It wasn't me guys who took it down. That is okay. And now what we're going to do is we're going to use clawed MCP remove cfmcp products. And there we're going to take claude MCP add. Actually, I can't remember the exact transport. Yep, that's right. Perfect. Love it when a plan comes together. Now, when I was playing with this earlier, it was I uh totally missed the slashMCP just like Justin did. Um and I was like, "Oh my goodness, this whole thing is broken." And I was very frustrated. But turns out I was good. All I needed was the SLMCP. Claude in Oh, I spoke too soon. Let's see if it works. Oh, good. We're connected. Okay, now let's open up a new session and let's ask it, what tools do you have? We're waiting. I also have access to it lists through a bunch of tools, but then it says I also have access to list products, get product, create product, update product, and delete product. Pretty cool, right? Okay. Nice. All right. So, from here, we're going to go off. Um, let me check on time. Um, I can't remember when I got started. Let's try and implement um one one public API real fast. Let's let's let's ask Quad what's a good public API. Oh, I like dummy JSON. Tell me more about dummy JSON. And now it's going to tell us exactly about dem JSON because that's its job. What we're going to try and do is we're going to try and replace and in inside of our MCP where we list products, we're going to try and replace that with our dummy JSON. See how that works. So reviewing it here, it's done the search for me, which is great. Is a free fake REST API. The key features, no authentication required, rich realistic data, that's nice. available endpoints gets. Oh, looks like you can add one. Interesting. You can update one, too. Okay, so let's just list Let's Let's try and update our Git products. Um, this one right here. Could we update our MCP server to use this REST API? Let's see what it says. So, we're going to update the product interface to match the dummy JSON schema. This makes sense. And then we're going to replace the in-memory product with dummy JSON API calls in API.ts. And then we're going to test the updated API endpoints. I'm going to stop that because I don't really want to do that. Um, could we connect the MCP directly with the dummy JSON and bypass our API? The goal here that I'm trying to kind of allude to is that we have an API that we built oursel that is simple and controlled. And what we're going to use the dummy JSON API to you do is go to more of an uncontrolled environment and see how quickly we can convert that API into something that is MCPable so to speak. So there's the dummy JSON and you can see here that we are um Yep, that's perfect. We're going to add in this is perfect for our purposes because we're trying to move kind of quick. Yep. We don't need the base URL anymore. That's great as well. That's a good improvement. And if you can believe it, we are going to try and deploy this. Yep, that's good. and see if it'll just work because I think that'd be pretty cool if we could just get this these changes in, deploy it, see if it would just work. That'd be amazing. Okay, so now let's see. Perfect. The MCP server now connects directly to dummy JSON. Here's what I changed. Updated the execute tool function. Removed the base URL. Updated create products. Add Oh, products add nice. added support for limit and skip. Nice. Cleaned up the base URL. Your MCP server is now a proxy. This is a really solid definition of what an MCP server is inside of this context. MCP server is a proxy for a a REST API. A tool proxy. Uh one might even say testing the tools. You can now use the MCP server tools that will fetch the real data. Okay. To illustrate this point, let's get this deployed. MPM run deploy. Let's test it. What tools do you have? By the way, if you're curious as to what my setup is here, this is what I was referring to earlier. I'm using Cloud Code, but the VS Code extension, it's really nice. Um, I turned out turns out I like VS Code. Um, that's just a fact. I've tried to I've tried to get away from it, but I love it. Um, I can see you have MCP product management tools installed, right? And so this is not product management as in organ as in like startups. This is literally like management products, folks. Um, so let's try and list the products. Let's Can you because we deployed it, right? So we deployed the changes just immediately and now we're going to try and oneshot this. Can you use this? I would like to proceed. Thank you. And look at this. Boom. Just like that, we took a So, we started out with a REST API that we built just to kind of get us in a familiar environment. Took our MCP handler, converted it to work with it nicely, and then we switched over to a public data set with one that we don't have any control over, and it just worked. That's pretty magical. It's in Cloudflare. Let's see what else we can do. Can you can you get a specific product update and then get it again? I don't know, folks. I'm just playing with it now. Yes. Yes. Yes. So, we updated it here. It went through and then we got it back. Interesting. I successfully executed all three operations. It appears the update operation may have succeeded in a coordinated API response, but the underlying data source might be read only. That is true. It did pick up on that, which is even amazing in and of itself that it picked up on that. Um, pretty cool. Let's see. I think I'm actually going to I'm going to commit these changes. By the way, this repo is public. You can find it on uh this link here which I will post in chat if I can find chat. I can't seem to find chat. Oh, there it is. Awesome. Check it out there. For now, let's go back over to our slides real fast. Let me just grab this and we can start to look at some advanced topics and then wrap wrap this thing up. And I actually want to let's see pop over here. There we go. So kind of going beyond the basics of what we looked at, we we essentially established our MCP server as a MCP proxy to MCP REST proxy. Um and the advanced going back here advanced topics. This is essentially all the information that we didn't cover. Uh not all of the information. And I shouldn't say all, but some of the information we didn't cover, you you would naturally want to add in authentication into any sort of REST API. Um, and so one of the things that you can do here and is you can add in just straight up an API key to your MCP server. That one's pretty transparent. You can just set it regular secret put, no problem. Um, persistent storage, same thing. You may want to include a database um with with Cloudflare. Cloudflare has a excellent SQLite database D1. Check it out. Um, you can do that sort of thing too if you wanted to be able to select from the products and return those results. Easy enough. Um, rate limiting that's not super uh important to us. Caching also less important to us. But the best practices, let's let's let's see kind of what some of the principles that we we have uh we follow the best practices of REST API, right? We have clear resource naming um kind of a consistent we even saw that backed up by um our dummy data rest API and then the MCP tools. You'll notice though that the best practices are a little bit different. Um, with REST APIs, you do end up writing documentation. Yes, like every but you don't always end up writing documentation. It's not self documenting, right? MCP in and of itself is kind of self-documenting. Like the purpose of MCP is for these tools to be interpreted by an LLM. Therefore, you have to use some version of natural language. And we saw that in our MCP tools definition. And so we had descriptive tool names. We had rich input schemas. This is important too for natural language purposes. The LLM needs to discern do I have the inputs required to actually make this tool call. We had all that built in clear descriptions really important type validation and then some air messaging document and all fields. This is also huge. Um tool naming conventions what you want to use here and we this was referenced a little bit in the code. I did not highlight it at all, but um it's a clear verb plus a noun um or a specific action, obvious intent, descriptive. You can see that each one of these each one of these ones are kind of there. List products list products get product. It's a specific action, right? Bad names would be like products or fetch or do stuff API call. uh we don't you don't you don't end up the the difference between an LLM and a REST API is a REST API is essentially wanting the developer to kind of if there's no documentation the developer needs to be able to self-discover what the API does. That requires experience and you know it's it's fine. We've all kind of been through that doing the motions of trying to discover a REST API with an MCP. The LLM needs to know all of the information about the tools. Um, it needs to be self-documenting and that's the thing. You do stuff. There's that tweet that Justin referenced. Uh, these, you know, exposing just all the SQL calls from a database doesn't help the LLM. It's not helpful. Sorry. Schema best practices. Um, you can see here AI agents read descriptions make them helpful. Error handling best practices. The log errors return user friendly messages. This is where like you know the error messages are interesting because the LLM if you if the LLM is getting an error from the MCP it may be beyond its capabilities to discern how to fix it. Many times when I'm getting when I'm working with an MCP and I'm having issues the LM can't help me because it's a connection issue of some kind. You know I have to like kind of switch modes and describe how my configuration is with the NCP. And so the error messages kind of differ from the inputs fields in that they're not necessarily just for the LLMs. They're also for the end user of the LLM testing strategy. You can use curl requests. In my opinion, they don't work super well. Um I was using curl requests to kind of get this um MCP working and uh it was not it was not the best experience. I liked uh um some of the other ways to test in MCPS better. Um, corores issues are common challenges. Uh, large responses, another one. These are all things though that REST APIs end up having to deal with in one way or another. They're just pushing the limits. The thing is is that when you have like a get products rest API, it's um, you have an intended use case that you intend to use to develop. A lot of times when you make an API, it's you or your coworker who's going to be consuming that API when they implement it in like a front end. MCPs are a little different. The LLMs, we've talked about this a lot, they're non-deterministic. And so if the MCP can do one thing, the LLM will eventually do that one thing. So the air handling has to be kind of a little bit more buttoned up. And when I say air handling, I'm actually mean like the large responses, all that sort of stuff needs to be a little bit more buttoned up. Type safety um execute tool. You can see here um you want to run with some sort of validation as well. Makes sense. Um you can test locally. The best thing to do with test MCPS locally though is to um use uh is you use an agent with it um or the like MCP inspector sort of thing. Um beyond this project what you can do I've posted the link in chat you can take this and you can uh you can customize it. You can take this MCP and make it work with any sort of REST API. They are not complicated. These these things are not complicated to build. Um, MCP proxies, I think, is a proper name um for these these sorts of things. It's not uh it's not even a proper It's funny. I'm not even sure if MC MCP reminds me more of websocket than it does of REST. Just a thought. Um, you can wrap other APIs. We use the dummy JSON product. Uh, we can use GitHub, Stripe, whatever. Um, they're they're all interesting. Um, and then some rearch some resources. Um, all these slides are available inside of that repo that I posted of using slide dev and so you can see all the different resources that I have um here. Hono, by the way, is really cool. Check it out. Questions? Now it's time for the ominous voice to return. >> Hey, I'm back. Thank you very much, Garrison. >> How about you on time? >> Uh, you are you know what? Let's see. You are like maybe five minutes over, which is all good. We uh >> Oh, I'm so sorry. >> I think I was like 15, so you know. >> Uh all right, let me switch the view here. So that is better. Okay, so our first question here that I have for you is why choose Cloudflare workers over other platforms? Yes. Um okay, so this is a good question. I am obsessed with Cloudflare workers. I think they are an amazing concept. Um they have a actor model behind it called durable objects that you can also use. And so when you take a

Cloudflare worker and a durable object and put them together, you kind of get almost like a full server experience um just without that full server. And what that translates into is um you're no longer bound by time which is one of the main issues with the serverless platform is that you um you know a lambda for instance time for instance times out at 15 minutes um even uh versel fluid compute it times out at a certain point with um cloudflare workers and durable objects um you not only get all the benefits that cloudflare talks about with like edge and you know it's across 300 different regions you don't have to think about any of that stuff anymore but you also get the benefits of um being able to maintain like a persistent websocket connection um and not pay for it um because they have this hibernation feature that essentially allows you to the meter doesn't run when your websocket connection is hibernated.

Um and that means that like it uh with Cloudflare you typically don't pay for networking which is networking like ingress egress is one of the most expensive things to win with any of these sort of cloud platforms. Cloudflare, you don't end up paying for that. And so, um, I mean, it ends up being like a there's so much wiggle room on Cloudflare because you you end up saving so much money that it covers an abundance of sins if you were to like have like a lot of uh, you know, like a if you had like a million lambdas executed um, that would be a big bill. But if you had if they were running for 15 minutes, but if you executed a million Cloudflare workers for 15 minutes, like it would just be nothing.

>> That's crazy. And I personally am partial um because it's uh that's the home of of Nuxub. So that's I but I didn't know all these uh these other cool things. I've never really dug into it that much um because I use Netlify for a lot of things, but I've always wanted to kind of start moving over to to Cloudflare for more um interesting.

Um what what about in terms of like the MC MCP specifically? Why are you why host the MCP on on Cloud Cloudflare workers?

>> Yeah, so the MCP on Cloudflare um that was uh specifically because they handle all the routing for you and that sort of thing. So, it just kind of means that you get a global network for the MCP server. I know it sound it it's not a super big deal um when you're looking at like a platform like when you're looking at like a a live coding example like this. Um but when you get to a situation when you say the word proxy or gateway um which in this case we're essentially building the MCP proxy um you really don't want to put those things on places that charge you bandwidth >> u because they're inherently you what they're transferring. A proxy is transferring a variable like X. You don't know what it's going to transfer. Um and so in this case with putting it putting the MCP proxy on um Cloudflare, it means that you can kind of work with almost any API um and you don't have to worry about the experience of what's happening. Gives you a lot more flexibility. You can spoof a lot more of the requests in Cloudflare. Probably shouldn't say the word spoof, but you can.

>> So cool. All right. Thanks, man. Um next question we have How can you restrict which clients or agents are allowed to call sensitive tools on your MCP server?

>> Yeah, there are a few thoughts here. Um the first thought is you can actually and and this is like I like to work backwards from this this method. Okay. uh you can actually restrict your API the way that you always have. You don't have to change that. And so that means that you can keep the consistent like restriction level um that you would on your API and then just extend it to the MCP, right? And so that that's kind of an unsatisfying answer, but essentially what I'm getting at is you don't have to rewrite your whole API. Now, you will want to maybe add in some like like one of the things that Justin showed was the OOTH experience of Twitter, being able to hit like authorize and then have it have a kind of a beautiful experience there. You may want to add in something like that into your MCP. But realistically, what you're doing there is you're returning a URL to send back to the MCP and then opening it up. And so, functionally, when you look at restricting um sensitive tool calls, I would say that probably still want to do that on the rest RE rest API side. And then where you're thinking about authentication and how to handle that is typically going to be um essentially I would decouple the the concept of like restricting from the uh feature of authentication. um when you want to authorize somebody, you want that to be done in the API itself and the rest API. And then when you want to authenticate somebody, you want that probably to be an MCP concern. And that's realistically going to look more like an OOTH situation where you return a URL, which is not a complex concept.

>> Cool. Awesome. Uh so time for one more question here, I think. Thank you, Garrison, um for that. So the last one See, that one's a lot like the one we just answered. So, let me put this one up here. What where could be the first step to start from scratch of building your uh own MCP? What would you recommend for someone who's never touched it at all before?

>> Um, so you want to build your own MCP. Is that that that is the question, right?

>> Yep.

>> Yeah. Um the the the best way to start from scratch would be to do to do exactly what I I did, which is to build a REST API. Um just a little REST API with the products. It just returns JSON, just small and simple, something that you can fundamentally get your hands around and understand. And then I would say switch over to like a MCP.ts file and just start to try and make calls against that REST API with the MCP protocol. Um it is very simple. It is something that you can easily put into quad and kind of get it working with you. Um you can look at the recording, you can look at the GitHub repo and you'll understand that it's not rocket science. There there is like no magic in this.

>> Yeah. And and that's I mean that's kind of one of the reasons MCP has taken off too, right? Is it's it's really not hard to actually make one. Um so um Okay, cool. Um I I believe there's also uh one tutorial that I have gone through and and used to help learn is um on the official model context protocol website. It's.com or.io, I don't remember. But anyways, they have a a tutorial for creating a server, your own server. Um and it is a weather MCP. So it's like your classic let me just fetch the weather kind of example. It makes it very very easy to follow. Um, and over on our aid platform, uh, Justin has a a lesson where he goes through how to build an MCP, which is really nice as well. And one of the one of the things I would add is I think MCP server is like a bad name for these things because MCP server almost you almost think of it like, oh, so it's on like a different port. Um, it's like it it is genuinely I would it is more of an MCP proxy. um even when there's not a REST API involved and you're doing like I would say you're doing like remote procedure calls. So I still think of it um MCP server to me was like oh this sounds intimidating.

>> It sounds intimidating.

>> Yeah. I would say it's not intimidating. Anybody who thinks it's intimidating trust me just go build something with it and you'll you will discover there is no magic.

>> Absolutely. Absolutely. All right. Well thank you so very much for your time and expertise Garrison. Enjoyed having you on here sir. See you.

>> See you. Bye.