AWS MCP server | Serverless Office Hours

[music] [music] [music] Hello everybody. Good morning, good afternoon, good evening and maybe for the late nighters. Good night as well to everyone wherever you may be somewhere across our lovely world. Thanks for joining us live once again for the one and only serverless office hours. We are streaming on the AWS Twitch channel. So welcome if you're joining us from there and also via YouTube on the AWS events channel. Uh either channel is awesome. We're so happy uh that you're with us. My name is Julian. I'm a developer advocate for serless here at AWS. Mainly doing

serless, but a bit of other kind of stuff. And today we are talking MCP and AWS and getting your agent stuff to do more stuff. Isn't that a great intro? Uh no stuff because it is a lot. So I didn't want to just limit what we're talking about to lots of different things. Um so joining us are product manager extraordinaire which is third time lucky on serless office hours. So welcome back Prrenita. You've had an interesting and storied career across AWS doing various different kind of things obviously doing things with with MCP now. So for

for people who don't know the awesome Prrenita uh how have you landed up doing what you do today? Um I am just all over the place right now but I I work for developer tools organization. I I love developer tools. I used to be a developer for the longest time. So this is how I've worked on SAM in the past. I've wor I work right now on CDK and uh I'm also now working on AWS MCP server which is right in the heart of your developer environment and really really excited to be providing AWS as

you know a facade to AWS through the MCP. I think it's it's a great tool. Cool. Exit. Yeah. And it's this interesting progression. And uh I was talking to someone earlier this week who was saying, "Oh, should I be using uh CDK or should I be using SAM?" I was like, "Well, it doesn't really matter. There different ways you can doing it for it all." And then they just looked at me and said, "I don't need need to know either. I can just use AI and MCP to do it." [laughter] So interesting interesting thought. Yeah.

I mean, this is probably my first time on your show where I won't get that question because [laughter] because now the agents decide everything for us and we just have to make sure that they have our right the right interests at heart. Yeah. Yeah. Well, yeah. By as with all things AI, that's partly true that it can write the syntax for you, but yeah, I I would like to know what my CDK is doing since it's deploying infrastructure or my SAM or whatever. So, as with all coding and AI, um yeah, go nuts and things

could go wrong, understand a little bit, and it's going to help you as well. Certainly. Next up, uh Claudia, uh welcome to Service Office hours. You're in Amsterdam, so sort of European time zone, so we're representing more of the World. love to have software engineers on it. Uh tell us what you do at AWS and uh how you got involved in the AWS MCP server. [snorts] Um yeah, hi Julian. Hi folks. I'm uh I'm really glad to be here. Um so I've been at AWS close to six years now. Uh time kind of flies. Um

I'm a senior engineer um here working in the developer tools work focusing on developer tooling and in particular tooling specific to um to AI like pretty much making AWS easier to use by by agents and humans alike uh as well. Um, I've been in the MCP story uh for AWS since the beginning, right? since we launched the AWS API MCP last year around July if I recall correctly and um then we uh we also shipped at reinvent the uh remote AWS MCP server uh which um I'm here to talk about and I think it's a

really interesting and exciting product for humans and agents alike. Cool. Lovely. I love the I've been doing sort of MCP and AWS since the beginning and then I cast my mind back and I'm like well I think it came out when not Wednesday November two well November just over a year ago but actually sort of woke up in February. So it's really just only over a year uh a year going on with this MCP thing and that's got to be an incredible trajectory. Um, and I will Even say even as a tool that started as

a great idea, but loads of weird stuff that the way it's set up and everything and how it's just evolved over the past year with, you know, being able to do more streaming things, the more remote things and everything. So, yeah, what an incredible journey for a technology that just took the world by storm and we're a year on. It's a sort of like we always used to always do say with AWS uh when you said you worked here for six years as well as Clauddio and Prenita for a long time. Yeah, it seems like

dog years where it's for ages. AI, I think, just you know, is just accelerating it even more. Just the last year was like seven years long. So yeah, [laughter] exactly. So seven years times seven years. Anyway, exactly. But remember, we are also live and we'd love to find out where you are around the world. We have Reginaldo joining us via YouTube. Reginaldo 8597 from Brazil. That's very cool. I'm hoping to be able to get to Brazil later this year. Also loves CDK as well, which as well maybe. Hi from Spain. Ah, awesome to uh awesome

to hear from people from Spain. We've got Louise saying good morning. Uh we've got India uh Andrea Pradesh awesome thank you for joining us as well I think ah there was eerie edits as well from the beginning there's lots of stuff to this stuff when I was talking about the the stuff here um so eerie edits joins us regularly so that is great a template of Florida Monty's girl welcome as well from Ghana as well excellent so um yeah we're mostly represented I do appreciate well we do have people from India but rest it's very

late at night or super early in the morning uh yeah I'm sure people watch this and remember the recording is also available afterwards um So I suppose telling you Telling people now that the recording is available when you're not here but for people who do discover this um super game we've got more we've got Tampa Florida and also from Miami. So wow excellent well so awesome to have everybody. Uh so so where do we start? Maybe Prrenita just over to you. AWS MCP server. I know the industry has gone mad. I don't think you could

