How we built an MCP bridge to give our AgentCore-hosted AI agent access to local MCP tools

There's a specific problem that trips up a lot of enterprise AI plans: the agent lives in the cloud, but the data people actually work with sits in a spreadsheet on someone's laptop. AWS just published a detailed walkthrough of how their team solved this for an internal finance assistant that's fielded over 41,000 conversations in its first year, and the fix is a clever bit of plumbing rather than a new model.

The core idea rides on MCP, the open protocol Anthropic released in November 2024 for connecting AI systems to tools and data. MCP normally assumes either two local processes talking over stdio, or a remote client and remote server talking over HTTP. Nobody had really solved the case where the client is remote and the server is local — which is exactly the setup you get when a Bedrock AgentCore-hosted agent needs to open a file that never left someone's machine. AWS calls their fix an MCP bridge, and it stitches together four pieces: the AgentCore runtime running a Strands agent in the cloud, a Chrome extension acting as a relay, a local FastMCP proxy called the MCP Bridge, and whatever MCP server actually touches the files — in their demo, an Excel server.

The mechanics are almost old-school in their simplicity. WebSocket carries messages between the cloud agent and the browser; native messaging, the same feature Chrome and Firefox use to let extensions talk to local apps without begging for network permissions, carries messages the rest of the way to the bridge. Every message gets wrapped in an envelope, unwrapped at each hop, and JSON-RPC payloads pass through untouched. Native messaging caps incoming messages at 1MB and outgoing at 64MiB, and the bridge itself runs two loops so a slow tool call doesn't stall the next request. It's not glamorous engineering, but it's the kind of unglamorous plumbing that makes a demo into something you'd actually trust with a budget.xlsx file.

Security gets a fair amount of attention, and rightly so, because handing a cloud-hosted agent the ability to run commands with a user's local file permissions is the obvious worry. AWS's answer here is deliberately minimal for the demo: Chrome checks extension IDs against an allow-list, WebSocket URLs are SigV4-signed and expire after five minutes, and credentials never leave the user's machine. They're upfront that a real production deployment needs more — Bedrock Guardrails and additional hardening they promise to cover later — but the underlying principle they state plainly: the agent should never have more access than the user explicitly grants, and every tool call should be visible to the person who granted it.

What's notable is how directly this maps onto Claude Cowork's pattern of a cloud agent reaching into local tools, except AWS built the whole thing self-hosted, with your own model choice and custom tool servers. The code is open on GitHub, deployable in about 15 minutes, and it runs on pay-per-invocation pricing with no idle cost — which makes this less a research curiosity and more a template other teams building finance or ops copilots will probably just copy outright.