WebMCP Funciona No Chrome. Minhas 400 Chamadas Diárias De Ferramentas Não.

Google I/O 2026 lançou o WebMCP e metade da linha do tempo da AI no Twitter está chamando isso de "o novo padrão MCP." Não é. É um protocolo com escopo de navegador que resolve um problema completamente diferente do que os servidores MCP atualmente em execução no seu VPS às 3 da manhã. Aqui está o limite que o Google enterrou na documentação, e como decidir de que lado dele seu agente pertence.

O Que O WebMCP Realmente É (E Não É)

WebMCP é um protocolo de ferramenta com escopo de navegador. Ele expõe ferramentas a um agente de dentro de uma aba do Chrome — as ferramentas vivem na página, a autenticação é a sessão ativa do usuário, e o runtime é o próprio navegador. Essa é toda a área de superfície.

Quando o Google diz "web agente", eles se referem a um agente que opera dentro de uma aba que o usuário já tem aberta, usando os cookies e tokens OAuth já carregados. Esse é um padrão legítimo e útil:

• Fluxos de reserva — o agente preenche um formulário de múltiplas etapas em um site no qual o usuário está logado
• Dashboards — o agente puxa um gráfico, exporta, insere em um documento
• Copilotos em aplicativos — produto SaaS envia ferramentas que seu próprio agente de usuários pode chamar
• Preenchimento de formulários e assistentes com escopo de página

O que o WebMCP não é: um substituto para os servidores MCP stdio e HTTP que estão rodando headless na sua máquina ou VPS. Diferente runtime, diferente modelo de autenticação, diferente ciclo de vida. Chamar isso de "o novo MCP" é como chamar um service worker de "o novo backend." Mesma família de protocolos, alvo de implantação completamente diferente.

A Divisão Que Realmente Importa

Há exatamente uma pergunta que você precisa responder para escolher corretamente:

Um humano está olhando para a tela quando o agente é executado?

Se sim → WebMCP está na mesa.
Se não → você precisa de um MCP real do lado do servidor.

É isso. Tudo o mais é barulho de retweet.

Eu executo três servidores MCP em produção. Triagem do Gmail, mensagens do Telegram, faturamento. Eles estão em uma caixa WSL Ubuntu, rodam headless como serviços systemd, e entre eles lidam com mais de 400 chamadas de ferramentas por dia. Nenhuma dessas chamadas envolve um navegador. Não há sessão de usuário. Não há aba. O agente acorda em cron ou um webhook, puxa e-mails, decide o que importa, rascunha respostas, envia uma notificação do Telegram, gera uma fatura, volta a dormir.

WebMCP não pode fazer nada disso. Não porque está quebrado — porque está limitado a um runtime onde um humano está presente.

Como É Um Verdadeiro MCP Do Lado Do Servidor

Aqui está a forma de um dos meus servidores de produção, despido até os ossos. Este é o servidor de triagem do Gmail que roda em um cron de 5 minutos e processa a caixa de entrada antes de eu acordar:

# gmail_triage_server.py — servidor MCP stdio, roda como serviço systemd
from mcp.server import Server
from mcp.server.stdio import stdio_server
from google.oauth2.credentials import Credentials
from googleapiclient.discovery import build

app = Server("gmail-triage")

# Credenciais carregadas do disco uma vez na inicialização.
# Sem navegador, sem sessão de usuário — uma conta de serviço / token de atualização.
creds = Credentials.from_authorized_user_file("/etc/agents/gmail.json")
gmail = build("gmail", "v1", credentials=creds)

@app.tool()
async def list_unread(max_results: int = 50) -> list[dict]:
    resp = gmail.users().messages().list(
        userId="me", q="is:unread -category:promotions", maxResults=max_results
    ).execute()
    return resp.get("messages", [])

@app.tool()
async def get_message(message_id: str) -> dict:
    return gmail.users().messages().get(userId="me", id=message_id, format="