exist a year ago if you didn't have an MCP server. Um uh AWS has got loads. Some have evolved. Some have changed. So yeah, just sort of map us out the MCP landscape at AWS. Yeah, at first we we started with, you know, how can we provide a facade to AWS in a really quick way. Uh you know, people have struct uh natural language inputs and we provide them CLI commands that that work pretty well that are that are tested that are um run through certain analysis before we uh let the agents run them. And

then we went from there to you know how can we make this a remote managed endpoint where anyone can get the most upto-date AWS knowledge they can uh they can run it as a remote service. So you have observability you have the security that comes with that and you never have to deal with updating uh your MCP server that's on your machine to to make sure that you get access to the latest information. Um and now we are you know and and then we kind of built that out. We launched it in preview um o

over reinvent last Year and now as we are as the industry we're learning with the industry on how to use MCP servers when to use MCP servers and as as we are going through that progression now we are in a stage where we have access to all of our AWS service teams who are continuously shipping new features um and new services, how can we take not only the existing knowledge of AWS, but also the new ones that come up, put them together in a format that your agents understand and and get access to like the

latest best practices and uh and also perform complex multi-action steps because I as as we are progressing in our AI journey, we're also seeing people are letting agents do longer and longer actions, right? And so how how can we ensure that it is do you know following the best practices doing things in in the secure way with AWS where you can observe and monitor and even kill something if you if if if it's doing uh I don't know like agents you can only trust them so far. So uh as of now so you need to

have a a way to observe overall uh on uh what actions agents are taking and this is where we are right now in our MCP server journey as we're working towards GA or making it generally available to our customers. Excellent. So I I'm excited. So I get lots of questions myself as well. Seen I'm I'm the host. I get to I get to ask them as well to learn. you you had a a cool interesting comment where you said about uh you know things you've discovered about MCP across the journey or MCP servers we've had

before that have evolved what kind of things changed the way that you've approached MCP servers I'm asking that from a from a how this tool has evolved as well but then also other people who thinking about MCP um maybe they're not as up to date and you know thinking if they're going to provide or host MCP service or do that kind of thing how have things changed that's that that's uh how how's it evolved over time Yeah, I think the the fact that AW AWS has such a wide surface uh in there are what 14,000

APIs um it it has such a wide surface uh that we as the the AWS MCP server are trying to cover. One of the things that we've just we've we've been talking a lot about lately is how do we make it uh context efficient, right? and where h how it's it's not just making sure that the tool calls are correct, but they're also as minimized as possible so you're getting the the most accurate and the most efficient run of your uh of your query to the MCP. Um, and it it's interesting because we get to

lead the charge on how we're we're building these internally and I know Claudio is is kind of at the forefront of that because We're like, well, is it, you know, should we focus on cost? Should we focus on speed? And it's it's it's this constant balance between how the industry is moving and how things are over time getting cheaper, but also how models are getting more powerful. And then we we want to make sure that the MCP server keeps up with it as well. So um Clauddio, do you do you want to take that too?

Yeah. Um if I add if I could add some additional um learnings that we had through our journey. Um initially when we started u when AWS started the the MCP uh server uh journey it was um honestly a bit uh service specific right as in you put out the lambda MCP server or the Dynamob MCP server or IMCP server. Um and then what we learned is that it tend customers or users don't tend out to uh know in advance what they need from from AWS in terms of NTP server interactions, right? They either install everything

or they install a certain uh subset that's specific to their job and then they uh they always have to uh be mindful and be aware of new additions to the MCP server offering from from AWS. So this poses a couple of problems. One, the mental tax on users to know in advance what MCP servers they need. Either they install everything or a subset but always keeping uh uh looking out for new additions. And the Other one, it also poses attacks on the uh uh on the model itself, which as a result leads to um increased

token usage on on the on the user side, right? because when they need to install I think right now AWS has like 70 MCP servers for example each MCP server has a lot of tools like some tools or 20 tools or 50 tools well all those tools have tool descriptions those tool descriptions go into the context window of the model and effectively user would just blow up their context window before they can actually do any meaningful job uh using agents with AWS MCP servers. Um, that's a hard thing that that we learned and that was

one of the reasons why we created AWS MCP as a single unified general purpose MCP server that users should install first unless they know better and unless they have like specific requirements that are not met by uh this particular offering. Um we like Prenita suggested we have a lot of ideas on how we can get more context uh efficient with our tools using uh like tool description optimizations like making them as short as possible in a sense but still uh enough for agents to know when to select a tool. Um we're also exploring ideas around

how we can uh surface the MCP Server offering through uh concepts like progressive tool disclosure for example where um an agent would search and discover the right tools for the right job. So um yeah a lot of learnings that initially we we didn't know uh we didn't but I think now we know better and that's that's where we're heading. Yeah, that that I think maps the you know evolution of the industry of you know MCP servers also getting bigger and bigger and bigger half your context windows gone with the MCP server tools and descriptions. So,

