¿Un MCP para CaptainDNS?

⚡TL;DR

El Model Context Protocol (MCP) es un protocolo abierto que permite a una IA hablar con herramientas externas (APIs, bases de datos, servicios SaaS) de forma estandarizada.

• Define un lenguaje común entre los modelos y las herramientas (los "servidores MCP").
• Evita rehacer una integración distinta para cada proveedor de IA.
• Abre la puerta a agentes reales capaces de llamar a CaptainDNS por sí mismos.

Este artículo sienta las bases: qué es un MCP, para qué sirve y por qué CaptainDNS decidió construir uno. Los siguientes artículos detallarán arquitectura, elecciones técnicas y los primeros casos de uso concretos, con un acceso anticipado para quienes quieran probar.

¿Por qué hablar de MCP antes de escribir una línea de código?

CaptainDNS ya es una herramienta muy especializada: DNS, correo, propagación, monitorización.
Un MCP, por sí solo, no hace "nada": es una capa de diálogo entre una IA y unas herramientas.

Antes de conectar uno con otro, conviene hacerse algunas preguntas sencillas:

• ¿Qué es exactamente un MCP?
• ¿Es un estándar universal o una tendencia pasajera?
• ¿Lo necesita todo el mundo o sólo ciertos perfiles (DevOps, SRE, equipos de entregabilidad, etc.)?
• Y sobre todo: ¿qué puede cambiar realmente para una herramienta como CaptainDNS?

Este artículo sirve de base para los siguientes: si entiendes lo que ocurre aquí, el resto (arquitectura, elecciones técnicas, demos) será mucho más claro.

¿Qué es el Model Context Protocol (MCP)?

Un protocolo para que la IA hable con tus herramientas

El MCP (Model Context Protocol) es un protocolo que define cómo:

• un host (una aplicación que integra un modelo de IA, por ejemplo un cliente de ChatGPT, un IDE o un agente interno),
• se conecta a uno o varios servidores MCP ("herramientas" expuestas vía MCP: una API, una base de datos, un servicio como CaptainDNS),
• y intercambia peticiones estructuradas (en la práctica JSON) para ejecutar acciones.

Se puede ver como:

un enchufe estándar para conectar una IA a herramientas, en lugar de una colección de cables propietarios distintos para cada proveedor.

La idea de fondo:

• la IA habla en lenguaje natural con el usuario,
• pero en cuanto tiene que actuar (consultar DNS, leer una base, llamar a una API) pasa por tools expuestos vía MCP.

Tres roles que recordar

Para el resto de los artículos, hay que tener este trío en mente:

• El host: la aplicación que aloja el modelo (ChatGPT, un IDE, un agente interno, etc.).
• El cliente MCP: la capa de ese host que sabe hablar MCP.
• El servidor MCP: el servicio que expone herramientas utilizables por la IA.

En nuestro caso, el servidor MCP será CaptainDNS, visto desde la IA como:

• "herramienta DNS/correo" accesible mediante un protocolo estándar,
• con tools como dns_lookup, dns_propagation, email_auth_audit, etc.

Algunos ejemplos de lo que permite un MCP

El MCP no se limita a CaptainDNS. Podemos imaginar servidores MCP para casi todo:

• Un MCP para una base de datos La IA puede listar tablas, ejecutar consultas SQL preparadas, analizar informes, sin exponer directamente las credenciales de la base.

• Un MCP para una herramienta DevOps La IA puede lanzar despliegues, leer logs, verificar el estado de servicios, consultar dashboards, etc.

• Un MCP para un CRM o una herramienta de negocio La IA puede encontrar un cliente, listar sus contratos, revisar un histórico de tickets, proponer un resumen para soporte.

• Un MCP para un filesystem o un almacenamiento de objetos La IA puede explorar un espacio de ficheros, leer ciertos documentos, proponer síntesis, sin salir del entorno controlado.

Lo que cambia respecto a integraciones "clásicas" es que:

• el modelo deja de estar encerrado en una simple ventana de chat,
• se convierte en una especie de coordinador de herramientas, capaz de encadenar varias acciones:
• llamar a un MCP "base de datos",
• luego a un MCP "monitorización",
• luego a un MCP "ticketing",
• y finalmente redactar un informe coherente.

¿Para qué sirve de verdad el MCP? (y dónde brilla)

1. Estandarizar integraciones IA ↔ herramientas

Sin MCP, cada integración se parece a:

• un esquema JSON diferente,
• un protocolo ligeramente distinto,
• una forma específica de declarar tools para cada proveedor (OpenAI, otros LLM, etc.).

Con MCP:

• escribes un solo servidor MCP,
• compatible con varios hosts (siempre que hablen MCP),
• lo que evita rehacer la misma integración tres veces.

Para un SaaS como CaptainDNS, es clave:
un único conector MCP bien diseñado permite, en teoría, hablar con varios ecosistemas de IA, actuales y futuros.

2. Dejar que los agentes trabajen "solos" (con guardarraíles)

Otro interés del MCP es que es agent-friendly.

Un agente de IA puede:

1. analizar la petición del usuario,
2. decidir qué tools MCP llamar,
3. planificar varias llamadas, ejecutarlas, analizar los resultados,
4. y volver al usuario sólo con un diagnóstico o un plan de acción.

El protocolo aporta un marco:

• los tools están descritos con precisión (nombre, parámetros, tipos),
• el host puede pedir confirmación del usuario antes de ciertas llamadas (por ejemplo, operaciones sensibles),
• todo se puede loguear y controlar.

3. Aislar y securizar el acceso a los sistemas

El MCP no es magia de seguridad, pero ayuda a:

• delimitar lo que la IA puede hacer:
  exponer un tool de sólo lectura, o muy limitado, en lugar de la API bruta.
• separar entornos:
  un MCP para prod, otro para preproducción, otro para un tenant dado.
• controlar los permisos:
  por ejemplo, un usuario puede autorizar a la IA a leer consultas de CaptainDNS, pero no a crear nuevas monitorizaciones.

¿Es el MCP "universal"?

El MCP aspira a ser un estándar abierto, no el protocolo único de todo el universo.

Concretamente:

• Está pensado para ser agnóstico respecto al proveedor de modelos de IA.
• Debe ser reutilizable por distintos tipos de aplicaciones (chat, IDE, agentes autónomos, etc.).
• No impide que coexistan otros enfoques (plugins propietarios, APIs directas, webhooks, etc.).

Se puede ver como:

una base común para las herramientas que quieren ser "AI-ready" sin apostarlo todo a un único ecosistema.

CaptainDNS se apoyará en esta base sin abandonar la interfaz web ni la API existente. El MCP llega como complemento, para quienes quieran ir más lejos.

¿Por qué un MCP para CaptainDNS?

La verdadera cuestión de este artículo: ¿qué aporta, específicamente, a una herramienta orientada a DNS y correo como CaptainDNS?

Aquí van algunas pistas que guiarán el desarrollo.

Del lado de CaptainDNS, el MCP se cuela entre el host de IA y la API Go existente:

1. Un copiloto DNS/correo en tu chat habitual

Imagina:

Analiza la propagación de los MX de example.com y dime si hay riesgo de pérdida de correos.

El agente de IA podría:

1. llamar a un tool dns_propagation expuesto por CaptainDNS vía MCP,
2. recuperar un estado multi-resolvedor,
3. responderte con:

• los resolvers con retraso,
• las IP en desacuerdo,
• un resumen de riesgos.

Mismo escenario para el correo:

Verifica SPF, DKIM y DMARC para example.com y explícame qué puede bloquear en Microsoft.

La IA llama entonces a email_auth_audit y devuelve una explicación comprensible, en lugar de un bloque de TXT.

2. Debug de incidentes más rápido

En caso de incidente:

• un dominio deja de resolver correctamente,
• un failover DNS no se propaga,
• ciertos proveedores dejan de recibir correos.

El agente puede:

1. revisar el histórico de consultas de CaptainDNS (vía un tool request_history),
2. relanzar pruebas dirigidas (lookup, propagación),
3. correlacionar los resultados,
4. proponer un diagnóstico inicial al humano (SRE, admin, consultor de entregabilidad, etc.).

CaptainDNS no sustituye la pericia, pero el MCP permite pre-masticar buena parte del trabajo.

3. Integrarse en pipelines y flujos existentes

Un MCP de CaptainDNS también podría ser usado por:

• pipelines CI/CD,
• workflows internos,
• asistentes de equipo (SRE, SecOps, soporte).

Por ejemplo:

• tras un despliegue de zona DNS, un agente de IA puede verificar:
• que los registros A/AAAA esperados responden en todas partes,
• que DMARC sigue coherente,
• y que ningún MX ha desaparecido.

