Un MCP pour CaptainDNS ?

⚡TL;DR

Le Model Context Protocol (MCP) est un protocole ouvert qui permet à une IA de discuter avec des outils externes (API, bases de données, services SaaS) de manière standardisée.

• Il définit un langage commun entre les modèles et les outils (les "MCP servers").
• Il évite de refaire une intégration différente pour chaque fournisseur d'IA.
• Il ouvre la porte à de vrais agents capables d'appeler CaptainDNS tout seuls.

Cet article pose les bases : qu'est-ce qu'un MCP, à quoi ça sert, et pourquoi CaptainDNS a décidé d'en développer un. Les prochains articles détailleront l'architecture, les choix techniques et les premiers cas d'usage concrets, avec une avant-première pour les utilisateurs qui voudront tester.

Pourquoi parler de MCP avant même d'écrire une ligne de code ?

CaptainDNS est déjà un outil très spécialisé : DNS, e-mail, propagation, monitoring.
Un MCP, lui, ne fait "rien" tout seul : c'est une couche de dialogue entre une IA et des outils.

Avant de brancher l'un sur l'autre, il est utile de poser quelques questions simples :

• Qu'est-ce qu'un MCP exactement ?
• Est-ce un standard "universel" ou une mode de plus ?
• Est-ce que tout le monde en a besoin, ou seulement certains profils (DevOps, SRE, équipe "délivrabilité", etc.) ?
• Et surtout : qu'est-ce que cela peut réellement changer pour un outil comme CaptainDNS ?

Cet article sert de base pour tous les suivants : si tu comprends ce qui se passe ici, la suite (architecture, choix techniques, démos) sera beaucoup plus claire.

C'est quoi le Model Context Protocol (MCP) ?

Un protocole pour que l'IA parle à tes outils

Le MCP (Model Context Protocol) est un protocole qui définit comment :

