Conectar N ferramentas a M modelos antes exigia N×M camadas de adaptação. O MCP desacopla o lado das ferramentas do lado dos modelos para que cada um implemente o protocolo uma única vez. O artigo explica essa escolha de arquitetura, as abstrações de ambiente e ações do navegador e o que ainda não foi resolvido.
Para um Agent realmente executar tarefas, ele normalmente acaba no navegador: fazer login, publicar, coletar dados ou preencher formulários. A dificuldade técnica não é saber se ele consegue clicar, mas o custo de integração necessário para entregar um navegador a um Agent.
O labirinto de adaptações N×M
Suponha que existam N ferramentas e M modelos no mercado. O fornecedor de uma ferramenta precisa escrever uma integração para cada modelo, enquanto o lado do modelo precisa de uma camada de adaptação para cada ferramenta. Cada lado mantém sua própria implementação, totalizando N×M combinações.
O problema é a multiplicação. Adicionar uma ferramenta não significa apenas uma tarefa extra: é preciso conectá-la a cada modelo. No sentido inverso, quando um modelo muda de versão, ferramentas já integradas podem precisar ser validadas novamente. Uma capacidade pode ser excelente, mas, se não houver adaptação para determinado modelo, ela não poderá ser usada ali — a ferramenta fica presa na etapa de distribuição.
No início, cada parte precisava desenvolver sua própria solução. Para fazer a mesma coisa — listar ambientes, iniciar um navegador, ler uma página — era necessário reescrever tudo ao mudar o chamador, e a lógica muitas vezes ficava inconsistente: alguns colocavam a espera no cliente, outros no servidor.
O protocolo desacopla os dois lados
O MCP (Model Context Protocol) foi divulgado publicamente no fim de 2024. A proposta é padronizar a descoberta e a chamada de ferramentas: o que é exposto, como os parâmetros são descritos e qual estrutura é retornada passam a ser definidos pelo protocolo.
A arquitetura passa a ser um Agent conectado a um MCP Client, que, seguindo o protocolo, se conecta a vários MCP Server; as capacidades concretas ficam atrás desses servidores. O volume de implementação cai de N×M para N+M: o lado do modelo implementa o cliente uma vez, e o lado da ferramenta implementa o servidor uma vez.
Há apenas três papéis. O Host é a aplicação que executa o modelo e inicia o cliente. O Client é a implementação cliente do protocolo, geralmente um para cada Server. O Server é desenvolvido pelo fornecedor da ferramenta e expõe as capacidades como ferramentas padronizadas.
Atualmente há dois modos de comunicação. No modo local, cliente e servidor ficam na mesma máquina e usam entrada e saída padrão; o caminho é curto e há pouca configuração, por isso esse modo é muito usado em automação. O modo remoto usa HTTP ou WebSocket e é adequado para implantações distribuídas, mas exige pensar com mais cuidado em autenticação e limites de rede.
No navegador, três camadas são expostas
Ao conectar um ambiente de navegador ao protocolo, as capacidades expostas se distribuem, de forma geral, em três camadas.
A camada superior é o ambiente: listar os ambientes de uma conta, criar um novo com base em uma configuração, iniciar um ambiente específico, associá-lo a uma saída de rede e encerrá-lo depois do uso. Antes, essas operações ficavam espalhadas por APIs de diferentes fornecedores; agora se tornam ferramentas que o modelo pode descobrir e chamar. Ao iniciar, normalmente é retornado um endpoint de depuração, como uma porta ou endereço WebSocket, que pode ser entregue a drivers como Selenium ou Puppeteer.
A camada intermediária é a página: abrir um endereço, ler o DOM ou a árvore de acessibilidade, alternar abas e fazer capturas de tela.
A camada inferior reúne as ações: clicar, digitar, rolar, esperar uma condição e lidar com pop-ups.
A principal mudança não está na quantidade de ações. O ambiente deixa de ser um trecho de código que você precisa escrever e passa a ser um recurso que o Agent pode escolher e usar. Basta indicar o objetivo; ele pode decidir se cria um novo ambiente ou reutiliza um existente e em que ordem chama as ferramentas. Isso fica especialmente claro quando vários ambientes funcionam em paralelo: o agendamento é descrito no prompt, em vez de ficar codificado rigidamente em um script.
O que ainda não foi resolvido
O protocolo resolve a conexão, não a correção. Há vários pontos fáceis de ignorar.
A qualidade da descrição das ferramentas determina o resultado das chamadas. Se os parâmetros estiverem errados ou a ferramenta incorreta for escolhida, o protocolo não poderá corrigir isso. Com mais ferramentas, as próprias descrições também ocupam contexto, exigindo um equilíbrio entre quantidade e granularidade. Se a granularidade for ampla demais, o modelo não entende tudo o que uma ferramenta pode fazer; se for fina demais, o contexto se esgota primeiro.
Permissões e auditoria ainda estão em estágio inicial. Muitos servidores são locais e executados em uma única máquina, iniciam com privilégios consideráveis e não oferecem autorização detalhada nem registros completos de chamadas. No modo remoto, primeiro é preciso responder quem pode se conectar e o que pode ver.
A instabilidade das páginas também não desapareceu. Elementos que não são encontrados, sequência de carregamento incerta, sessões expiradas e CAPTCHAs ainda exigem esperas, novas tentativas e mecanismos de contingência. O protocolo apenas padroniza o ponto de entrada.
A maturidade do ecossistema também é desigual. Diferentes servidores não oferecem exatamente os mesmos tipos de recurso, estruturas de retorno ou códigos de erro. Ao combinar vários servidores em uma tarefa, a lógica de orquestração ainda costuma precisar ser escrita manualmente. O próprio protocolo continua evoluindo, então diferenças de comportamento entre versões merecem atenção.
Também é importante separar outro limite: o protocolo define como um modelo chama ferramentas, não se a tarefa em si está em conformidade. Saber se a coleta foi autorizada, se a finalidade de uso de uma conta é legítima ou se regras de uma plataforma estão sendo violadas são avaliações independentes e não têm relação com a fluidez da conexão.
Em cenários com vários ambientes, o isolamento entre eles e a configuração conjunta de saída de rede, fuso horário e idioma costumam afetar mais o resultado do que o método de integração. Na camada de isolamento de ambientes, a PurpleMark oferece interfaces de criação, inicialização e configuração de rede que podem ser chamadas por ferramentas de AI e coordenadas por um único cliente.
Este conteúdo apresenta apenas princípios técnicos. Use os protocolos e ferramentas correspondentes de acordo com as leis e regras aplicáveis.