so Claudia from a mental model of AWS MCP servers is this MCP server a wrapper around documentation wrapper around um the APIs but there are I know I think there's a you know there's a serverless MCP server there's a I think there's even a bedrock or a DSQL there are other MCP servers do those go into more detail or will ultimately all of them be absorbed into the AWS MCP server or what's the sort of lay of the land with how things are today and how you see the future Yeah. So, um I can go

back to what I mentioned earlier around AWS uh API MCP which we launched in in July last year. Um that was our first step right and that's was that was part of our uh learning journey. So um we started with covering for the first time the entire surface of AWS APIs and AWS API surface is huge. At that time there were 15 thou thousand APIs plus. I think now it's easily 16,000 or or maybe more. I I don't know. I can't keep count with the APIs that AWS is generally vending to to customers. So we

we started from this Foundational layer, right? If you have an MCP server that covers the entire breadth of AWS, um that's usually good enough for 80% of use cases. Um then we took this a step further like you mentioned documentation um and I'm not sure if um we've mentioned I don't think we we've did so there there's this documentation NTP server which uh is a local MCP server and that comes with its own uh uh taxing concerns like you have to install it and keep it up to date and have credentials for it. Um but

at the same time uh as with AWC API MCP we put out knowledge MCP. Um what this is is a remote unauthenticated MCP server that gives access to AI agents to the latest documentation um to best practices to uh information that uh is generally useful for agents to know how to do their job. Um and then we took that in and we merged that into AWS MCCP. So that was step two, right? AWS CCP now has access to all APIs but also has access to knowledge. And what that means is well you know models tend

to be very confident um about certain things and when they're not that confident and when they don't know how to uh do a certain step in a job or a certain job now they have access to search tools right Against the AWS knowledge against AWS vendor best practices which is always kept up to date so customers users don't need to install anything in particular uh so that step two in our journey. Then we took this a bit further, right? Um, we looked at all the offerings that AWS uh has in terms of MCP servers. And

what we noticed uh was another lesson that was a bit hard uh learned which is um well you have all these deterministic workflows, right? like someone has to go and write a bunch of uh bunch of code, Python or whatever the language the MCP server is implemented to enable an agent to perform some uh some operations, right? Um the problem with that approach is that well it might work for simple use cases but for more complex use cases uh there's a ton of additional information that you would have to bake in. for example, oh okay,

what are the best practices for a certain API, right? Or a certain service, right? Um or what about of APIs or services that would also need to come under this tool. And then there's also the maintenance tax where now service owner would need to always keep up to date with uh whatever AWS is releasing. So we looked at that and we thought that there should be a better way. Um and that's how we came up with the agent SOPs. Um so in short agent SOPs they're like standard operating procedures. Uh they're just natural language descriptions

of uh workflows that uh agents know how to follow. In our uh evaluations, in our testing, we noticed agents follow this pretty closely, right? It's not always 100%. It's because models are not deterministic by nature, but it's really good enough for most of the most of the use cases. So, that's the third the third pillar in WSMCP uh story. That that's super interesting because I like the evolution of the that the documentation server becomes a knowledge server because the documentation is you know and I've you know saw the tools before where you could search documentation

uh and you know great but the the the fact that you got the knowledge MCP server which is also best practices and I because anyone who's used AWS documentation super comprehensive super awesome but it's not easy to find stuff because it is so comprehensive and so those best practices are often spread around in different services if I using Dynamo and Lambda. I've got two sets of best practices. Yes, Prrenita. Not to mention, it's not opinionated. The documentation is not opinionated because we are just talking about what exists, how you can use it. But but what

agents need is the opinions as well and and and a way to encode those in are also, you know, SOPs. Yeah. So, and that that's what I love about the standard operating uh procedures where you know the best practices that we give to our customers and even our I know our professional services and heck I I do a talk at reinvent called best practices for serverless you know some of those things I know are you know are are sort of componentized and just at an LLM call. So I I think that's yeah super awesome. We

do have some comments that have come in. We are going to get to do some demos as well. So uh it's just been interesting to hear all about MCP and so and all the cool stuff that we're doing. So we will get there and I've lost my place. We do have some people. We have Chris from Johannesburg. I'm from South Africa originally. So hello Chris. Uh we have RM Fox from RM Rocks from North Carolina. Colorado represented as well. Uh we had some Mex more people from Mexico City as well. Uh so yeah two quick

questions. Uh the cost of doing this on AWS and then there was another one about deploying it as well. So for running MCPs do we need to deploy in some other service ECS lambda EKS or does AWS handle anything? Yeah, a how do we deploy this and then a cost thing and if that is part of the demo we you know we can also cover that there. Yeah, I I can take the deployment. So the interesting thing about AWS MCP is that it's managed by AWS. Uh you don't have to deploy anything. Um it has

