- MCP-B: protocolo nativo de automação com IA para navegadores
- Em vez do método tradicional de captura de tela e cliques, ele permite que a IA automatize 1.000 vezes mais rápido e com mais precisão ao acessar diretamente a API do site, por meio de um protocolo de contexto para navegadores
- Com a adição de cerca de 50 linhas de código, é possível integrar IA imediatamente usando as credenciais do próprio site, sem OAuth separado, chave de API ou configurações complexas
- Aproveitando a sessão do navegador e o sistema de autenticação existente, funciona na hora sem novas autenticações ou configurações de permissão, respeitando integralmente as políticas de segurança de API de cada web app
- Por meio de uma extensão, o assistente de IA pode consultar dados e executar tarefas diretamente entre várias abas e apps, com desempenho (execução em poucos ms) e confiabilidade muito superiores à automação tradicional
- Como se trata de acesso estruturado à API, ele fica livre de problemas com mudanças de UI, erros de screenshot e manutenção complexa de seletores. Tanto a instalação quanto o uso são muito simples
Visão geral do MCP-B
- MCP-B (Machine Context Protocol for Browsers) é um protocolo de contexto de modelo para navegadores, que fornece um padrão para controlar e interagir com o ambiente do navegador de forma semelhante à automação de terminal baseada em IA
- O protocolo define claramente a comunicação entre o navegador e o motor de IA, estruturando diferentes formas de automação e interação com modelos
Diferenças em relação aos métodos existentes
- Automação tradicional de navegador: análise de screenshots, clique em elementos, vulnerável a mudanças de UI, lenta e instável (10 a 20 segundos por tarefa, custo de $4~5)
- Abordagem MCP existente: exige chave de API e autenticação complexa, com alta barreira de entrada na configuração inicial
- MCP-B: utiliza a sessão do navegador, acesso direto à API e funciona imediatamente sem autenticação nem configuração complexas
Princípio central e arquitetura
- Servidor MCP por aba: cada web app executa seu próprio servidor MCP baseado em TypeScript (transporte em memória, reaproveitando autenticação existente por cookie/JWT)
- Extensão MCP-B: extensão para Chrome/Edge/Firefox (o content script se comunica com o servidor da aba via
postMessage), integrando em um só lugar todas as ferramentas e APIs de todas as abas - Integração com assistentes de IA: automação de navegador via MCP-B em Native Bridge e vários clientes (Claude Desktop, Cursor IDE etc.)
Uso e implantação
- Desenvolvedores: 1) instalar o pacote 2) adicionar o código do servidor MCP 3) concluir a implantação → sem necessidade de chave de API, OAuth ou configuração complexa
- Usuários: basta instalar a extensão e usar imediatamente; a automação começa na hora apenas com a configuração da IA
Vantagens práticas
- Autenticação: usa diretamente o login e as informações de sessão já existentes no site, sem necessidade de OAuth 2.1/autenticação separada
- Desempenho: tarefas concluídas em milissegundos por meio de chamadas diretas à API (melhoria de 10.000 vezes em relação ao método anterior)
- Segurança: opera dentro da aplicação, respeitando integralmente os controles de acesso e políticas de permissão existentes
- Escalabilidade: vários web apps, abas e ferramentas de IA podem ser gerenciados de forma integrada via MCP-B
- Configuração: a automação fica pronta com cerca de 50 linhas de código
Resumo comparativo
| Método | Autenticação e configuração | Forma de operação | Desempenho e confiabilidade |
|---|---|---|---|
| Automação tradicional | Autenticação complexa, chave de API | scraping de tela, cliques | lenta e instável (10 a 20 s) |
| MCP existente | Exige chave de API, OAuth | acesso à API | alta barreira de entrada |
| MCP-B | Sem configuração, usa sessão do navegador | chamada direta de API | nível de ms, muito rápido/estável |
Conclusão: automação de IA baseada em navegador de próxima geração
- O MCP-B é um protocolo de automação com IA otimizado para o ambiente do navegador e inovador em autenticação, segurança, escalabilidade e desempenho
- Sem autenticação adicional nem configurações complexas, é possível implementar automação de IA em larga escala apenas com chamadas diretas à API a partir do navegador
- Licença MIT, voltado para a comunidade e com suporte a todos os principais navegadores
2 comentários
A visão central da tecnologia MCP-B pode ser resumida da seguinte forma.
"Por meio de um intermediário confiável chamado extensão do Chrome, vamos aproveitar as informações do usuário que o navegador já gerencia com segurança — cookies, sessão, autenticação etc. — para chamar e controlar, a partir de uma janela de chat com IA e usando comandos em linguagem natural, as 'ferramentas (Tools)' previamente definidas por desenvolvedores em páginas da web."
Mas eu sinto que "não parece haver espaço para escalar", e acho que os motivos são os seguintes.
Em conclusão,
a ideia do MCP-B em si é tecnicamente muito interessante e inovadora, mas parece não conseguir dar uma resposta clara à pergunta fundamental de usuários e desenvolvedores: "por que exatamente seria necessário usar esse método?". Em comparação com o modelo tradicional de APIs, os benefícios não são claros, enquanto as desvantagens — preocupações de segurança e complexidade de desenvolvimento — são evidentes.
Portanto, por enquanto, essa tecnologia até pode ser usada de forma experimental entre alguns entusiastas ou desenvolvedores com objetivos específicos, mas parece haver muitas dificuldades para que ela se expanda por todo o ecossistema web.
Comentários no Hacker News
Previsão: vai seguir um caminho parecido com o do RSS. As empresas tendem a não gostar que o usuário controle por conta própria como seus dados são usados
O mesmo aconteceu com APIs REST, que em certo momento eram vistas, junto com a onda de design "API-first", como o futuro da automação e da integração de serviços. Mas as empresas logo perceberam que oferecer esse tipo de capacidade ameaçava seu modelo de receita, e mudaram rapidamente de direção. No fim, redescobriram que todo o dinheiro depende de impedir que o usuário tenha esse tipo de poder
Acho que o RSS não fracassou; na verdade, foi um enorme sucesso. Depois que o Google Reader acabou, pude migrar para outros leitores, e os feeds RSS continuam funcionando sem problemas há mais de 20 anos. Quase nunca encontrei um site que não oferecesse suporte a RSS
A maioria dos sites ainda oferece suporte a RSS, e alguns até têm feed por padrão mesmo sem exibi-lo na página. Mesmo que só alguns publiquem o conteúdo completo, ele ainda tem muito valor como aviso de atualização ou gatilho de automação. O RSS continua muito vivo e útil, como um micro-ondas: está simplesmente ali, como algo óbvio
Houve uma mudança na estrutura do mercado, e agora as grandes empresas se concentram mais na "camada de inteligência" do que no conteúdo em si. O conteúdo está cada vez mais comoditizado. O Google precisa capturar os olhos e a atenção dos usuários, além da tecnologia inteligente que os prende, para continuar vendendo anúncios. O Google não queria o RSS porque ele podia contornar o Google Search
Quando a IA passar a clicar e rolar a página como uma pessoa, haverá mais uma rodada de competição infinita
O histórico de contribuições do projeto no Github é muito interessante (citando diretamente este link). MiguelsPizza fez 3 commits, Claude fez 2, mas o volume de código alterado por Claude é quase esmagador
Houve um ajuste temporário no histórico do git quando a extensão foi colocada como privada por um tempo, então há uma pequena diferença em relação ao histórico real. Ainda assim, é verdade que cerca de 85% do código foi escrito pelo Claude
Parece provável que esse padrão de contribuição massiva de código por IA se torne cada vez mais comum
O gráfico de commits do Claude é bem peculiar. Parece que o Claude Code está fazendo commits diretamente, mas na prática quase não faz. Vale ver também o perfil do claude
Se olhar a lista real de commits, todos aparecem no nome de MiguelsPizza / Alex Nahas (link). Tem algo estranho aí
Citando um trecho do blog, discutem o problema de autenticação no MCP. O OAuth2.1 parece aceitável no longo prazo, mas estamos numa situação em que é preciso reinventar a autenticação para agentes que atuam em nome do usuário. O risco de vazamento de dados em apps multi-tenant ainda não foi resolvido
Limitar o alcance do dano e os dados acessíveis ao modelo pode ser uma grande vantagem do MCP. Espera-se que a API do lado do cliente em apps multi-tenant já esteja restrita ao escopo do usuário, então, se só isso for exposto ao modelo, o dano não deve ser grande. Também é mencionado o problema de compatibilidade entre o sistema interno de autenticação da Amazon e o OAuth2.1 (na Amazon a autenticação é diferente)
Fica a dúvida se parte dessas funções do OAuth2.1 já não é tratada pelo RFC 8693 em delegation vs. impersonation
O escopo que o modelo pode acessar acaba sendo o mesmo do usuário, então implementar segurança corretamente é responsabilidade do administrador do site
Acho que o exemplo da Amazon, onde o OAuth não foi aplicado corretamente, não é a questão principal. Um acesso estilo backdoor que ultrapasse o escopo de permissão do usuário é extremamente perigoso. Se todas as ações do app MCP forem registradas na mesma categoria do acesso do usuário, isso pode gerar muitos problemas de compliance. É uma perspectiva muito interessante, mas do ponto de vista de segurança parece um atalho com bastante potencial de problema
Surge a ideia de que talvez quase tudo isso pudesse ser substituído simplesmente publicando uma especificação Swagger (OpenAPI) e tendo um cliente MCP genérico para swagger. O próprio usuário poderia abrir manualmente a sessão autenticada. A proposta é que, se o Claude já entende bem chaves de API a partir do prompt/configuração, então usar um cliente de API baseado em swagger não daria no mesmo
Foi a primeira ideia que quase todo mundo teve quando o MCP apareceu. Mas, na prática, percebeu-se que isso não funciona tão bem porque existem ferramentas demais. Ainda assim, seguem surgindo tentativas interessantes nessa área
Também há o alerta para não colocar a chave de API no prompt
O Claude Code fica muito prático para testar APIs se você só colocar o link do swagger.json no
CLAUDE.mdIncentivam a testar por conta própria
Não está claro quem é o usuário-alvo. Em testes de frontend, se a UI muda muito e o teste quebra, isso pode até ser útil. Para outros objetivos de automação, parece melhor oferecer uma API de verdade
Sobre a analogia de que "seria ainda mais difícil montar uma mesa na Home Depot", alguém questiona isso lembrando que a Home Depot está cheia de madeira
A Home Depot também vende mesas já prontas
A Home Depot pode até facilitar o trabalho, porque lá existem ferramentas de precisão melhores e até profissionais
Fazem uma piada no sentido de que "a madeira você precisa imaginar e criar sozinho"
Dizem que ajustaram a frase levando essa observação em conta
Ainda não usou MCP diretamente, mas, do ponto de vista de uma pessoa com deficiência, parece haver um grande potencial de uso para acessibilidade na automação de navegador e smartphone. Ao mesmo tempo, fica a dúvida se esse tipo de tecnologia seria adotado por grandes sites/apps, já que pode ser abusado por usuários mal-intencionados. Pergunta se já existem casos reais de uso para melhorar acessibilidade
Agradecem por o MCP-B ter sido disponibilizado como open source. Muita coisa já acontece dentro do navegador, mas o MCP parte da premissa de que o trabalho será feito por um cliente de IA. A dúvida fundamental é em que isso difere de conectar diretamente a API JS de um app web a um servidor de LLM. No fim, seria a mesma coisa ou existe uma visão maior por trás disso
Só pelo conteúdo da homepage não ficou muito claro, então perguntam se seria como uma versão para navegador do Selenium
Preveem que, se a automação de navegador via MCP começar a atingir usuários de LLMs gratuitos, até os modelos gratuitos vão acabar recebendo CAPTCHA. O problema é que CAPTCHA não é tão eficaz assim contra LLMs, então talvez entremos numa estranha era de guerra entre robôs, em que LLMs vão brigar entre si para bloquear o acesso de outros LLMs de automação