Google Search Console MCP : ce que quatre serveurs MCP SEO exposent réellement

Les serveurs MCP de Google Search Console sont le moyen de faire lire vos données de recherche à un agent sans exporter un CSV au préalable. C'est la partie facile. La partie difficile, c'est de distinguer les serveurs entre eux, car tous se présentent de la même façon, et la différence n'apparaît que lorsqu'on leur demande ce qu'ils savent réellement faire.

Nous avons donc demandé. Le 12 septembre 2026, nous avons connecté quatre serveurs MCP SEO publiés, envoyé à chacun une requête tools/list, et compté ce qui revenait. Les nombres étaient 42, 21, 4 et 1.

Cet écart n'est pas un classement de qualité. C'est une décision de conception, et elle change ce que l'agent peut faire, ce qu'il vous coûte en contexte, et la quantité de vos données qui sort de votre périmètre.

Ce que nous avons testé, et comment

Méthode : chaque serveur a été lancé exactement comme sa propre documentation l'indique, via l'entrée et la sortie standard, ou via HTTP lorsque la documentation précisait ce mode. Nous avons envoyé la poignée de main initialize du protocole MCP, puis tools/list, et noté le nombre et les noms des outils. Nous n'avons utilisé de clés d'API que là où un serveur refusait de démarrer sans clé.

Un serveur, un paquet Search Console tiers, n'a pas terminé la poignée de main dans notre fenêtre de 50 secondes : il a donc été écarté plutôt que noté. Les listes d'outils changent à chaque version, alors traitez ces chiffres comme un instantané d'une matinée, pas comme une propriété permanente d'un fournisseur.

Les quatre conceptions, et à quoi sert chacune

L'enveloppe (21 outils). mcp-gsc prend l'API Search Console et enveloppe chaque rapport dans un outil nommé. Sa liste se lit comme la fiche de poste d'un analyste search : search_analytics, inspect_url, top_movers, quick_wins, cannibalization, content_decay, device_country_breakdown, ctr_anomalies, weekly_seo_report, indexing_coverage. Le gain : le modèle n'a jamais à construire une requête. Le prix : vous héritez de l'avis de quelqu'un d'autre sur ce qu'un rapport doit contenir, et rien hors de la liste ne peut être demandé.

Le miroir de toute la plateforme (42 outils). Le serveur d'Ahrefs expose la surface produit du fournisseur point d'accès par point d'accès : rank-tracker-overview, rank-tracker-competitors-overview, keywords-explorer-matching-terms, keywords-explorer-volume-history, batch-analysis. C'est la liste la plus riche que nous ayons mesurée, et la plus coûteuse en contexte, car chaque définition d'outil est chargée, qu'elle concerne la tâche ou non. C'est aussi celle qui montre le compromis le plus clairement : l'étendue des capacités contre une taxe permanente sur chaque prompt.

La passerelle (4 outils). Le serveur v3 de DataForSEO est allé dans la direction opposée. Il expose docs_index, docs_list_sections, docs_search, et un outil générique, api_request. Au lieu de nommer chaque point d'accès, il apprend au modèle à trouver la documentation puis à faire un appel authentifié. Quatre outils couvrent une API aux centaines de points d'accès, et le modèle paie le coût de la spécificité à l'appel, pas au chargement. Dans notre vérification, le point d'accès HTTP a renvoyé invalid auth sans identifiants et a répondu normalement avec. C'est le comportement souhaité.

Le serveur à outil unique (1 outil). seo-mcp-server renvoie exactement un outil, ai_content_detect. Il n'y a rien de mal à un petit serveur, mais il devrait être honnête sur ce qu'il est : une démo ou un contrôle isolé, pas un établi SEO. Si vous l'installez en attendant un rapport hebdomadaire, vous serez déçu d'une manière que les instructions d'installation n'ont jamais mentionnée.

Quatre archétypes. Deux d'entre eux passent à l'échelle d'un vrai travail de reporting, et chacun monte en puissance dans une direction différente.

Pourquoi le nombre d'outils est le mauvais titre

Deux serveurs au même nombre peuvent se comporter de façon totalement différente, car ce qui compte est la forme de la frontière, pas le chiffre.

L'enveloppe décide de vos questions à l'avance. C'est réellement utile quand l'API sous-jacente est pénible et que l'enveloppe encode une vraie expertise, et la liste de mcp-gsc fait exactement cela. Elle devient une limite au premier instant où votre question n'est pas dans la liste, et il n'y a aucun moyen de contourner.

La passerelle ne décide presque rien et pousse le travail vers le modèle. C'est plus souple et plus fragile. Le modèle peut atteindre n'importe quoi, ce qui veut dire qu'il peut atteindre le mauvais point d'accès, mal lire la forme de la réponse, et dépenser trois appels d'outil pour découvrir que le champ voulu porte un autre nom. Sur des questions simples, l'enveloppe est plus rapide. Sur des questions nouvelles, seule la passerelle répond.

Le test utile n'est pas « combien y a-t-il d'outils » mais « le serveur expose-t-il cette chose que je demande chaque semaine ». En travail de suivi de positions, c'est en général l'analyse de recherche avec ventilation par date et par appareil, plus l'inspection d'URL. L'enveloppe et la passerelle le couvrent. Le serveur à 42 outils le couvre, et couvre avec quarante autres choses dont vous n'userez pas aujourd'hui.

Les vérifications qui comptent vraiment avant d'installer quoi que ce soit

