How AWS Bedrock Is Shaping Model Context Protocol  🔗 **Source:** [How AWS Bedrock Is Shaping Model Context Protocol](https://share.snipd.com/episode/2303778a-a4ee-4214-8770-d889053415dc) ## Highlights - **Maintainers' Diversity Drives Slow Consensus** - MCP maintainers bring diverse priorities that prevent groupthink and create many competing ideas. - Luca Chang described long maintainer meetings where presenters debate features like sessions, transports, and skills but often leave without final decisions. Transcript: Luca Chang I mean like, well, at this point we have maintainers with diverse enough interest that like there are just like so many topics to cover. We couldn't even fit it all until all inside of like that one meeting on Monday. Like we had a whole bit about like skills, skills over MCP, a lot of stuff about the planned changes for the June specification, the changes to sessions, to the remote transports, and All that. Yeah. A lot of these meetings come down to whoever's leading the effort. They give a short little presentation about it, and we all debate and discuss all the finer points about it. And then hopefully we come to a conclusion. ([Time 0:01:28](https://share.snipd.com/snip/12ad3966-deb0-4980-84f4-a1870e621828)) - **Transport And Auth Fixes Unlocked Enterprise Adoption** - Rapid enterprise adoption followed key protocol fixes like OAuth-based authorization and Streamable HTTP transport adjustments. - Luca explained the switch from HTTP+SSE to Streamable HTTP and a static-JSON workaround enabled Bedrock to scale MCP servers. Transcript: Luca Chang In terms of like just where it got enterprise adoption in general, that actually like didn't take very long. I think like, you know, from 2024, when it was like initially announced to when platforms started integrating with it, that was only, like, a few months. It seemed pretty quick. Yeah. Yeah. It was in March 2025, I think, that, like, that was when MCP first got its, like, initial authorization specification that built on top of OAuth. And that was when you started seeing all these, like, integrations with Asana and so forth. Sort of first party things that were officially mediated with Cloud.ai initially. I would say that was the initial tipping point. I see. After that, other big enterprises, AWS started looking at it a lot more and seeing the potential of it. But, you know, when we started thinking about how we would like start deploying these things, it got a little tricky with the remote transport at the time. The remote transport at the time was called HTTP plus SSE. It's a bit of a confusing name, especially the current one is streamable HTTP. The naming is, yeah. But we realized pretty quickly that it would require scaling our fleet in ways that would require things like sticky sessions that are, you know, feasible, but not like the cheapest Option to implement. Alex Williams Which, given rising token costs for better models, matters. I mean, price does have a part to play. Yeah, definitely, definitely. Luca Chang But yeah, in the specification release after that, that was when Streamable HUTV released. That's like the current transport model. And that is where there was this little workaround where technically servers could return to static JSON responses. They didn't have to return a bidirectional stream system. That meant that we could start deploying them at scale a lot more easily. But it also meant that we would be doing so by compromising on some of MCT's features. But yeah, that is like the status quo of things. ([Time 0:05:45](https://share.snipd.com/snip/4eb8c02b-4f50-475d-a7c7-6ade1331a3ce)) - **Use Tasks To Avoid Model Polling** - Use Tasks in MCP for long-running operations instead of letting models poll repeatedly. - Luca advised collapsing create/get-result polling into a single job tool to avoid hallucinated job IDs and wasted token usage from model-driven polling. Transcript: Luca Chang Yeah. Tasks are sort of MCP's answer to like long running operations. And what we mean by that is more specifically operations where you might make a request, but it doesn't come back right away. You actually want to like check on its status multiple times. Alex Williams Is it because there's computational work going on or something that it takes longer to query a database, for example, to get that information back? Luca Chang It could be either. I mean, it's more about the amount of time it takes and not necessarily the work that's going on under the hood. Okay. Yeah, those are things that map very neatly to things that we already used a lot in AWS, like AWS step functions, for example, where, you know, you would create a job, you would pull on The job, and eventually you get the job's result. Maybe it points to like an S3 object or something. But like, yeah, when we tried to start like mapping those to MCP, to tool calls, we found that the only way to do that was to like expose that pulling to the model itself. Alex Williams Yeah. So you need to have a mediation layer or an orchestrator to kind of solve that problem for you. Luca Chang Well, yes. Exposing the pulling to the model itself wasn't inherently the problem. It was the unreliability that we saw in the model polling. Oh, interesting. How unreliable was it? Well, there were two specific failure modes that we saw. One, it was the case a lot more often at the time, not so much now. The thing that's still common now, I'll get to. The initial problem we saw was that models would frequently hallucinate things like job IDs. They see a create job thing, a get job status, a get job result thing, and they would just see the get job result and be like, oh, let me just stick an ID in there. And then they would call it and say, oh, well, nothing happened. This tool isn't useful for me. That was one thing that we thought very interesting. The second thing was just, you know, model pulling is at the discretion of the model. What that means is that a lot of models give up after a while. Yeah. Alex Williams We've all seen that in our day-to life. Yes. Yeah. Luca Chang I mean, you can see it in coding agents. If you give a coding agent a long enough task, at some point it'll say like, oh, well, we've done enough of this. Let's stop for now and come back to it later. Alex Williams Funny, I actually ran into a different problem. I ran into you're out of capacity, come back in five hours before I ran into that problem. I can see on the horizon, eventually get in there. Luca Chang Yeah, yeah. Alex Williams Once I have your token budget. Luca Chang Yes. Well, my token budget is funded by my employer. ([Time 0:08:37](https://share.snipd.com/snip/d4bdfb83-c3f1-44d0-aa0c-ada93e5c6504)) - **Require User Approval With Elicitations** - Use Elicitations to require explicit user approval for destructive or sensitive agent actions. - Luca described elicitation as a protocol-level prompt that forces a user to press a big red button before an agent executes a dangerous tool. Transcript: Luca Chang Well, again, we were looking at the use cases that we can map to MCP and saw a lot of cases where we might want to give agents access to destructive actions, things like, you know, tearing Down a database, say. But, like, that is something that we don't want to just, like, blindly give to an agent. We want some way to say, oh, well, you know, you can do this, but it requires explicit user approval. The problem there is that the way that user approval is handled is not like uniform across the diverse range of client applications today. Like the way Cloud Desktop does it, the way that Kuro CLI does it, the way VS Code does it, those are all slightly different. Alex Williams Which is annoying, by the way, if I can just say. Luca Chang Yeah, it is. But yeah, so we introduced elicitation as a way to say that, okay, some interactions actually do require user interaction. They don't go through the model. And through that, we can say, oh, okay, you have this destructive action. We'll send an elicitation that forces the user to press a big red button before they actually do the thing that the agent wants to do. ([Time 0:11:18](https://share.snipd.com/snip/487d2ad6-6d64-41ca-93f1-1b218e56a5b3)) - **Polling Burns Tokens Regardless Of Hallucinations** - Even if hallucinations decline, model-driven polling wastes tokens and should be handled by clients. - Luca emphasized that frequent polling burns low-value tokens and clients should wake the model when a job completes. Transcript: Luca Chang Not at all. Because the other consequence of model-driven polling besides hallucination is that every time it pulls, that's tokens it's burning. Those are very low value tokens that it's burning because it's burning tokens just to query a thing for, is it done yet? That's something that we think should be the responsibility of the client or application above it so that it can just wake up the model when it's done. It doesn't need to burn your tokens on something that's trivial. Alex Williams No one has compute, y'all. Well, I guess you do technically, but I mean, like everyone's hunting for more of it. So we're trying to be token frugal, if you help. So one thing that I learned a lot about was that a problem with MCP that people talk about or have talked about is context float and how calling lots of tools brings in all these tokens and You end up just burning through a lot of compute for no reason. Does the tasks addition to MCP resolve any of that tension that people have? Luca Chang Only a little. Not really. ([Time 0:13:15](https://share.snipd.com/snip/0de4222b-71ac-4793-adc6-2e07e005ad44)) - **AWS Contributes Based On Real Customer Gaps** - AWS contributes to MCP when real customer use cases reveal protocol gaps rather than for speed. - Luca said AWS explores customer mappings, then proposes protocol changes like skills when clear needs arise. Transcript: Luca Chang Well, it's a little hard to say. Right now, I think the thing that we are most interested in, like the protocol itself, is the skills of our MCP work. And that is something that we expect to see a lot more movement on in the next couple of weeks. But, you know, I think in general, AWS, we don't exactly like look to make contributions as quickly as possible. The contributions sort of fall out of our customer use cases that we explore. Once we explore a use case and see that there is like some gap in the protocol itself, that's when we say, oh, there might be something here that we can give back to the community. ([Time 0:15:05](https://share.snipd.com/snip/5fcd7a53-2bb1-4599-96d7-b5dcc31863bb)) - **Ground-Level Demand Comes From Many SaaS Integrations** - Most MCP demand comes from engineers who want connectors for the many SaaS apps they use daily. - Luca observed internal channels full of requests for MCP servers for dozens of SaaS products teams depend on. Transcript: Luca Chang Honestly, the most demand that we see is basically from people on the ground. Just like everyone in their day-to work uses like a dozen SaaS products. Any SaaS product that like does not have an MCP integration, people are in our internal channels like asking like, hey, does anyone have something? And on top of that, like it's a dozen SaaS products. So everyone who picks up an agent for the first time wants MCP servers for all those things. ([Time 0:17:27](https://share.snipd.com/snip/3b952055-8c12-4678-91c2-c2fa3a2e9536)) - **Design MCP Servers For Universal Interoperability** - Avoid building MCP servers tied to a single agent to preserve interoperability. - Luca recommended designing servers for MCP as a universal connector so any agent can plug in without agent-specific tweaks. Transcript: Luca Chang Well, because MCP is designed to be the universal connector. Right, the USB-C. Alex Williams Yeah. Luca Chang Any agent, you can plug in the same MCP server and it works uniformly. One thing that I've started seeing, mostly on the skill side, actually, and I'm a little concerned that we might start seeing it in MCP as well, is cases where, say, you write a skill, But it doesn't work super well. And so you tweak it, but you tweak it in ways that reference concepts that are specific to like one agent or another. That is something that I'm a little concerned about people starting to look at in MCP as well. Alex Williams And we talk about one agent in particular are you referring to like a vendor specific agent like a sierra customer support agent or um a salesforce crm agent or more like one type of agent Luca Chang That would be not tied to a single corporation i mean like specific agents like you know uh i see a lot of skills that are like written for like quad code for example uh and they ref they tools By name that specifically quad code has. Alex Williams Right. Which codecs won't have or kilocode or et cetera. Luca Chang Or if they have them, they'll be named different things. Alex Williams How do you push back against people doing that when at base we're talking about open source software and people kind of do what they want? Luca Chang I think really the way we do that is just by reinforcing that MCP is supposed to be universal. It was not designed for any particular agent from the outset. And we don't want people building servers that are only for one agent. We want them to build for MCP the protocol. ([Time 0:18:39](https://share.snipd.com/snip/73c5472d-3ce9-4c53-9b67-6bf709f01ee0)) - **MCP Enables Controlled Access To Internal Data** - Enterprises primarily use MCP to safely connect agents to internal data sources behind auth. - Luca noted MCP servers can expose a discrete set of tools so agents access search/wiki functions without broad auth to internal services. Transcript: Luca Chang I would say hooking up agents to internal data sources. Yeah, like, you know, you can point like an agent at a URL for like, you know, Wikipedia or something and it can download it and whatever. But if you point it at like your internal company wiki, well, that has like SSO systems and stuff and it can't just like fetch information from it unless it also has your authorization. And if you give it your authorization, that opens up a whole other can of worms where now you're allowing your agent to interact with your internal company resources as you. And like that's just a whole mess, especially because you has a lot more scope than you necessarily want to give your agent access to. Alex Williams Very much so, especially if it's PII or et cetera. Luca Chang Yeah, and so MCP servers are sort of a partial solution to that in that you can explicitly define the tools that an MCP server offers. ([Time 0:21:02](https://share.snipd.com/snip/28efab1b-34ee-4065-ab2e-93e6183c2ec3)) - **Combine Sandboxes And Better Auth To Harden MCP** - Harden MCP with architecture controls plus protocol-level auth improvements. - Luca suggested sandboxing, network controls and proposals for DPoP and Workload Identity Federation to reduce credential blast radius. Transcript: Luca Chang There are sort of architecture answers and protocol answers. The architecture answers, I think, are actually some of the most compelling ones. Like a lot of the problems that we see today are problems that we sort of always had. And a combination of sandboxing and network controls and other things can effectively address all or almost all of those changes, today. In Bedrock AgentCore, that's actually one of the main things that we attempt to do. If you combine AgentCore runtime, gateway, and policy, that covers basically all of your bases. There was a blog post from Mark Brooker not too long ago called Agent Safety is a Box, and he discusses this more thoroughly. So I'll leave that one there. But on the protocol side of things, I think there are also some changes that can be made to how authentication and authorization are handled, just a little bit. There are currently some proposals active for supporting both Depop and Workload Identity Federation, which basically will improve how credentials are managed and reduce the blast Radius if any credential leaks. ([Time 0:25:11](https://share.snipd.com/snip/70c75577-f4bc-420c-b515-75831e44b131)) - **Open Shell Agents Increase Security Burden** - OpenClaw-style open shells represent a parallel, risky trend that increases sandboxing responsibility for operators. - Luca contrasted MCP's discrete tool model with OpenClaw's shell-heavy approach and warned most operators are poor at securing sandboxes. Transcript: Alex Williams So OpenClaw just remains as Wild West as possible. Luca Chang Yeah, I would say it represents an parallel trend. Alongside how, you know, on the MCP side, a lot of what we're looking at is making sure you can control the tools that are available to an agent. On the OpenClaw side, it's more representing a paradigm where basically you give your agent bash, you give your agent traditional clis and skills and basically just like let it run Wild that i think is a dangerous and somewhat worrying trend uh i i think it's a it's a dangerous path to go down because basically it leaves you entirely at the mercy of how good your sandboxing Is yeah people uh aren't always very good at at securing their sandboxes no they're not especially uh if if they just open the door for for all network access which you know a lot of people Do i am never gonna let you come home and see my home open claw install because he would scream at me i probably would um but yeah so you know and in that sense i think leaning in into that approach That sort of shell heavy approach is probably uh a mistake overall because it it just put so much responsibility for for securing the sandbox itself under the responsibility of the Operator, who might just be a regular person. Whereas MCP lets you say, okay, there is a discrete set of tools that I will allow my agent to use. I know what those tools are. I can't do anything beyond them if I also lock off network access beyond that. ([Time 0:27:06](https://share.snipd.com/snip/e951839a-1c56-46ef-b080-e9a1c79ffb2a)) - **MCP Server Growth Outpaces Agent Adoption** - MCP server usage tends to outpace agent usage because each agent needs many service connectors. - Luca stated enterprises create many MCP servers per agent to connect the dozens of SaaS products employees use, so server growth exceeds agent growth. Transcript: Luca Chang An extent, you know, as I mentioned, like when people start like working with agents, they usually want to hook them up to a lot of services. And so you see many more MCP servers than agents that people are using. So the usage of MCP is like sort of like greater than the usage of agents. Alex Williams It's above. OK, so then as agents scale, we should expect MCP usage and the number of servers out there to scale even faster. Yes. So this should be essentially vertical for the next couple of years. I ([Time 0:30:13](https://share.snipd.com/snip/7ea75876-2e93-41a1-b992-a92e0159f01a))