a simple configuration that uh the user can can use to configure this in an MCP client uh like cloud code for example. Um so yeah is it's just managed which makes it very easy for users to to use it. Cool. Excellent. And and costwise uh do you pay to use it or uh there is no additional cost. It's just the tokens you use that you you pay the uh the provider anyway. It's it's it's nothing no additional cost for the MCP itself. So you're free to use the MCP server, but you're going to pay for

your token, whatever whatever MCP client you're using. And then obviously if you're deploying stuff and using it, uh, you know, that's obviously uh that's obviously done as well. Uh, I know Claudia, you had some stuff to show us as well. I always love going into the demos and that also sparks lots of questions. So um, do you want to uh let me just add your screen on? All right. Um, are you seeing uh my shell by the way? Yes, we can see your shell. Yeah. Okay. Awesome. Um, so I'm going to use Kira CLI for

for this demo. Um, let's see if everything works. All right. Okay. I have a bunch of MCP servers installed. Uh, let me just check where are we. So, everything seems to be working fine. Uh let me just clear this just like this. So just while you are there also just for people who don't know um Claudia is using Kirro CLI. So Kirro is sort of two parts of our um an Amazon provided agentic experience. One's in an IDE form and one's in a CLI form. Um but if you Are using you know C codeex claw

whatever all these kind of things all of the AI agents allow you to just plug MCP servers in a mostly similar configuration way. Um, so yeah, this isn't a Kira only thing. Kira is awesome, but uh and Kira is also loaded with lots of AWS specific stuff, but if you're using something else, this is also valid for you as well. So just to plunk that in. All right, so um we're at the several office hours and um I've heard of this thing called durable functions. I never used it, so I don't know what that is.

Uh but maybe it might make sense for my use case. Um I'm just going to ask my agent what are durable functions. Um now it's going to do uh or it depends because it's nondeterministic but it's going to do a really interesting thing u which is well I didn't actually specify [clears throat] on which cloud um the agent should look for. So it defaulted by default into Asia functions. I think this shows the importance of having up-to-date knowledge for agents because uh for example if you're not on the latest model or um you use an

agent and it's training window was you know like six months ago um then the agent might not actually know of the latest uh um the latest releases from from AWS um and It would make assumptions cuz Like I mentioned earlier, they tend to be extremely confident in in their own knowledge even though they're incorrect. So in this case, let me just nudge the agent a little bit that this is also now an AWS feature. And this is common. I mean there's so many and not even cloud providers across lots of services, especially in the JavaScript

ecosystem. You've got lots of things that are called similar things or called the same things and they're different. So good prompting. Be slightly more specific. Yeah. And Serons is quite right and a proof that the agent isn't biased which is I suppose a good thing. [laughter] Yeah. So um now I'm chatting with my agent right so I guided to to look for for AWS uh durable functions and it's actually popping up uh an AWS MCP specific tool um which is also part of knowledge uh by the way and that is search documentation. So search documentation

is a like it says a tool for agents to search documentations in AWS. Um it has a bunch of topics that um is able to to filter out based on what the agent needs at that time. Um like for example there there are also best practices and the SOPs that I mentioned earlier but in this case it only needed like the current awareness and general information. So I'm going to trust the tool in this case. So again that is also a security thing that you've got quite specific control over every tool it's going to call

um whether you want to trust it or not trust it. So you know that is also a nice little feature. Yeah. Yeah. Exactly. Um okay so well now it's actually coming up with some information. Um, so it's actually telling me that hey, this was GA late 2025. I'm not sure what model I'm using here and if that model had any prior knowledge of uh AWS Lambda durable functions but given Asure Functions was uh possibly more prominent in its training data set then it would have had a harder time in surfacing AWS specific information which is

where knowledge MCP and AWS MCP with knowledge actually helps. So it's giving me some information like uh key durable operations some some constraints uh which kind of to me reads a little bit like best practices that the orchestrator code must be deterministic operations should be on it important retry tries and can reexecute them. Uh like I mentioned I don't have expertise or experience in huntable functions at all. So, I'm just going to ask the agents. Uh, okay. So, let's see if it's going to come up with with something. Cool. Now, it's showing another tool and

that is the red documentation. Right. This one takes an URL. uh the agent is going to fill that in depending on uh on what it needs and uh then effectively it's going to go and surface that information and being back to to the agent and um now I have that information right as in what it means for a durable function to follow best practices like writing deterministic code and designing for potency uh and all that. So that's really cool because now I can actually go and uh build a durable function for my particular use case,

right? Um so it's also useful for learning, right? Especially when you don't know what uh uh what you want to research or search for. Um but an agent would know how to how to do that or how to craft such such a query. So this kind of shows the knowledge part, right? Um like I mentioned AWS MCP covers the uh full breadth of um AWS APIs all 15,000 APIs. Um so it has access to knowledge and APIs as well. Um it for for API specifically it uses um well actually I didn't quite go into that

into the configuration but I think it's worth calling out. Um in this uh current uh iteration it uses your local credentials in whatever credential chain you have set up locally environment variables or uh yeah basically the the credential chain that you would usually Use for AWS CLI and uses those credentials to sign requests to the MCP server. Um and then on the MCP server side we do uh we follow the the best practices on uh leveraging those uh appropriately. So let let's just see some how uh authenticated API access would look like. Um I'm not

