Eu vejo um valor muito claro nessa arquitetura: ela permite que um agente de IA rode na nuvem, com controle centralizado, e ainda assim atue sobre arquivos que ficam no computador do usuário, como planilhas Excel. Para empresas que tratam nuvem com rigor, como a Interserv Cloud, esse padrão faz sentido porque junta governança, isolamento e operação remota sem levar credenciais e dados locais para fora da máquina sem controle.
O ponto central é simples: o agente fica no AgentCore na nuvem, mas as ferramentas MCP continuam locais.
Na prática, eu penso nessa solução como uma ponte bem definida. De um lado, está o runtime do Amazon Bedrock AgentCore, executando o agente e atuando como cliente MCP. Do outro, ficam as ferramentas locais, expostas por um MCP server rodando no computador do usuário e falando por stdio. Entre eles, entram dois componentes que fazem o tráfego acontecer com ordem.
Como a arquitetura se organiza
Quando eu monto esse desenho, separo os papéis assim:
AgentCore runtime: executa o agente na nuvem, recebe o pedido do usuário e faz chamadas MCP.
Extensão do navegador: mostra a interface de chat e funciona como relé bidirecional entre a nuvem e a máquina local.
MCP Bridge: roda localmente, recebe mensagens da extensão por native messaging, traduz formatos e fala com o MCP server.
MCP server: processo local que oferece ferramentas, como criar, ler e editar arquivos, usando stdio.
Eu gosto desse padrão porque ele não exige que o agente tenha acesso direto ao disco do usuário. Isso reduz exposição. Também deixa a peça local pequena e substituível. Se amanhã eu quiser trocar o servidor MCP de planilhas por outro voltado a PDFs, basta ajustar a camada local.
As ferramentas publicadas pelo MCP server aparecem para o agente sem mexer no código do agente. Isso acontece porque o protocolo faz descoberta automática de capacidades.
O agente vê ferramentas. Não discos.
Fluxo das mensagens
O caminho da mensagem precisa estar claro para o teste funcionar sem ruído. Eu costumo resumir o fluxo em seis etapas:
O usuário envia uma mensagem pela extensão no Chrome.
A extensão encaminha o texto ao AgentCore runtime na nuvem.
O agente decide chamar uma ferramenta MCP e manda a requisição de volta por WebSocket para a extensão.
A extensão repassa a mensagem ao bridge com native messaging.
O bridge remove o envelope do navegador, traduz o formato e envia ao MCP server local por stdio.
A resposta volta pelo mesmo caminho até o agente consumir o resultado e responder no chat.
Cada requisição e resposta usa IDs únicos para correlação, o que evita confusão entre chamadas simultâneas.
Isso é útil quando o agente lista ferramentas, lê um arquivo e depois escreve em uma planilha quase ao mesmo tempo. Sem esse controle, a resposta de uma chamada poderia cair na conversa errada.
Como o MCP entra na conversa
O protocolo MCP segue uma inicialização padrão. Primeiro vem o handshake. Depois, o cliente descobre as ferramentas disponíveis. Em geral, eu espero ver chamadas como tools/list para listar recursos e tools/call para invocar uma ação específica.
Se o MCP server expõe funções para manipular planilhas, o agente passa a enxergar comandos como criar workbook, escrever célula ou ler dados. Isso acontece de forma automática após o discovery. Eu gosto disso porque o agente fica mais genérico e a inteligência de integração fica no lado das ferramentas.
No MCP, o servidor descreve suas ferramentas e o cliente passa a usá-las sem alteração manual no agente.
Esse desacoplamento ajuda muito em ambientes controlados. Em times que lidam com auditoria e mudança bem rastreada, como costuma ocorrer em projetos operados pela Interserv Cloud, isso simplifica manutenção.
Como o native messaging funciona
A extensão do navegador não fala direto com qualquer processo. Ela usa native messaging, que depende de um manifesto registrando o binário do bridge e do identificador permitido da extensão. Esse controle por extension_id limita a origem que pode abrir o processo local.
As mensagens são serializadas com cabeçalho de tamanho antes do payload. Há limites de tamanho, então o bridge precisa tratar isso com cuidado. Em muitos projetos, um script inicializa o ambiente Python e então sobe o processo do bridge, garantindo que dependências e paths estejam corretos.
Eu recomendo manter o bridge isolado. Ele deve receber, converter e encaminhar. Nada além disso.
No bridge, faz sentido ter:
Remoção e adição de envelope e cabeçalho entre navegador e stdio
Filas de entrada e saída desacopladas para evitar bloqueios
Arquivo simples de configuração para novos servidores MCP
Com isso, adicionar um novo servidor local pode virar quase uma linha no mcp.json ou arquivo parecido.
Requisitos para rodar
Antes de testar, eu separaria o ambiente com estes itens:
Conta AWS com Bedrock habilitado e modelo Claude Opus 4.7
Permissões de IAM para criar e operar o runtime
AWS CLI configurado
AWS CDK instalado
Python 3.10 ou superior
Node.js 20 ou superior
Chrome com suporte a Manifest V3
Git
AgentCore CLI e AWS CDK instalados via npm
Se você acompanha temas de agentes, eu sugiro também guardar como referência os conteúdos da categoria de agentes de IA e da categoria de agentes de IA no blog, porque esse tipo de integração cresce rápido e muda bastante.
Passo a passo de implantação
Quando eu testo esse cenário, sigo uma ordem simples para não me perder:
Clono o repositório com Git.
Instalo as dependências Python do bridge e do MCP server.
Crio e publico o agente com o AgentCore.
Faço o deployment da infraestrutura com AWS CDK, se o projeto usar stack auxiliar.
Ajusto o arquivo bridge/bridge_config.json com o ARN do runtime.
Carrego a extensão no Chrome em modo de desenvolvedor.
Registro o bridge nativo com o manifesto correto.
Abro o painel lateral da extensão e inicio os testes.
Para experimentar com planilhas, eu começaria com mensagens assim:
Criar uma workbook chamada budget.xlsx com abas Q1 e Q2
Escrever "Receita" na célula A1 da aba Q1 de budget.xlsx
Ler dados de budget.xlsx
Cuidados de segurança nesta versão
Essa implementação já adota algumas barreiras úteis:
Restrição de origem na mensageria nativa por extension_id
URLs presignadas com expiração de 5 minutos
Isolamento de processos entre extensão, bridge e servidor
Credenciais mantidas apenas no computador do usuário
Mesmo assim, para produção eu adicionaria mais camadas:
Autenticação com handshake JWT
Assinatura de payloads com Ed25519
Diretórios explícitos permitidos para o MCP server
Logging de todas as invocações, com nome da ferramenta, argumentos, horário e status
Esse último ponto conversa bem com práticas de monitoramento contínuo e também com a abordagem de monitoramento no blog. Eu também gosto de cruzar isso com controle de gasto e previsibilidade, tema tratado em práticas para evitar surpresas no orçamento da AWS.
Como limpar o ambiente e como ampliar a solução
Depois dos testes, eu faria a limpeza sem pressa:
Remover o deployment do AgentCore e as stacks associadas
Desinstalar o bridge e apagar o manifesto nativo
Excluir a extensão do Chrome
Apagar planilhas e arquivos de teste
Se a ideia for crescer, o caminho é bom. Dá para adicionar ações no navegador, como cliques e preenchimento de formulários. Dá para conectar novos servidores MCP com uma linha no mcp.json. E também dá para empacotar o bridge com PyInstaller, criando um binário próprio e evitando dependência de instalação manual do Python.
Eu gosto dessa arquitetura porque ela separa bem as fronteiras. O agente continua centralizado. As ferramentas ficam perto do dado. E o controle de segurança pode amadurecer por etapas. Se a sua empresa quer ligar agentes a fluxos locais sem abrir mão de resiliência e governança, vale conhecer melhor o trabalho da Interserv Cloud e conversar com um arquiteto para desenhar esse modelo com segurança.
Perguntas frequentes
O que é o Bedrock AgentCore?
Eu definiria o Bedrock AgentCore como o ambiente em que o agente roda na nuvem, com execução centralizada, integração com modelos e capacidade de chamar ferramentas externas. Nesse cenário, ele também atua como cliente MCP para consumir ferramentas publicadas localmente.
Como integrar AgentCore com MCP?
Eu faço isso conectando quatro peças: runtime no AgentCore, extensão do navegador, bridge local e MCP server. O usuário fala com a extensão, o agente envia requisições MCP por WebSocket, a extensão repassa por native messaging, o bridge traduz e entrega ao servidor local por stdio. A resposta retorna pelo mesmo caminho.
É seguro manipular arquivos locais?
É seguro quando há limites claros. Nesta versão, há controle por extension_id, isolamento de processos, expiração curta de URLs presignadas e credenciais mantidas no computador do usuário. Para ambiente de produção, eu adicionaria JWT, assinatura Ed25519, diretórios permitidos e logs completos.
Quais arquivos posso acessar com MCP?
Depende do MCP server instalado na máquina local. Se ele foi criado para planilhas, o agente pode criar, ler e editar arquivos como XLSX. Se outro servidor expuser ações para PDF, texto ou navegador, essas capacidades também podem aparecer para o agente após o discovery de ferramentas.
Preciso de permissões especiais para integração?
Sim. Eu esperaria permissões de IAM para operar o Bedrock AgentCore, acesso configurado na AWS CLI, dependências como AWS CDK e AgentCore CLI, além de permissão local para registrar o native messaging host no sistema e carregar a extensão no Chrome.