Lisez la portée des autorisations, pas la liste des fonctionnalités. Les serveurs Search Console héritent de ce que votre autorisation OAuth permet. Une autorisation en lecture seule, capable de lister les propriétés et de récupérer l'analyse de recherche, suffit pour le reporting et la surveillance. Tout ce qui propose de modifier des réglages, de soumettre un sitemap ou de demander une indexation écrit dans vos propriétés, et cela mérite une barre bien plus haute que « ce dépôt a des étoiles ».

Vérifiez ce qui quitte votre machine. Une passerelle qui transmet des identifiants d'API à un fournisseur a un profil de risque différent d'une enveloppe locale qui parle à l'API Google avec votre propre jeton. Les deux peuvent convenir. Mais une seule signifie qu'un tiers voit chaque mot-clé que vous récupérez.

Lancez le test de la réponse vide. Demandez au serveur une plage de dates sans données, par exemple une propriété que vous n'avez pas encore lancée. Un serveur bien fait renvoie un ensemble vide. Un serveur mal fait renvoie une erreur, et un agent qui reçoit une erreur invente souvent une explication plausible pour les données manquantes. Ce seul test attrape plus de problèmes que n'importe quelle relecture de code.

Deux serveurs peuvent exposer exactement le même rapport et différer complètement sur qui voit vos identifiants.

Vérifiez ce qui se passe quand un outil échoue. Les limites de débit sont réelles : Search Console autorise 1 200 requêtes par minute et par propriété, et une vague de tentatives de l'agent les consume à elle seule. Un serveur qui expose la limite est utilisable. Un serveur qui ne renvoie rien en silence apprend à votre agent que vous n'avez aucune impression, ce qui est pire qu'une erreur. La même limite façonne tout suiveur de positions maison, donc le budget de requêtes mérite une ligne dans le fichier de configuration.

Le brancher sur un agent

La configuration est la petite partie. Le placement est ce qui décide si vous en tirerez de la valeur.

{
  "mcpServers": {
    "gsc": {
      "command": "npx",
      "args": ["-y", "mcp-gsc"],
      "env": { "GSC_CREDENTIALS": "/path/to/service-account.json" }
    },
    "dataforseo": {
      "url": "http://localhost:3000/mcp",
      "headers": { "Authorization": "Basic <base64 login:password>" }
    }
  }
}

Trois règles que nous appliquons, classées par quantité de douleur évitée.

Un serveur par source de données. Deux serveurs qui prétendent chacun répondre aux questions de position produisent deux réponses, et l'agent choisira la plus plausible, pas la bonne. Donnez Search Console à l'enveloppe, les données SERP tierces à la passerelle, et notez quel champ fait autorité chez qui.

Gardez la définition du reporting hors du serveur. Les outils donnent à l'agent l'accès aux données. Ils ne lui donnent pas vos définitions : quelles propriétés comptent, quelles requêtes portent le revenu, et si la position est une moyenne de période ou un instantané quotidien. Cela appartient à un fichier d'instructions que l'agent lit avant d'appeler quoi que ce soit, et c'est la différence entre un résumé utile et une erreur confiante. Le workflow de rapport hebdomadaire est un exemple vivant de définitions qui vivent hors des outils.

Vérifiez le premier passage à la main. Récupérez une semaine d'analyse de recherche via le serveur et comparez-la à la même semaine dans l'interface Search Console. Si les chiffres ne concordent pas, vous avez un problème de plage de dates ou d'attribution, et tout rapport automatisé ensuite en hérite.

Point de vue Auspia : la question du MCP n'est pas « quel serveur est le meilleur ». Elle est « quelle frontière voulez-vous tracer entre votre agent et vos données ». L'enveloppe est un contrat que vous acceptez d'avance. La passerelle est une responsabilité que vous acceptez à chaque exécution. Laquelle des deux s'inscrit dans un workflow de positions plus large, c'est ce que le guide des capacités d'agent organise par tâche. Les deux sont légitimes, et l'équipe qui se brûle est celle qui a choisi sans remarquer qu'elle choisissait.

Questions fréquentes

Google publie-t-il un serveur MCP officiel pour Search Console ? Au 12 septembre 2026, nous n'en avons trouvé aucun dans les registres de paquets. Les serveurs Search Console que nous avons testés sont des projets communautaires ou d'éditeur posés sur l'API officielle. Ce qui est officiel, c'est la couche API, ce qui en soi n'est pas un défaut automatique, mais cela signifie que ce serveur est une dépendance de maintenance que vous choisissez.

Combien d'outils MCP sont trop nombreux pour une session d'agent ? Il n'y a pas de nombre fixe. La limite pratique est de savoir si la liste d'outils pousse vos instructions hors de la fenêtre de contexte. Charger un serveur à 42 outils pour une tâche qui en demande deux vous fait payer quarante définitions à chaque appel. Chargez des serveurs étroits pour la routine et larges pour l'exploration.

Peut-on utiliser MCP avec Search Console sans compte de service ? Oui, à condition que le serveur implémente le flux OAuth et que vous le terminiez une fois en local. La voie du compte de service est plus simple à automatiser et plus difficile à transmettre à une personne, donc les équipes font généralement tourner les deux : compte de service pour les exécutions planifiées et OAuth pour le travail ponctuel.

Sur quel serveur êtes-vous restés ? L'enveloppe, pour le rapport hebdomadaire, parce que les questions sont connues. La passerelle reste installée pour tout travail nécessitant une source de données que l'enveloppe ne couvre pas, et c'est la plus grande partie du travail intéressant et aucune des tâches de routine.

Auteur : Julian Mercer, chercheur en intégration MCP chez Auspia, sur plus de 40 chaînes d'outils d'agents. Il écrit sur les protocoles d'agents, les frontières d'outils et le coût opérationnel de relier des modèles de langage à des données vivantes.