sure what resources I have in Yeah, this also does line into 29 said uh you're talking about or does the MCP server run under a specific role or or anything? So yeah, this is this is good to know. Anyway, the MCP server is remote. You know, it's running in AWS. So you're not running anything in AWS. Everything's coming locally onto your workstation or laptop and running locally with whatever credentials you are working with locally. see as as as Claudia is showing. [snorts] Um yeah uh yeah actually this would run uh remotely right. Um oh well

the uh there that that's an interesting thing in the demo when you have multiple tools doing the same thing the model tends to not know which one to use. So I'm just going to nudge it a little bit to leverage call AWS instead. Okay. So uh again similar story as with knowledge just going to trust this for now. Um so like I mentioned um Everything runs uh remotely. Um it's just the credentials that are local. Um actually the reason for that is the uh the MCP spec, right? The MCP spec right now doesn't have an

authentication story around or that supports AWS authentication mechanism which is s4 um the MCP spec is only o based um for us to get AWS MCP out we had to somehow bridge the gap between what the MCP spec requires and what uh AWS requires and that came through the MCP proxy. So we released this MCP proxy which uh bridges the gap. It's acting as a uh local process that takes your credentials um signs those uh assigns the requests to the remote NTP server using those credentials and then and then just forwards the the requests appropriately.

Um so that's uh that's a uh bridging the gap. Um we are uh working on eventually supporting oath uh as well so that this would be MCP uh native like the authentication would be MCP native at at that point. Okay. And Claudia just uh your just to let you know your light has gone off or something and you look uh quite mysterious and ghostlike uh which is Very Kira uh Kira on brand. So yeah, if you do have a light that's on we'd love to see you slightly more clearly if that is possible. But I

don't know what happened with unless it's your webcam or or light went off or something. But um yeah, it's just the the light. I'm going to stop my camera for a bit. Yeah, go for it and stick it on. It's the dark mode, Julian. Yeah, I like it. I like it. Proper developer. Proper developer. Skirons is asking, is there a call to show your costs and token consumptions? Works only for current uh for current session. As you can see there, it's showing the credits and 29% is actually the context window, the the not context window,

the context size that is being used in the in the current session. So if that doesn't answer your question, uh let me know. And of course, we are in dark mode. Thanks, Gons. Okay. [snorts] Excellent. Is it better now? Yes. Perfect. Perfect. Perfect. Um all right. So it wasn't able to find anything but like I mentioned this command actually run remotely which is quite interesting for a bunch of use cases. Um for example let's say you're an organization and maybe you want to enforce a little bit how um the users in the in the organization

would interact with AWS using agents. So by the fact that uh AWS provides this managed AWS MCP server that also means that organizations can now have governance in place and auditability of what agents Did um and metrics to understand how uh um what an agent did and how it's performing uh in in general as well as to just deny certain functionalities in uh in the MCP server that the users in the organization shouldn't shouldn't use. Um which is an advantage from running local CLI commands because then an organization would not be able to uh do

such such things. So Claudia just just to reiterate these CLI commands are not actually running locally with your local user profile. that is actually what is it running uh in a sandbox in AWS linked to whatever profile you connect it to? I'm probably confusing myself, but yeah, just uh if if you can walk me through the the local remote story again where where this is actually running. Yeah. [snorts] Yeah, you're you're right. This is actually running remote in a sandbox that is um so it's isolated to the MCP session that I have in here, which

also means it's tenant isolated. So we have sandboxes for every account and for every session that uh that they create. Um and um the local component it's just that MCP proxy that sits in front of uh uh of the remote URL, right? Um I I can show that configuration a bit Later. I I need to uh get out of the terminal for for that. But uh it's just that local component that uh uses the credentials for requesting. Ah, excellent. I did not know that. I thought it was I knew there was some proxying going on,

but I I hadn't quite figured that out. Excellent. All right. Um, so let me if there are not any other questions from the audience. Um, let me see if I can go through the through the actual demo. Like this was not the actual demo. Um, not sure if I have the if I have the utterance for for it, which would be a shame. Um, so let let me just confirm what SOPs do I have. Okay. So, let's see what the agent is going to come up with. Um, and potentially can come up with uh with

the one that that I want for for this demo. Um, so like I mentioned, SOPs, they're just na natural language workflows, right? uh they at least the ones that AWS vends um they follow best practices they have uh a lot of uh institutional knowledge baked in in terms of how you operate with certain services and how you orchestrate certain things. Um they can be pretty verbose as well. Um, and uh, the really interesting thing about them is that they're also Kind of easy to maintain. Um, especially in an agentic workflow where you can ask agents

to look at an SOP and then figure out where an agent without prior knowledge would stumble, right? which also kind of creates like a virtuous loop where you use agents to create and uh amend and uh change SOPs that then are also being used by uh agents to actually do the job that uh um that the user is is intending. Um, okay. So, I have a bunch of SOPs in here. Um, and functions. Maybe I'm not seeing it. I did see one for durable functions. Yeah. Um, is it it actually returned? Ah, there build it's

