WebMCP vs MCP: qual é a diferença

O MCP é um protocolo para executar um servidor que expõe suas ferramentas a agentes de IA de qualquer lugar. O WebMCP é uma proposta de padrão web que permite a uma página declarar o que um agente pode fazer nela enquanto o usuário a mantém aberta.

Se você já construiu um servidor MCP, o nome “WebMCP” sugere o mesmo protocolo, só que transferido para o navegador. Não é o caso. A diferença determina onde fica o seu código voltado para agentes, sob qual identidade ele é executado e se você já pode depender dele.

Este artigo compara os dois em termos de runtime, identidade, ciclo de vida e descoberta. Em seguida, relaciona cada um a um tipo de produto e faz uma avaliação objetiva do status atual do WebMCP.

Qual é a diferença entre WebMCP e MCP em uma frase?

O MCP é um servidor que você executa para que um agente possa chamar suas ferramentas. O WebMCP é a sua página declarando o que um agente pode fazer na página em que ele já está. O Model Context Protocol é um padrão aberto para conectar aplicações de IA a dados, ferramentas e fluxos de trabalho externos, e não importa se o agente roda em um navegador ou não. O guia do Chrome sobre quando usar WebMCP e MCP define o WebMCP como uma proposta de padrão de navegador composta por duas APIs. Essas APIs só alcançam o agente integrado ao navegador, e o navegador repassa as mensagens entre esse agente e o seu site. Para entender melhor os navegadores que já vêm com seu próprio agente, veja nossa introdução aos navegadores agênticos. O Chrome chama o WebMCP de “inspirado no MCP”. Trata-se de uma API de navegador modelada a partir do MCP, e não do MCP reescrito em JavaScript.

Quem executa o quê no MCP e no WebMCP?

Um servidor MCP é um processo separado, com implantação, autenticação e disponibilidade próprias. O WebMCP não adiciona nenhum processo novo: ele é executado dentro da aba aberta.

Com o MCP, você mantém um serviço ao qual agentes em clientes desktop, mobile, na nuvem ou na web podem se conectar a qualquer momento. Esse alcance tem seu custo. Você hospeda o servidor, faz o versionamento, monitora e decide como autenticar cada chamador. O guia do desenvolvedor sobre o ecossistema MCP explica como clientes, servidores e o protocolo se encaixam.

Com o WebMCP, as definições de ferramentas são entregues como parte do seu frontend. Não há nada extra para implantar, mas as ferramentas ficam atreladas à aba. Cada ferramenta WebMCP desaparece junto com a aba que a registrou. Se o usuário navegar para outra página ou fechar a aba, o agente perde o acesso àquela ferramenta.

Identidade: o agente age como o usuário autenticado

Como as ferramentas WebMCP são executadas dentro da página que o usuário já tem aberta, um agente que as utiliza atua dentro da sessão, dos cookies e das permissões já existentes desse usuário. Ele não possui uma credencial separada para o seu site. O Chrome destaca que o WebMCP pode usar os dados da sessão ativa da página, os cookies e o DOM, e nada disso existe fora de uma aba aberta. Consequentemente, as requisições de rede de uma ferramenta são enviadas com a sessão que a página já tiver.

Um servidor MCP enfrenta um problema diferente. Por ser um serviço independente, ele precisa descobrir sozinho quem está chamando e o que essa pessoa pode fazer. Isso geralmente significa emitir e verificar algum tipo de credencial para o agente ou para o usuário que ele representa. O WebMCP pula essa etapa porque nunca sai da sessão do usuário. Você não precisa provisionar chaves de API, configurar contas de serviço nem construir uma camada de autorização separada para o agente.

A identidade baseada em sessão do WebMCP tem um custo. Do ponto de vista da página, uma chamada de ferramenta WebMCP é uma ação realizada pelo usuário autenticado. A menos que você projete uma forma de diferenciá-las, seu código não consegue distinguir uma chamada de agente de um clique. Daí decorrem três boas práticas:

• Limite o escopo de cada ferramenta ao que o usuário já poderia fazer pela interface.
• Exija confirmação para ações sensíveis. A visão geral do WebMCP diz que uma ferramenta que executa algo sensível, como uma compra, pode exibir ao usuário uma caixa de diálogo de confirmação antes de prosseguir.
• Conte com os controles da plataforma. O WebMCP só é executado em documentos com isolamento de origem e é controlado pela Permissions Policy tools. O padrão da política é self, então um iframe de origem cruzada precisa receber acesso explicitamente.

<iframe src="https://widget.example.com/" allow="tools"></iframe>

Se o iframe não tiver esse atributo, o padrão self bloqueia o registro de ferramentas nesse frame de origem cruzada. A documentação do Chrome também informa que as APIs do WebMCP ficam desativadas em qualquer documento que habilite document.domain, por exemplo, por meio do header Origin-Agent-Cluster: ?0.

WebMCP vs MCP lado a lado

A divisão fundamental entre MCP e WebMCP é persistência e alcance de um lado, e contexto da página e sessão do usuário do outro.

As cinco primeiras linhas se baseiam na comparação entre WebMCP e MCP feita pelo Chrome.

Quando usar MCP ou WebMCP?

Use MCP para trabalhos que acontecem em um servidor sem UI, e WebMCP para trabalhos que acontecem em uma página com um usuário nela.

