Não existe MCP oficial do Search Console. O que isso muda
Nenhum servidor MCP do Search Console é publicado pelo Google. Os que existem são de terceiro, então a responsabilidade por manutenção, segurança e continuidade recai sobre quem escreveu e sobre quem opera cada um.
O Google não publica nem mantém um servidor MCP oficial para o Search Console. Todo servidor MCP que conecta o Search Console a um assistente de IA hoje é construído por terceiro, seja como projeto aberto que roda na sua máquina, seja como serviço hospedado por outra empresa. Isso muda quem responde quando algo quebra, quem decide quais ferramentas existem, e quem você precisa confiar antes de autorizar o acesso à sua conta Google.
Por que não existe um MCP oficial do Search Console?
Não há um MCP oficial porque o Google não publicou um, e não há indicação pública de que vá publicar um no curto prazo. O MCP (Model Context Protocol) é um padrão aberto criado pela Anthropic em novembro de 2024; o Google adota o protocolo em outros contextos, mas isso não implica que cada API do Google ganhe automaticamente um servidor MCP mantido pela própria empresa. A Search Console API existe desde antes do MCP e continua sendo uma API REST comum, que qualquer desenvolvedor pode envolver num servidor MCP por conta própria.
Quem constrói os servidores MCP do Search Console que existem hoje?
Dois tipos de terceiro constroem esses servidores: desenvolvedores independentes que publicam código aberto, e empresas que operam um serviço hospedado.
O exemplo de referência do primeiro tipo é o mcp-gsc, de Amin Foroutan, publicado sob licença MIT, com 21 ferramentas cobrindo propriedades, desempenho de busca, inspeção de URL e sitemaps. Qualquer pessoa pode ler o código, rodar na própria máquina ou até criar uma versão modificada.
O segundo tipo hospeda esse mesmo tipo de servidor num transporte remoto (Streamable HTTP), com um aplicativo OAuth próprio já registrado e verificado no Google, para que você não precise abrir o Google Cloud Console. O MCP Search Console é um exemplo desse formato; a diferença entre os dois formatos no uso diário, não só no setup, está em MCP hospedado ou local.
Como nenhum dos dois é o Google, cada um decide sozinho quais ferramentas implementar, com que nomes, e com que comportamento em casos de borda como erro da API ou dado provisório.
O que muda quando o servidor não é oficial?
Quatro coisas mudam: suporte, continuidade, superfície de confiança e ritmo de atualização.
Suporte: não existe um canal oficial do Google para reportar bug de um servidor MCP de terceiro. O caminho é o issue tracker do projeto aberto, ou o suporte do serviço hospedado, cada um com o próprio prazo de resposta.
Continuidade: um projeto open source mantido por uma pessoa pode parar de receber atualização a qualquer momento, sem aviso. Antes de depender de um servidor específico para um fluxo de trabalho importante, vale checar a atividade recente do repositório: quando foi o último commit, quantas issues abertas sem resposta.
Superfície de confiança: como o servidor não vem do Google, autorizar o acesso à sua conta significa confiar no código de quem escreveu (se for local) ou na infraestrutura de quem hospeda (se for hospedado). O escopo pedido continua sendo o mesmo, auth/webmasters (veja o que ele libera de verdade), mas quem tem acesso ao token depois da autorização muda conforme o operador.
Ritmo de atualização: quando a Search Console API do Google muda (um campo novo no relatório de Desempenho, por exemplo), a atualização do servidor MCP depende de quem mantém aquele projeto notar a mudança e ajustar o código. Não há garantia de prazo, porque não existe contrato de suporte entre o Google e o mantenedor de um projeto de terceiro.
Como avaliar um servidor MCP do Search Console antes de conectar?
Três checagens cobrem a maior parte do risco. Primeiro, o escopo pedido na tela de autorização do Google: deve ser só auth/webmasters (ou a versão somente leitura equivalente), sem Gmail, Drive ou outro produto junto. Segundo, o status de verificação do aplicativo OAuth: um app não verificado mostra um aviso do Google antes da autorização, o que não significa necessariamente má-fé, mas indica que o desenvolvedor ainda não passou pela revisão do Google para aquele escopo sensível. Terceiro, quem responde pelo código: um repositório público com licença clara e atividade recente, no caso de projeto aberto; documentação de segurança específica (onde o token fica, o que é registrado, como revogar, como esta), no caso de serviço hospedado.
Nenhuma dessas checagens garante que nada vai dar errado. Elas reduzem a chance de conectar algo que ninguém mantém, ou que pede mais acesso do que o necessário.
Isso significa que um MCP não oficial é menos seguro que um oficial seria?
Não necessariamente. Um projeto aberto e auditável, com código visível para qualquer pessoa revisar, pode ser tão confiável quanto um produto oficial, às vezes mais, porque a transparência do código compensa a ausência de um selo do Google. A diferença não é de segurança inerente, é de responsabilidade: com um MCP oficial, o Google responderia por manutenção, suporte e continuidade. Sem ele, essa responsabilidade fica distribuída entre quem escreve o código, quem opera o serviço, e quem decide confiar antes de autorizar.
Resumo
- O Google não publica nem mantém um MCP oficial do Search Console; todo servidor disponível hoje é de terceiro.
- Existem dois formatos de terceiro: projeto aberto que roda na sua máquina (como o
mcp-gsc) e serviço hospedado que roda num servidor remoto. - Sem um MCP oficial, suporte, continuidade e ritmo de atualização dependem de quem mantém cada projeto, não de um contrato com o Google.
- Antes de conectar, vale checar o escopo pedido na autorização, o status de verificação do aplicativo OAuth, e quem responde pelo código ou pela operação do serviço.
- Não ser oficial não torna um servidor automaticamente menos seguro; troca a garantia de um contrato pela responsabilidade de avaliar quem construiu e quem opera aquele servidor específico.