under compute. Build lambda durable function under compute. There we go. Oh, nice. Yeah, that that was it. So I for the purpose of this demo, I created a SOP that's specific to Lambda durable functions. This was also useful for me to know what Lambda durable function is. Uh so I can talk a little bit more about that. Um so like it mentions here right it it's for building and deploying a durable function. It has everything needed to set up. uh for example I wouldn't uh or it would take me a lot more time to do

this by hand. So creating an IM ro and then uh installing the durable execution SDK and defining all the steps. Um so let's see. Yeah. Okay. So let's see what the agent is going to come up with. Um so there's there's another tool. Um like I mentioned we're trying to be as much as possible context efficient and we have a lot of stories uh in our journey on on getting uh to uh to a lot better efficiency. So we we have this tool called retrieve agent SOP which takes an SOP because SOPs tend to be

very large as well. Uh so you can't really put this into the context window like in tool descriptions. So you need like search capabilities uh around those and um the cool thing about SOPs is that they're like functions, right? So um you can uh create them with uh parameters like in this case it's asking me for a function name or uh a region or whatever is needed for the SP at hand. Um so in this case the agent really wants to know this information so that it can go and parameterize the the SOP. Um this

case let me go with some defaults. Okay let's see if that's enough. Okay. I like the proper vibe coding approach of Yeah, coffee. You know what coffee you're ordering is. Do it. Keep doing it. Keep doing it. Okay. Hopefully my credentials are still working. Um, so now it's going to start and do a bunch of calls. So it's going to go through call AWS. Um and yeah, it's going to take a little bit of time. So now it's a good time for uh for questions. Um where otherwise I can show the the SOP while this

is happening in parallel. Well, so a question I have is this is obviously you know using the AWS CLI to go and you know create a role and do all these kind of things. Can you sort of combine an SAP and you say well I actually want this also done in CDK or I want this done in SAM and then it'll have sort of the best of both worlds. I mean you did a super simple prompt so you know that makes sense that it's just going to you know build a durable function based on the

CLI but what sort of other approaches um could customers use? Yeah so that's a really uh interesting question. Um so well from a tooling perspective and from an interaction perspective the AWS MCP server by the virtue of being a remote MCP server uh only has access to uh let's say remote tools as in you could see APIs as remote tools right um but for example if you would have something that's local um maybe SAM or maybe CDK um but local to your machine but not local to the remote MCP server then it's not going to

be able to leverage such uh such tools right because uh it's just a remote Endpoint and doesn't actually have access to your local file system um and by the way um there are some APIs that are disabled right now in the remote MCP server because they're exactly what I'm mentioning APIs that require access to a local file system to do such certain things. Um we're uh solving that problem for GA. So for GA we will have like 100% API coverage. Um to answer your question concretely though uh I I thought that was a good uh

context to have. We do actually have SOPs. SOPs are not limited to what the NCP server provides. Um you can bake in all sort of information in there. And then uh the interesting point is that the agent that's consuming the MCP server is going to run those tools that the author of the SOP uh defines in the SOP itself. It's going to run them locally to the agent. So um for example, we have the uh the deploy um SOPs where you a user can take uh a web app and deploy to AWS. Um, and these

uses CDK. Uh, they might be using other uh local tools that I I I don't know these in in detail, but they're definitely using CDK. I'm not sure if they use SAM or anything on those lines. Um, so nothing prevents uh SOPs having access to local tools for in that sense. Excellent. So yeah. So, so would there be sort of other SD um CDK a CDK MCP server for example that you could also Because I'm thinking of a world where you want this and you I think that's where you started saying this is a generic

all of AWS MCP tool um but you know there may be some other MCP tools that you want for um to being able to dive deeper into things like or I suppose specifically things that you want to do locally uh you know things like CDK and that kind of thing. Yeah, print that's that's right. Yeah, we are we are looking at the existing MCP servers that are locally available today and and and figuring out how can we bring in their capabilities as SOPs or tools whatever makes sense uh into into the remote AWS MCP server

so people can get the benefit of all this knowledge that we put put out there in with one endpoint. Yeah. And uh for the CDK and and the IAMCP server especially, this is going to look like SOPs as Clauddio mentioned. Okay. And then just on the SOPs, Clauddio mentioned, I know he's the dev on this, but he said, "Oh, I just set up an MCP. I set up an SOP for durable functions. Uh is that one that's that's existing or or can people create their own custom SOPs or is just Claudia because he's so good,

he can just go, you know what, I'm going to do a durable functions one that's available for everyone?" Yeah. So we are working with all of the service teams on creating these SOPs and vending them as the official SOPs from AWS. But we also I also talked to customers that you one customer would would like convert their runbooks into SOPs and and run them uh as within their MCP server. So this is also happening today. It's it's a pretty easy format. Anyone can build I have built an SOP for product management. So um anyone can