• Serviço de backend, jobs em segundo plano ou acesso a dados sem UI: MCP. O WebMCP precisa de uma página aberta, e a visão geral do Chrome diz que ele foi criado principalmente para uma pessoa trabalhando em um navegador local, e não para execuções headless. Comece por como construir um servidor MCP.
• Aplicação web com usuário autenticado: WebMCP. Use-o para ações na página atual, como preencher um formulário complexo ou escolher datas em um widget de reservas, em que a sessão do usuário e o estado da página são relevantes.
• Ambos. Muitos produtos vão querer os dois. O MCP concentra a lógica de negócio principal e os dados, e o WebMCP cobre as ações dentro da aba. Se você já tem uma API HTTP, expor essa API a LLMs com MCP é a metade natural do lado do servidor. Para o lado do navegador, veja nosso artigo complementar, Exposing Your Site’s Actions to AI Agents With WebMCP.

O WebMCP substitui o MCP?

Não. O Chrome diz claramente que o WebMCP não estende nem substitui o MCP. Ele foi criado para o navegador e deixa de fora conceitos do lado do servidor, como resources. Ele também depende de uma página. Suas ferramentas só podem ser descobertas visitando o site e desaparecem quando a aba é fechada. Muitas tarefas de agentes nunca passam por uma página web: jobs agendados, assistentes de IDE, pipelines de dados e agentes rodando na nuvem. Essas tarefas continuam precisando de um servidor MCP.

Qual é o nível de maturidade do WebMCP?

O WebMCP é experimental. Ele está disponível por meio de um origin trial no Chrome a partir do Chrome 149 e localmente pela flag chrome://flags/#enable-webmcp-testing, e o Chrome avisa que a API ainda está em discussão e pode mudar. Origin trials duram um período fixo, podem ter limites de uso e servem para coletar feedback que molda a API final. A especificação do WebMCP é um relatório preliminar do W3C Web Machine Learning Community Group. Ela não é um W3C Standard e não está no W3C Standards Track. A documentação do Chrome cobre apenas a implementação do Chrome, então não presuma suporte em outros navegadores ou hosts de agentes até que a documentação deles confirme isso. Acompanhe o WebMCP no Chrome Status para ver mudanças de marcos. O Chrome também observa que o WebMCP pode ser adicionado como progressive enhancement. Implemente-o dessa forma, para que sua UI funcione da mesma maneira, com ou sem um agente enxergando as ferramentas.

Escolhendo entre os dois

MCP e WebMCP respondem a perguntas diferentes. O MCP torna seus recursos acessíveis a qualquer agente, a qualquer momento. O WebMCP torna a página em que o usuário está utilizável pelo agente do navegador dele, sob a sessão do próprio usuário. Como próximo passo, liste as ações que seu produto expõe e classifique-as: operações headless vão para um servidor MCP, e ações de página vinculadas à sessão se tornam candidatas ao WebMCP, por trás do origin trial. Mantenha a camada WebMCP enxuta, porque a API ainda pode mudar.

Perguntas frequentes

Como ativo o WebMCP para visitantes reais, e não apenas no meu próprio navegador?

Registre sua origem no console de Origin Trials do Chrome e gere um token do WebMCP. Inclua-o em todas as páginas que registram ferramentas, seja em uma meta tag de origin trial, seja em um header de resposta HTTP Origin-Trial. Os tokens são por origem. Sem um token, os visitantes que usam o Chrome padrão nunca veem suas ferramentas, porque a flag de teste local só afeta o navegador em que você a ativa. O trial começou no Chrome 149 e inicialmente estava previsto para durar até o Chrome 156. O Google solicitou a extensão até o Chrome 162, então verifique a data de término do seu token no console de Origin Trials.

Como posso testar ferramentas WebMCP sem construir um agente?

Use o Model Context Tool Inspector, uma extensão do Chrome listada na documentação do WebMCP do Chrome. Ela lista as ferramentas que uma página registrou e permite que você mesmo as execute. Ela também confirma se o navegador consegue interpretar seu JSON Schema e exibe o resultado ou o erro que cada ferramenta retorna. Sua página ainda precisa estar com o WebMCP ativado, seja pela flag de teste do WebMCP em chrome://flags, seja por um token de origin trial.

Posso reutilizar minhas definições de ferramentas MCP no WebMCP?

Muitas vezes você pode reutilizar as definições de entrada, mas não os handlers. Tanto as ferramentas MCP quanto as WebMCP descrevem suas entradas com JSON Schema, então o nome, a descrição e o formato dos argumentos de uma ferramenta geralmente podem ser aproveitados. O handler é diferente. Um handler MCP é executado no seu servidor, sob a autenticação que você implementar. Um handler WebMCP é JavaScript executado na página, com a sessão do usuário e o estado ativo do DOM.

O Angular oferece suporte ao WebMCP?

Sim, mas apenas de forma experimental. O suporte experimental do Angular permite registrar ferramentas WebMCP que seguem o ciclo de vida da injeção de dependência do Angular, e ele pode transformar Signal Forms em ferramentas sem que você precise escrever JSON Schemas manualmente. A documentação do Angular avisa que a especificação do WebMCP está mudando com frequência e que essas APIs podem mudar mesmo fora de versões major. Fixe a versão do Angular e esteja preparado para atualizar seu código.