• un hôte (une application qui embarque un modèle d'IA, par exemple un client ChatGPT, un IDE ou un agent interne),
• se connecte à un ou plusieurs serveurs MCP (des "outils" exposés via MCP : une API, une base de données, un service comme CaptainDNS),
• et échange des requêtes structurées (sous forme de JSON, en pratique) pour exécuter des actions.

On peut voir ça comme :

une "prise standard" pour brancher une IA sur des outils, plutôt qu'une collection de câbles propriétaires différents pour chaque fournisseur.

L'idée de fond :

• l'IA discute en langage naturel avec l'utilisateur,
• mais dès qu'il faut agir (interroger du DNS, lire une base, appeler une API), elle passe par des tools exposés via MCP.

Trois rôles à retenir

Pour la suite des articles, on peut garder ce trio en tête :

• Le host : l'application qui héberge le modèle (ChatGPT, un IDE, un agent interne, etc.).
• Le MCP client : la couche dans ce host qui sait parler MCP.
• Le MCP server : le service qui expose des outils utilisables par l'IA.

Dans notre cas, le MCP server sera CaptainDNS, vu depuis l'IA :

• "Outil DNS/e-mail" accessible via un protocole standard,
• avec des tools comme dns_lookup, dns_propagation, email_auth_audit, etc.

Quelques exemples de ce que permet un MCP

Le MCP n'est pas limité à CaptainDNS. On peut imaginer des MCP servers pour à peu près tout :

• Un MCP pour une base de données L'IA peut lister des tables, exécuter des requêtes SQL préparées, analyser des rapports, sans exposer directement les identifiants de la base.

• Un MCP pour un outil DevOps L'IA peut lancer des déploiements, lire des logs, vérifier des statuts de services, consulter des dashboards, etc.

• Un MCP pour un CRM ou un outil métier L'IA peut retrouver un client, lister ses contrats, vérifier un historique de tickets, proposer un résumé pour le support.

• Un MCP pour un filesystem ou un stockage objet L'IA peut explorer un espace de fichiers, lire certains documents, proposer des synthèses, sans sortir de l'environnement contrôlé.

Ce qui change par rapport aux intégrations "classiques", c'est que :

• le modèle n'est plus enfermé dans une simple fenêtre de chat,
• il devient une sorte de coordinateur d'outils, capable de composer plusieurs actions :
• appeler un MCP "base de données",
• puis un MCP "monitoring",
• puis un MCP "ticketing",
• et finalement rédiger un compte rendu cohérent.

À quoi sert vraiment le MCP ? (et où il brille)

1. Standardiser les intégrations IA ↔ outils

Sans MCP, chaque intégration ressemble à :

• un schéma JSON différent,
• un protocole légèrement différent,
• une manière spécifique de déclarer les outils pour chaque fournisseur (OpenAI, autre LLM, etc.).

Avec MCP :

• tu écris un seul serveur MCP,
• compatible avec plusieurs hosts (tant qu'ils parlent MCP),
• ce qui évite de refaire trois fois la même intégration.

Pour un SaaS comme CaptainDNS, c'est un point clé :
un seul connecteur MCP bien conçu permet, en théorie, de parler à plusieurs écosystèmes IA, actuels et futurs.

2. Laisser les agents travailler "tout seuls" (avec garde-fous)

Un autre intérêt du MCP est d'être agent-friendly.

Un agent IA peut :

1. analyser la demande de l'utilisateur,
2. décider quels tools MCP appeler,
3. planifier plusieurs appels, les exécuter, analyser les résultats,
4. et ne revenir vers l'utilisateur qu'avec un diagnostic ou un plan d'action.

Le protocole fournit un cadre :

• les tools sont décrits précisément (nom, paramètres, types),
• le host peut demander la confirmation de l'utilisateur avant certains appels (par exemple, des opérations sensibles),
• tout ce qui se passe peut être loggé et contrôlé.

3. Isoler et sécuriser l'accès aux systèmes

Le MCP ne "magique" pas la sécurité, mais il aide à :

• délimiter ce que l'IA peut faire :
  exposer un tool read-only, ou très limité, plutôt que l'API brute.
• séparer les environnements :
  un MCP pour la prod, un autre pour la préproduction, un autre pour un tenant donné.
• contrôler les permissions :
  par exemple, un user peut autoriser l'IA à lire des requêtes CaptainDNS, mais pas à créer de nouvelles surveillances.

Est-ce que le MCP est "universel" ?

Le MCP vise à être un standard ouvert, pas le protocole unique de tout l'univers.

Concrètement :

• Il est pensé pour être agnostique au fournisseur de modèles d'IA.
• Il devrait être réutilisable par différents types d'applications (chat, IDE, agents autonomes, etc.).
• Il n'empêche pas d'autres approches de coexister (plugins propriétaires, APIs directes, webhooks, etc.).

On peut donc le voir comme :

un socle commun pour les outils qui veulent être "AI-ready" sans tout miser sur un seul écosystème.

CaptainDNS va s'appuyer sur ce socle, sans abandonner l'interface web ni l'API existante. Le MCP vient en plus, pour ceux qui veulent aller plus loin.

Pourquoi un MCP pour CaptainDNS ?

La vraie question de ce blog : qu'est-ce que ça apporte, spécifiquement, pour un outil orienté DNS et e-mail comme CaptainDNS ?

Voici quelques pistes qui vont guider le développement.

Côté CaptainDNS, le MCP se glisse entre l'interface IA (host) et l'API Go existante :

1. Un copilote DNS/e-mail dans ton chat habituel

Imagine :

Analyse la propagation des MX de example.com et dis-moi s'il y a un risque de perte de mails.

L'agent IA pourrait :

1. appeler un tool dns_propagation exposé par CaptainDNS via MCP,
2. récupérer un état multi-résolveurs,
3. te répondre avec :

• les résolveurs en retard,
• les IP en désaccord,
• un résumé des risques.

Même scénario pour l'e-mail :

Vérifie SPF, DKIM et DMARC pour example.com et explique-moi ce qui bloque potentiellement chez Microsoft.

L'IA appelle alors email_auth_audit et te rend une explication compréhensible, plutôt qu'un bloc de TXT.

2. Debug d'incidents plus rapide

En cas d'incident :

• un domaine ne résout plus correctement,
• une bascule DNS ne se propage pas,
• des mails n'arrivent plus sur certains providers.

L'agent peut :

1. revoir l'historique des requêtes CaptainDNS (via un tool request_history),
2. relancer des tests ciblés (lookup, propagation),
3. corréler les résultats,
4. proposer un diagnostic initial à l'humain (SRE, admin, consultant deliverability, etc.).

CaptainDNS ne remplace pas l'expertise, mais le MCP permet de pré-mâcher une bonne partie du travail.

3. Intégration dans des pipelines et workflows existants

Un MCP CaptainDNS pourra aussi être utilisé par :

• des pipelines CI/CD,
• des workflows internes,
• des assistants d'équipe (SRE, SecOps, support).

Par exemple :

• après un déploiement de zone DNS, un agent IA peut vérifier :
• que les enregistrements A/AAAA attendus répondent partout,
• que DMARC reste cohérent,
• et qu'aucun MX n'a disparu.

Le tout en s'appuyant sur les tools CaptainDNS au lieu de scripts maison dispersés.

Ce qui va arriver dans les prochains articles

Ce premier article posait le décor. La suite sera plus technique et plus concrète.

Au programme :

• Architecture du MCP CaptainDNS
  Comment sera structuré le "MCP server" CaptainDNS, comment il parlera à l'API existante, quels choix de transport et d'authentification seront faits.

• Design des tools
  Quels seront les premiers tools exposés (dns_lookup, dns_propagation, email_auth_audit, request_history, etc.), avec leurs paramètres et leurs réponses.

• Garde-fous et sécurité
  Comment limiter ce que l'IA peut faire, gérer les API keys, tracer les requêtes, isoler les environnements.

• Démonstrations concrètes
  Des scénarios complets : "incident e-mail", "migration DNS", "mise en place d'un nouveau domaine", pilotés en langage naturel, mais exécutés via CaptainDNS.

CaptainDNS documentera les choix d'architecture, les compromis et les itérations au fil du développement.
Et, une fois un premier noyau stable, il y aura une avant-première pour les utilisateurs qui voudront tester le MCP dans leurs propres environnements.

Glossaire MCP

MCP (Model Context Protocol)

Protocole qui définit comment un modèle d'IA peut interagir avec des outils externes (APIs, bases de données, services) via des "serveurs MCP".
Il standardise la description des tools, des paramètres, des réponses, et le dialogue avec le host.

Host (hôte)

Application qui contient le modèle d'IA et qui sert d'interface à l'utilisateur :

• application de chat,
• IDE,
• agent autonome,
• outil interne d'entreprise, etc.

C'est le host qui décide quand et comment les tools MCP sont appelés.

MCP server (serveur MCP)

Service qui expose des tools utilisables par le host via MCP.

Dans le contexte CaptainDNS, le MCP server sera un service qui expose des outils DNS/e-mail (dns_lookup, dns_propagation, etc.) au format MCP.

Tool (outil)

Action spécifique que le MCP server expose, avec :

• un nom (dns_lookup),
• des paramètres structurés (domain, record_type, etc.),
• un schéma de réponse.

Le modèle d'IA peut choisir de l'appeler lorsqu'il en a besoin pour répondre à l'utilisateur.

LLM (Large Language Model)

Modèle de langage de grande taille, capable de :

• comprendre des instructions en langage naturel,
• générer du texte,
• planifier des actions (comme appeler des tools MCP),
• expliquer ses résultats.

Le LLM, en lui-même, ne "voit" pas directement la base de données ou le DNS : il passe par les tools.

JSON-RPC

Protocole léger basé sur JSON pour faire des appels de type "requête/réponse" (un peu comme une API, mais standardisée pour des échanges structurés).
Le MCP réutilise une variante de JSON-RPC pour que host et MCP servers puissent discuter de manière prévisible.

Questions fréquentes sur le MCP

Ai-je besoin d'un MCP pour utiliser une IA ?

Non. On peut très bien utiliser une IA sans MCP, uniquement via une interface de chat classique.
Le MCP devient intéressant dès que l'on veut connecter la même IA à plusieurs outils, ou permettre à des agents de enchaîner des actions de manière fiable.

Ai-je besoin d'un MCP pour utiliser CaptainDNS ?

Non plus. CaptainDNS reste pleinement utilisable via son interface web et son API.
Le MCP vient en complément, pour les utilisateurs qui souhaitent intégrer CaptainDNS dans des assistants IA ou des workflows automatisés.

Faut-il être développeur pour bénéficier d'un MCP ?

Pas forcément. Le déploiement initial (brancher le MCP sur un host, configurer l'authentification) est plus simple si un développeur ou un DevOps s'en occupe.
Mais une fois en place, un MCP bien conçu permet à des profils non techniques de piloter des actions complexes en langage naturel.

Le MCP est-il lié à un fournisseur d'IA spécifique ?

Le but du MCP est justement d'être agnostique par rapport au fournisseur d'IA.
Un même MCP server peut, en théorie, être utilisé par plusieurs hosts et plusieurs modèles, sans réécrire toute l'intégration à chaque fois.

Le MCP remplace-t-il les plugins ou les APIs classiques ?

Non. Les APIs restent la base. Le MCP s'appuie souvent sur des APIs déjà existantes et sert de couche d'orchestration adaptée aux modèles d'IA.
On peut le voir comme une façon plus propre et plus portable d'exposer des fonctionnalités à un écosystème d'IA.