build it. It's natural language. Um and as long as you can kind of bring in the best you can you you can encode the best practices that you want to wanted to follow. Okay. Yeah. Yeah definitely makes sense because I can see the organizations having you know this is all about context and not wasting context and being as specific to your use case and ultimately this is all text. So if your company had uh uh you know some some SAP of even this is the front end stack I use the backend stack you know a

preference do I want to use CDK or SAM uh you know what what services do I want to use because you know you could even say deploy this website to AWS you know which way so I can definitely see a combination of using the AWS prescriptive guidance and then having some additional stuff for the stuff that you want to do and opinions y so yeah I mean just looking at the tools flicking past on the screen I mean, when you're doing CI tools, you're having to write AWS Lambda invoke and ads Lambda get rid of

all this kind of stuff. This is where AI is awesome to be able to call these tools and just just do it for you. Yeah. Um, I think while this is going because it's actually doing a lot, I just want to share how an SOP looks like. So, c can you see my ID by the way? Yes, we can. If if you zoom in one more, then that'll help uh us older people with old eyes. Let me try that. Um I'm not sure how um Yeah that's good. I mean basically I mean for people who

can't see it is an SOP. It's got some parameters. It's got I mean it's just it's a oh that's even good. So yeah a whole bunch of text and everything um as an instruction. Yeah. Yeah. Maybe the markdown view works better. So um like I mentioned you define the parameters um that the SOP should should receive. Um it follows the RFC 2,119 if I'm not mistaken for a number around that which is basically the must should not uh verbage. Um and we discovered that actually agents are really good at following the uh these type of

u uh instructions and um then it's just a step by step. So imagine you're um I'm going to speak from an AWS perspective. If you're an AWS service team, uh rather than writing a bunch of code that then you have to maintain and always keep up to date uh and test and and all that, um you can just write an SOP, right? And it's very detailed at every step. We have uh instructions on uh what to do or what should be the next uh uh the next item. Um so yeah uh that's how an SOP

is is structured which is um not very distinct than uh uh than Skills as well which is also a new uh or rather not new it's also like an industry uh approach. So yeah this is basically what what an SOP is and how it looks like. Okay. And then this so this SAP is a markdown I mean all AI context is pretty much push you know shunting in markdown files at various stages on the journey um to be able to get the the LLM to do things. So, so this um durable functions, so that's a

markdown file, but you I mean it's not locally. This is being pulled down remotely and then sent to the LLM with this is these are the great instructions for using durable functions and if you're using lambda, if you are doing other kind of things, you know, or API gateway for example, you know, there'd be an SAP and yeah, I mean even looking at the I love the you know, it must and it must not. I mean these are the things that the documentation has but it's you know it's not the simplest way in the documentation

to know whether it's opinionated as Brenita was saying before this opinionated of hey it must have this mustn't have this and uh also that's going to reduce your context because I I you know when I'm building with AI coding agents and it builds something and then goes back and goes ah that AI call didn't exist or that uh you know hasn't got quite the parameters and it just loops and loops around eventually it does get there but that's annoying you know if you this SOP looks great to be able to just at least have instructions

up front. [snorts] Yeah. Um so it kind of finished. So it it actually created the um the durable function for me. Um it's uh try it out. It it's testing. It seems like it's it's actually working. Um but yeah, that's not actually what what I want. Maybe I also want some front end uh to to try it out. So now I asked the agent yeah just just go for it. Um so let's see how how that is going to look like. Um yeah so yeah in short this is this is a way through which we

think uh agents would be able to get access to latest information and also orchestrate API calls and additional tools not just API calls like uh like I mentioned uh CDK and uh uh and whatnot. Um, all right. Yeah, loads. I mean, even it created a Dynamo DB table even though you're working in durable functions. It said, well, actually, we want to use Dynamob DB to be able to persist things and, you know, created that on the back end and everything as well. So, yeah, it's sort of stretching in a good way going outside its lane

to, you know, create something properly and and you can control that in the SOP. You you can tell it how creative to be. Yeah. And I think also I mean because you're using Kira and I know you're using Kira CLI uh but the Kira IDE you know it's real claim to fame is using spectrum development where you uh take an existing codebase or a new codebase and you I I like to do it actually via the vibe part to iterate over you know what would my application want to do. Claudia has done it, you know,

quick vibe just writes a single command, off you can go. But we know in a in a, you know, more production application, you'd want to put a lot more thought and care and attention into creating that spec. And so I can see um using a vibe mode to be able to iterate over what my application wants to be, uh what uh what parameters I want, one front end stack, backend stack, the kind of things I'm thinking of, you know, performance profile, all the kind of things a a product manager and a designer or even an

engineer or an architect would come uh come come with that. And then once that specification is created, you know, linking up with this MCP tool to actually make that live in a way to actually go and do that would be super good. So you could use the MCP service in the beginning to get information, you know, tell me how Dynamo DB works the, you know, write capacity units so I can model some costing. Uh, you know, tell me about Lambda durable functions. Would this be a good use case for a, you know, multi-step workflow, do