Todo ello basándose en los tools de CaptainDNS en lugar de scripts caseros dispersos.

Lo que llega en los próximos artículos

Este primer artículo puso el decorado. Los siguientes serán más técnicos y concretos.

En el programa:

• Arquitectura del MCP de CaptainDNS
  Cómo se estructurará el "servidor MCP" de CaptainDNS, cómo hablará con la API existente, qué opciones de transporte y autenticación se elegirán.

• Diseño de los tools
  Cuáles serán los primeros tools expuestos (dns_lookup, dns_propagation, email_auth_audit, request_history, etc.), con sus parámetros y respuestas.

• Guardarraíles y seguridad
  Cómo limitar lo que la IA puede hacer, gestionar API keys, trazar peticiones, aislar entornos.

• Demostraciones concretas
  Escenarios completos: "incidente de correo", "migración DNS", "puesta en marcha de un nuevo dominio", pilotados en lenguaje natural pero ejecutados vía CaptainDNS.

CaptainDNS documentará las elecciones de arquitectura, los compromisos y las iteraciones a lo largo del desarrollo.
Y, una vez estable un primer núcleo, habrá un preestreno para los usuarios que quieran probar el MCP en sus propios entornos.

Glosario MCP

MCP (Model Context Protocol)

Protocolo que define cómo un modelo de IA puede interactuar con herramientas externas (APIs, bases de datos, servicios) a través de "servidores MCP".
Estandariza la descripción de tools, parámetros, respuestas y el diálogo con el host.

Host

Aplicación que contiene el modelo de IA y sirve de interfaz al usuario:

• aplicación de chat,
• IDE,
• agente autónomo,
• herramienta interna de empresa, etc.

Es el host quien decide cuándo y cómo se llaman los tools MCP.

Servidor MCP

Servicio que expone tools utilizables por el host vía MCP.

En el contexto de CaptainDNS, el servidor MCP expondrá herramientas DNS/correo (dns_lookup, dns_propagation, etc.) en formato MCP.

Tool

Acción específica que expone el servidor MCP, con:

• un nombre (dns_lookup),
• parámetros estructurados (domain, record_type, etc.),
• un esquema de respuesta.

El modelo de IA puede decidir llamarlo cuando lo necesite para responder al usuario.

LLM (Large Language Model)

Modelo de lenguaje de gran tamaño, capaz de:

• entender instrucciones en lenguaje natural,
• generar texto,
• planificar acciones (como llamar a tools MCP),
• explicar sus resultados.

El LLM, por sí mismo, no "ve" directamente la base de datos o el DNS: pasa por los tools.

JSON-RPC

Protocolo ligero basado en JSON para hacer llamadas de tipo "petición/respuesta" (un poco como una API, pero estandarizada para intercambios estructurados).
El MCP reutiliza una variante de JSON-RPC para que host y servidores MCP puedan dialogar de forma previsible.

Preguntas frecuentes sobre el MCP

¿Necesito un MCP para usar una IA?

No. Se puede usar una IA sin MCP, únicamente a través de una interfaz de chat clásica.
El MCP resulta interesante en cuanto quieres conectar la misma IA a varias herramientas, o permitir que los agentes encadenen acciones de forma fiable.

¿Necesito un MCP para usar CaptainDNS?

Tampoco. CaptainDNS sigue siendo totalmente utilizable vía su interfaz web y su API.
El MCP es un complemento para los usuarios que quieran integrar CaptainDNS en asistentes de IA o workflows automatizados.

¿Tengo que ser desarrollador para beneficiarme de un MCP?

No necesariamente. El despliegue inicial (conectar el MCP a un host, configurar la autenticación) es más sencillo si lo hace un desarrollador o DevOps.
Pero una vez en marcha, un MCP bien diseñado permite a perfiles no técnicos pilotear acciones complejas en lenguaje natural.

¿El MCP está ligado a un proveedor de IA específico?

El objetivo del MCP es precisamente ser agnóstico respecto al proveedor de IA.
Un mismo servidor MCP puede, en teoría, ser usado por varios hosts y varios modelos sin reescribir la integración cada vez.

¿El MCP sustituye a los plugins o a las APIs clásicas?

No. Las APIs siguen siendo la base. El MCP suele apoyarse en APIs ya existentes y sirve como capa de orquestación adaptada a los modelos de IA.
Se puede ver como una forma más limpia y portable de exponer funcionalidades a un ecosistema de IA.