A financial analyst opens a complex Excel workbook on their local laptop and asks a cloud-based AI agent to summarize the quarterly trends. In a traditional workflow, this requires the analyst to manually upload sensitive spreadsheets to a cloud bucket, wait for processing, and hope the security team has approved the data transfer. This friction creates a persistent gap between the power of Large Language Models and the reality of where corporate data actually lives. For those handling high-stakes financial data, the act of uploading a file is not just a productivity hurdle but a significant security risk.

The Protocol Gap Between Cloud Agents and Local Data

To solve this disconnect, the industry is turning toward the Model Context Protocol (MCP), an open-standard specification released by Anthropic in November 2024. MCP aims to standardize how AI models connect to external data and tools using a client-server architecture. In this ecosystem, an MCP host (the AI application) establishes a connection with one or more MCP servers. Currently, the protocol supports two primary communication mechanisms: stdio for local process-to-process communication on the same machine, and streaming HTTP for remote server communication.

While the protocol is robust, a critical architectural gap emerges when the MCP client resides in the cloud and the MCP server resides on a user's local PC. Cloud agents cannot natively reach into a local machine's stdio stream. This is where the Amazon Bedrock AgentCore framework enters the picture. In a real-world deployment for financial services, an AI assistant built on AgentCore processed over 41,000 conversations in a single year, proving that local data access is not just a theoretical possibility but a scalable operational requirement. To bridge the cloud-to-local divide, a specialized MCP bridge architecture was developed, utilizing a combination of WebSockets and native messaging to call local functions without moving the underlying data to the cloud.

Engineering the Secure Relay via Native Messaging

Connecting a cloud agent to a local process requires a secure, low-latency pipeline that avoids exposing the user's machine to the open internet. The solution employs a browser extension as the primary relay. When a user initiates a session, the extension communicates with the AgentCore runtime to establish a presigned WebSocket connection. The browser side-panel sends a signature request to a native bridge, which uses the user's local AWS credentials and the bedrock-agentcore SDK to generate a SigV4 signed `wss://` URL valid for five minutes. Crucially, these credentials never leave the device and never enter the browser's memory space, maintaining a strict security boundary.

When the cloud agent determines it needs to access a local tool, such as reading an Excel cell, it wraps an MCP JSON-RPC request into a JSON envelope and transmits it via the WebSocket to the browser extension. The extension then relays this message to the local MCP bridge using the Native Messaging protocol. The bridge unwraps the envelope, extracts the JSON-RPC content, and delivers it via stdio to the MCP server running on the local machine. The response follows the exact reverse path: from the MCP server to the bridge, through the extension, and back to the AgentCore runtime.

To achieve this without requiring constant network permission prompts or manual user approvals, the system leverages the Native Messaging capabilities of Chrome and Firefox. The browser identifies the binary to execute by referencing a manifest file located at a specific system path. For a macOS environment running Chrome, the manifest is structured as follows:

{

"name": "com.example.mcp_bridge",

"description": "MCP Bridge for Chrome",

"path": "/Users/username/mcp-bridge/run_bridge.sh",

"type": "stdio"

}

The extension's background script triggers the local application by calling `chrome.runtime.connectNative("com.example.mcp_bridge")`. This invokes a shell script that manages the environment and launches the bridge process:

#!/bin/bash
source /Users/username/mcp-bridge/venv/bin/activate
python3 /Users/username/mcp-bridge/bridge.py

This native host process remains active for the duration of the connection. All messages are serialized as JSON, UTF-8 encoded, and prefixed with a 32-bit little-endian length header. While the browser limits messages from the host to 1MB and messages to the host to 64MiB, these constraints are negligible for the text-based JSON-RPC payloads used by MCP.

Optimizing Throughput with a Two-Loop Design

The MCP bridge functions as a protocol translator between the browser's native messaging and the MCP standard. To prevent the bridge from becoming a bottleneck, it employs a two-loop asynchronous design that decouples request reception from server processing. The main loop focuses exclusively on receiving messages from the browser, stripping the 4-byte length header, parsing the JSON body, and placing the JSON-RPC content into an input queue.

Simultaneously, a FastMCP proxy runs in a separate background loop. It pulls messages from the input queue, pipes them into the MCP server's stdin, and captures the resulting stdout response into an output queue. A second background loop monitors this output queue, re-wrapping the responses into JSON envelopes with the required length headers before sending them back to the browser. This architecture ensures that if a specific local tool—such as a heavy Excel calculation—takes several seconds to respond, the bridge can still receive and queue subsequent requests without blocking.

To handle the complexity of multiple simultaneous tool calls, the bridge implements a correlation matching system using `asyncio.Future`. Every JSON-RPC request from the agent carries a unique ID. The bridge registers this ID as a `(session_id, jsonrpc_id)` pair in memory. When a response returns via the WebSocket, the bridge matches it to the corresponding Future, ensuring that the agent receives the correct data even in a highly asynchronous environment.

Extensibility is handled via a configuration file, `mcp.json`, which allows developers to add new MCP servers by simply defining the execution path and arguments. This removes the need to modify the core Python code of the bridge whenever a new local capability is added, allowing the AI agent's skill set to expand dynamically based on the local environment's needs.

This architecture transforms the cloud AI from a remote observer into a local operator. By granting the agent temporary execution rights rather than permanent data access, organizations can bypass the lengthy security audits typically associated with cloud migrations. The system further ensures stability with an automatic reconnection mechanism that requests a new presigned URL every two seconds if the connection drops, masking the five-minute expiration window from the user.

By shifting the paradigm from data movement to function invocation, enterprises can finally integrate legacy local workflows with state-of-the-art cloud intelligence without compromising their data governance policies.