all that kind of things. And then you sort of build up your spec and then sort of back to the MCP server to actually go run the class and deploy things. This is how my my role is changing now Julian where we are the product manager is like kind of looking at or accessing all of the documentation and all of the the the AWS concepts to put together a spec file to to define what we want to build. It's almost like a pre-version of a tech design dock and then then that is then taken by

the team and then they they kind of run skills or SOPs to make sure that they're covering the deeper technical concepts like threat or making sure the right uh test coverage is there and stuff like that. Yeah. [snorts] No, no, that's an interesting well is it's a great approach and I think people are more evolved in their AI coding journey are getting way more uh way more better code and way more better applications by uh by using that as well. But it's not I I would also say it's not just the the plan mode because

some other tools use plan mode or just the spectrum of development. So I do find if you've got a uh I it's far better to really iterate over that spec and spend I mean I I spent you know even a day or two going over that spec thinking about it changing my ideas because ultimately spitting out the application in the end is actually quite quick with code now and so also you can spend a day or two just doing iterations of ideas and uh you know proof of concepts and that kind of thing and then

afterwards going this is what what I learned about what I wanted my app to be. Okay, now let's go and build a build a build a corporate app. Oh yeah, you were going to say something. Yeah, that's um yeah, that's actually interesting because it's not just Pranita's role that is changing but also how we approach engineering as well. Um like you mentioned from uh specd driven uh perspective um where like for example in in the past we used to write like detailed uh designs for new features and capabilities. We also do that but now we

leverage AI as well to create and iterate through uh through the specs and then as uh engineering team we review The spec and then we figure out uh is this what what we want right does it capture all the requirements the functional and the nonfunctional requirements and um it's definitely changing um on engineering as well not not just uh product so leverage AI for for everything. Excellent. Uh we did uh we we've got someone from United Kingdom who's joined. That's my home. So thank you as well. Uh back to original in Brazil. Great question which

I've been you know dying to ask from the beginning. How to prevent destructible actions like destroying the the stack recreating you know does MCP have a built-in solution or must be used something like AWS config. What is the story basically the meta story of you know people who worried I've got access to my AWS thing. I I wanted to do some deployment kind of stuff. Uh I wanted to read things of course uh how can I be safe and protected and I mean you know we say this as Amazon and we say this with AWS.

I mean Amazon has had a a recent issue where you know this same thing happened the AI agent and the human were working together and the AI got a bit a little bit um overexited let's say and the human didn't catch that as well. How should people think about that or protect themselves against that? Yeah, I mean uh we we think of the access model something like the AWS CLI or or SDK. If you have permissions to do actions through AWS CLI, then you can do them through the MCP as well. So really your authorization

happens on the service level and and through how you've defined authorization does not change for MCP. This the same rules apply. the same things will be honored uh and you need to lock down access on specific actions for specific users. So this still remains true in fact becomes even more important in this world. Um about like specific destructive actions itself like the yeah we I think we're still considering what that looks like uh on an MCP layer. However, we're also cognizant of the fact that if we only build it for MCP, that does not solve

it for all AI use. So, so which is why we kind of rely on IM being that singular uh source of truth when it comes to O. Yeah. No, I think that's going to be super interesting to try and work out how and it's not this isn't an AWS thing. It's, you know, just working with agents, how to protect, you know, is it SCPs that you do in your organization? is a different accounts where you you know create something in a in a testdev account and you you know because obviously in a production account maybe

you only want things to go through uh you only want things to go through um your CSC pipeline anyway. Uh so you know and then what guardrails can you do uh to be able to protect against that. So yeah it's it's mindboggling but it is super interesting how we uh because the agents are super clever and they know about every API action because that's what you want them to know about. So they they can go and deploy everything. that's working out how to how to keep them safe. Yeah, I just I just shared um a

a blog post on this topic and you'll see a lot More coming up from AWS on guidance on you know how how to make uh a aentic access more secure. Okay, excellent. So that's a good one. Yeah, that's one blog post. And then uh there is also another blog post which is the the docs page on what is the MCP server and somebody earlier also asked a question which we were silly not to do is what is MCP. So hopefully by the end of it you do understand but it does stand for model context protocol.

It's a way for your a it's a way for your local AI agents to be able to interact with uh AWS. Um Claudia that looks awesome. I can't believe you got a CloudFront distribution up with a whole coffee shop workflow. Um, working behind the scenes uh with with orders and a durable functions process. That looks amazing. So, great job to get you durable functions with knowing very little about it. Well, you do know about it now, but yeah, that that is awesome. Wow. Uh, Claudia, I'm I'm super super glad that you got to the end

of it and it all worked before before the end and was purely vibe coded. So, I love it. [snorts] Prenito, Claudia, thanks so much for joining us on Service Office hours. What a pleasure to go through the MCP server. Um people can contact you. Your your information is in the show notes. Um I think also, you know, happy to reach out to get some feedback before things are going. G. Uh yeah, we'll be back same time, same place next week for more service. Thank you very much for joining. Goodbye everybody. Thank you very much for

having us. Bye. Thank you. [music] [music] [music]