MCP servers de Chrome DevTools

O Chrome DevTools MCP coloca o painel do DevTools que você já conhece na frente de um agente de IA. Enquanto a maioria dos servidores de navegador serve para clicar e digitar, este serve para descobrir por que uma página está lenta, o que ela registra em log, o que ela requisita e o que ela mantém na memória. Ele é publicado pela organização ChromeDevTools no GitHub, tem 55.670 estrelas e é licenciado sob Apache-2.0.

Instalamos a versão 1.13.0, publicada em 11 de novembro de 2026, e fizemos duas coisas em 14 de novembro de 2026: listamos as ferramentas dele com opções diferentes por meio do MCP Inspector e o conduzimos com um pequeno cliente MCP para gravar um trace de performance e rodar o Lighthouse no hostedmcp.org, nosso próprio site. Os números abaixo vêm dessas execuções.

Instale

Você precisa do Node.js 20.19 ou mais recente e do Chrome. O navegador inicia na primeira chamada de ferramenta que precisar dele, não quando o servidor inicia.

Claude Code:

claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --isolated --no-usage-statistics

Cursor, Claude Desktop, Windsurf e outros clientes configurados por JSON:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["chrome-devtools-mcp@latest", "--isolated", "--no-usage-statistics"]
    }
  }
}

Codex:

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --isolated --no-usage-statistics

As duas flags são nossa recomendação, não padrões. --isolated dá a cada sessão um perfil temporário; sem ela, o servidor mantém um perfil persistente em ~/.cache/chrome-devtools-mcp/chrome-profile que não é limpo entre execuções. --no-usage-statistics desativa as estatísticas de uso que o servidor envia ao Google por padrão. Nosso config builder gera a mesma entrada para vários clientes.

O primeiro prompt sugerido no README é um bom teste: "Check the performance of https://developers.chrome.com".

As ferramentas, contadas

tools/list na 1.13.0 retornou 33 ferramentas sem opções, e as definições das ferramentas somaram 31.498 bytes. Com --slim, retornou três: navigate, evaluate e screenshot, em 1.042 bytes.

Cada grupo pode ser desativado com uma flag como --categoryEmulation=false. Outros ficam desativados até você ativá-los: mocking de rede, extensões, automação de PWA, autenticadores WebAuthn virtuais e ferramentas que uma página expõe por conta própria via WebMCP. Ative apenas o que a tarefa precisa; 31 KB de definições é pouco perto de alguns servidores, mas é enviado a cada requisição.

O que um trace retorna

Iniciamos o servidor em modo headless, abrimos https://hostedmcp.org/ com new_page, depois chamamos performance_start_trace com reload e autoStop ativados e, por fim, lighthouse_audit.

A chamada de trace levou cerca de 6 segundos e retornou 9.436 bytes de texto. Ela reportou:

Em seguida, listou os insights encontrados, cada um com uma explicação e, quando aplicável, uma economia estimada: detalhamento do LCP, requisições que bloqueiam a renderização (25 ms de FCP e LCP), a árvore de dependência de rede, entrega de imagens, terceiros, tempos de cache e JavaScript legado. O agente pode chamar performance_analyze_insight em qualquer um deles para obter detalhes. A resposta termina com uma descrição do próprio formato de call-tree, para que o modelo consiga ler os dados de flame chart que vêm a seguir.

lighthouse_audit levou cerca de 7 segundos e retornou 6.687 bytes: acessibilidade 94, boas práticas 100, SEO 100 e uma quarta categoria, navegação agêntica, com 67. Quatro auditorias falharam. A primeira foi contraste de cores: doze elementos, entre eles o rótulo de busca do nosso header, com uma proporção de 4,33 onde 4,5 é exigido. Então a ferramenta fez o seu trabalho; temos uma correção a fazer.

Duas observações sobre esses números. O time to first byte de 0,8 ms significa que a página veio de um cache de edge aquecido; uma requisição a frio seria mais lenta. E, como passamos --no-performance-crux, o trace não reportou dados de campo de usuários reais; por padrão, o servidor consulta a URL da página no dataset CrUX do Google.

A armadilha do pageId

Nossa primeira execução mediu about:blank. Na versão 1.13.0, as ferramentas de página recebem um pageId, e uma nova sessão começa com uma página em branco como número 1. Nossa chamada new_page abriu o site como página 2 e a marcou como selecionada, mas passamos 1. O trace reportou, obedientemente, um CLS de 0 para uma página vazia. Os agentes costumam chamar list_pages primeiro e acertar isso; se um trace reportar about:blank, é por isso.

Use seu próprio Chrome

Por padrão, o servidor inicia o próprio Chrome. Ele também pode se conectar a um que já está em execução:

• --autoConnect conecta ao Chrome 144 ou mais recente depois que você habilita a depuração remota em chrome://inspect/#remote-debugging.
• --browserUrl http://127.0.0.1:9222 conecta a um Chrome iniciado com --remote-debugging-port=9222.

Conectar ao seu navegador do dia a dia dá ao agente seus logins, cookies e abas abertas. É exatamente o que você quer quando precisa que ele depure uma página atrás de login, e o risco em qualquer outra situação. Use um perfil separado do Chrome para isso.

Privacidade e segurança

O servidor exibe um aviso ao iniciar: ele "expõe o conteúdo da instância do navegador aos clientes MCP, permitindo que eles inspecionem, depurem e modifiquem qualquer dado no navegador ou no DevTools". Leve isso ao pé da letra. Vale a pena mudar três padrões:

• Estatísticas de uso vão para o Google, a menos que você passe --no-usage-statistics. Elas também ficam desativadas quando a variável de ambiente CI está definida.
• Consultas ao CrUX: as ferramentas de performance podem enviar as URLs que você rastreia para a API CrUX do Google. Use --no-performance-crux para URLs internas ou de staging.
• Perfil: o perfil padrão é persistente. Use --isolated a menos que você precise de estado entre sessões.

evaluate_script executa JavaScript na página, e as páginas podem conter textos direcionados ao modelo. Aprove você mesmo a navegação para sites desconhecidos. Também notamos que a 1.13.0 limita a leitura e a escrita de arquivos, como traces e screenshots salvos, à pasta temporária do sistema quando o cliente não compartilha as raízes do workspace; --allow-unrestricted-paths remove essa limitação. Deixe-a ativa. Mais em segurança do MCP.

Chrome DevTools MCP ou Playwright MCP

Nenhum dos projetos publicou uma comparação, então essa divisão é nossa: Playwright MCP quando o trabalho do agente é usar o site, Chrome DevTools MCP quando o trabalho é entender por que o site se comporta daquela forma. Os dois funcionam lado a lado; nosso guia do Playwright MCP cobre a outra metade.

Quando não funciona

Os servidores Chrome DevTools do nosso catálogo, com as pontuações das verificações, estão listados no topo desta página.