¿Qué es un registrador de dominios nativo para agentes?

Los registradores de dominios cuentan con interfaces de programación de aplicaciones desde hace mucho tiempo. Extensible Provisioning Protocol (EPP), el lenguaje de máquina a máquina que los registradores usan para comunicarse con los registros, alcanzó el estatus de Proposed Standard en marzo de 2004 —hace más de dos décadas—. Desde entonces, todo Registrador acreditado por ICANN que se apoya en él ha tenido alguna API REST o SOAP para comprobar la disponibilidad, enviar una solicitud de registro y actualizar datos. Así que la respuesta honesta a «¿este registrador tiene API?» es, para casi todos los registradores del mercado: sí, y desde hace años.

Pero esa resulta ser la pregunta equivocada. Un Agente de IA que intenta registrar un dominio en tu nombre no falla porque al registrador le falte una API. Falla porque la API se diseñó para un desarrollador que lee una vez la documentación, escribe a mano el código de integración y lo lanza; no para un sistema que debe descubrir la API durante la ejecución, decidir qué ha ocurrido a partir de una respuesta JSON y completar una compra sin que nadie supervise una página de pago. Son requisitos distintos, y cumplir el segundo grupo es lo que este artículo llama nativo para agentes.

Este artículo define el término con precisión, presenta una lista para evaluar cualquier registrador —o cualquier API— con ese criterio y la aplica con franqueza a las plataformas disponibles en 2026, incluida Namefi. Para comparar las plataformas entre sí, en lugar de ver la definición, consulta Cloudflare vs Name.com vs Namefi: registradores nativos para agentes o la guía más amplia de plataformas de dominios agénticas basadas en IA. Si todavía concibes «IA y dominios» como un generador de nombres que propone cadenas aptas para una marca, la lista de abajo muestra cuánto más alto está el listón de lo nativo para agentes; consulta Más allá del generador de nombres de dominio con IA: la era de los agentes para ver esa diferencia en detalle.

Por qué «tener una API» y «ser nativo para agentes» no son la misma afirmación

Una API de registrador tradicional presupone que una persona participa en el diseño, no en la ejecución. Un desarrollador abre una cuenta, lee una página de referencia escrita para personas, copia un ejemplo de código y fija en su aplicación el endpoint, el encabezado de autenticación y la forma esperada de la respuesta. Una vez hecho eso, la integración se ejecuta sin supervisión, pero solo porque una persona ya hizo el trabajo interpretativo. No hay nada en la propia API que resulte legible para un sistema que llega sin contexto, sin una integración previa, y debe averiguar en ese momento qué operaciones existen y cómo llamarlas.

Un agente llega sin contexto continuamente. Cada conversación con un agente de programación y cada cliente MCP nuevo equivale, en la práctica, a un desarrollador que nunca ha visto tu API y dispone de apenas unos segundos para entenderla. Si la respuesta a «¿cómo aprende un agente a usar esta API?» es «una persona leyó la documentación y escribió código auxiliar hace años», la API mantiene a una persona incrustada permanentemente en su ruta de ejecución, aunque nadie haga clic durante la compra. Este artículo trata de lo que debe ser cierto del propio registrador para que ese agente que parte desde cero tenga éxito; para la perspectiva de quien compra sobre esa misma transferencia, consulta Cómo compran dominios los agentes de IA sin una persona (2026).

La lista de verificación para registradores nativos para agentes

Un registrador nativo para agentes es aquel que un agente de IA puede descubrir, entender y usar para realizar transacciones por completo por sí mismo: sin navegador, sin que una persona lea antes la documentación ni introduzca un número de tarjeta. Para ello deben cumplirse seis cosas concretas, no basta con «tener una API»:

Esta es la versión resumible de la definición: un registrador nativo para agentes es aquel que obtiene un sí en descubrimiento, documentación en lenguaje natural, errores legibles por máquina, compra sin navegador y pago programático; los controles de política son la parte que toda la categoría todavía está resolviendo.

Descubrimiento: llms.txt y MCP son el mapa del sitio para los agentes

Un desarrollador encuentra una API buscando o haciendo clic por un sitio de documentación. Un agente necesita un archivo que pueda obtener y leer de una vez, o una conexión de protocolo que pueda consultar para conocer las operaciones disponibles. Hoy hay dos mecanismos que cumplen esa función.

llms.txt es, en palabras de la propia propuesta, «una propuesta para estandarizar el uso de un archivo /llms.txt que proporcione información para ayudar a los LLM a utilizar un sitio web en el momento de la inferencia». Es la misma idea que robots.txt, pero, en lugar de indicar a un rastreador qué puede indexar, indica a un modelo de lenguaje qué es un sitio y cómo usarlo. Consulta llms.txt para dominios: una API que cualquier agente de IA puede leer para ver cómo se ve ese archivo cuando un registrador publica uno.

MCP (Model Context Protocol) resuelve un problema adyacente: es «un estándar de código abierto para conectar aplicaciones de IA con sistemas externos». Mientras que llms.txt es un documento que un agente lee una vez para orientarse, MCP es una conexión activa que el cliente del agente abre con un servidor que expone un conjunto definido de herramientas invocables. Son complementarios, no competidores: llms.txt permite al agente descubrir que un registrador existe y saber, a grandes rasgos, qué puede hacer; MCP es la forma en que el cliente del agente se conecta realmente e invoca las operaciones.

Namefi publica ambos. El punto de entrada en namefi.io/llms.txt documenta un servidor MCP en api.namefi.io/mcp, un archivo de descubrimiento de MCP en namefi.io/.well-known/mcp/servers.json y una referencia REST completa, junto con archivos complementarios para pagos con billetera y flujos de trabajo de agentes salientes. Al comprobar directamente dos operadores establecidos, la documentación de registradores de Cloudflare publica su propio llms.txt en developers.cloudflare.com/registrar/llms.txt, pero nada de su documentación pública afirma que Cloudflare ejecute un servidor MCP dedicado para el producto de registrador. La propuesta de la beta, según la información publicada, es que la API está «diseñada para funcionar dentro de las herramientas donde los desarrolladores ya trabajan: editores de código con compatibilidad con MCP como Cursor y Claude Code». Eso es más limitado: el editor es compatible con MCP, no necesariamente el propio registrador de Cloudflare. El portal para desarrolladores de GoDaddy, comprobado directamente, documenta endpoints REST para un desarrollador humano y, hasta la fecha, no muestra referencia alguna a llms.txt ni a un servidor MCP.

Pagos: por qué una tarjeta guardada bloquea a los agentes y qué la sustituye

El paso de compra es donde más cuesta eliminar la premisa de que haya una persona en el circuito, porque la infraestructura de pagos web de consumo se construyó alrededor de una persona: una tarjeta guardada, una dirección de facturación y, a veces, un CAPTCHA pensado para filtrar a cualquiera que no sea una persona. Un agente no puede completar un formulario de tarjeta y entregarle el número de tarjeta sin procesar de una persona para que se haga pasar por ella es un mal modelo de seguridad, aunque sea técnicamente posible.

Se están lanzando dos alternativas. La primera es la facturación con clave de API: el registrador emite una credencial vinculada a una cuenta prefinanciada o facturada, y el agente autentica cada llamada con esa clave en vez de con una tarjeta. La documentación de Namefi describe cómo generar esta clave en namefi.io/api-key y enviarla como encabezado x-api-key en cada solicitud, sin sesión de navegador ni formulario de tarjeta. Los precios de .ai de Cloudflare siguen la misma lógica de coste: ofrece «registros y renovaciones de dominios .ai a precios mayoristas, sin recargos adicionales». Un precio plano y previsible es más fácil de razonar para un agente que uno que varía según la promoción.

La segunda alternativa es el pago firmado por una billetera, que elimina la propia cuenta, no solo la tarjeta. La documentación web3 de Namefi describe un flujo basado en el código de estado HTTP 402 y el patrón x402: una solicitud de un dominio sin pago devuelve los precios en una respuesta 402, la billetera del solicitante firma una autorización EIP-3009 y esa autorización firmada se vuelve a enviar como encabezado para completar el registro y la liquidación en un solo paso, explícitamente «sin necesidad de una cuenta de Namefi ni de firma EIP-712». La idea aquí es más acotada: es un método de pago que el software puede conservar y usar por sí mismo, algo que una tarjeta de crédito guardada no puede hacer por su propia estructura. Consulta Paga dominios con una billetera cripto: sin necesidad de cuenta para ver ese flujo de principio a fin.

Controles de política: la fila que toda la categoría aún no ha resuelto

Esta es la brecha honesta. El descubrimiento, la documentación legible por máquina, los errores estructurados y el pago programático son cosas que un registrador puede construir una vez y poner en producción. Los controles de política —topes de gasto, un paso de confirmación por encima de un umbral o una clave limitada a un TLD o a un presupuesto— son distintos, porque protegen a la persona que delegó la autoridad, no la facilidad de uso de la API.

Al comprobar la documentación de Namefi, el caso más verificable, se ve que marca determinadas operaciones como relevantes y documenta errores estructurados y legibles por máquina (códigos estables, una marca retryable y detalles estructurados): un avance real en esa fila. Pero no encontramos un mecanismo de límite de gasto documentado ni una puerta de confirmación del lado del servidor en la referencia pública de la API hasta la fecha; esa salvaguarda vive hoy una capa por encima, en la política que la persona configure en el propio cliente MCP. Tampoco encontramos documentación pública de un mecanismo de límite de gasto en las API de registrador de Cloudflare o Name.com. Esta es la fila que todo registrador nativo para agentes debería cerrar a continuación.

Puntuación de las plataformas actuales según la lista

Así puntúan las tres plataformas más mencionadas en este espacio frente a la lista de seis elementos, según lo que verificamos directamente en la documentación pública de cada plataforma, en lugar de basarnos en textos de marketing:

La única fila que está vacía en todos los casos, los controles de política, es una verdadera brecha de toda la industria, no un reproche a una sola plataforma. Vale la pena revisarla de nuevo a medida que avance este espacio.

Preguntas frecuentes

¿Qué es un registrador de dominios nativo para agentes?

Un registrador nativo para agentes es aquel que un agente de IA puede descubrir, entender y usar para realizar transacciones por sí mismo: sin navegador, sin que una persona lea antes la documentación ni introduzca un número de tarjeta. Obtiene un sí en descubrimiento (un archivo llms.txt o un servidor MCP), documentación en lenguaje natural, errores legibles por máquina, compra sin navegador y pago programático; los controles de política —límites de gasto y puertas de confirmación— son la parte que la categoría todavía está construyendo.

¿Por qué los agentes de IA no pueden usar las API de registrador normales?

Técnicamente pueden llamar a los endpoints, pero la mayoría de las API de registradores presuponen que un desarrollador humano ya leyó la documentación y escribió por adelantado el código de integración. Un agente sin una integración previa no tiene una forma estándar de descubrir la URL base, conocer el esquema de autenticación o interpretar un mensaje de error en prosa. La API funciona solo porque una persona ya hizo ese trabajo interpretativo, no porque sea legible para un agente que parte desde cero.

¿Cuál es la diferencia entre llms.txt y MCP?

llms.txt es un archivo de texto plano que un agente lee una vez para saber qué es un sitio o una API y cómo utilizarlo: cumple el mismo papel que robots.txt para los rastreadores, pero está escrito para modelos de lenguaje. MCP es una conexión de protocolo activa que el cliente de un agente abre con un servidor que expone herramientas invocables. Son complementarios: llms.txt sirve para el descubrimiento y MCP es la conexión que el agente usa para actuar. Consulta llms.txt para dominios: una API que cualquier agente de IA puede leer para la mitad dedicada al descubrimiento.

¿Cómo hago que mi propia API sea utilizable por agentes?

Publica un llms.txt que describa tu API para los modelos, expón un servidor MCP —o, como mínimo, endpoints documentados con OpenAPI—, devuelve errores estructurados con códigos estables en vez de texto, asegúrate de que cada operación de escritura se complete sin una página de pago alojada, admite un método de pago que no presuponga una tarjeta humana y añade límites de gasto o de confirmación para que quien tenga las credenciales pueda delimitar lo que el agente puede hacer.

¿Namefi es nativo para agentes?

Según la lista anterior, Namefi obtiene un sí en cinco de las seis filas verificadas directamente: publica una familia de archivos llms.txt y un servidor MCP, su documentación está estructurada para el consumo de agentes, su API devuelve errores estructurados y legibles por máquina, el registro se completa íntegramente mediante la API o el flujo de billetera basado en x402 sin necesidad de un panel de control, y el pago funciona con una clave de API o una transacción firmada por una billetera sin requerir una cuenta. Los controles de política aún no están documentados en la referencia pública de la API; ese control reside actualmente del lado del cliente.

¿Tener un servidor MCP convierte automáticamente a un registrador en nativo para agentes?

No. La compatibilidad con MCP cubre el descubrimiento y la compra sin navegador, pero un registrador puede exponer un servidor MCP y aun así devolver errores no estructurados, seguir exigiendo una tarjeta guardada o seguir sin tener un mecanismo de límite de gasto. Ser nativo para agentes implica cumplir toda la lista, no una sola fila.

Fuentes y lecturas adicionales

• Wikipedia — Extensible Provisioning Protocol (EPP se estandarizó como Proposed Standard en marzo de 2004)
• CircleID — El universo de los dominios en 2026: IA, seguridad, madurez del mercado y la nueva frontera de los gTLD («Los agentes de IA actúan cada vez más como revendedores de dominios...»)
• webhosting.today — Los agentes de IA ya pueden registrar dominios, sin intervención humana (beta de la API de Cloudflare Registrar, abril de 2026)
• Name.com — La primera plataforma de dominios nativa para IA («compatible con estándares modernos como Model Context Protocol...»)
• llmstxt.org — La propuesta del archivo /llms.txt
• modelcontextprotocol.io — Qué es Model Context Protocol (MCP)
• Schema.org — FAQPage
• Cloudflare — Compra dominios .ai al coste
• Cloudflare Developers — Índice de documentación del registrador (llms.txt)
• Namefi — namefi.io/llms.txt (referencia de la API y del servidor MCP; fuente de referencia para las afirmaciones sobre el producto Namefi en este artículo)
• Namefi — namefi.io/web3/llms.txt (flujo de pago firmado por billetera / x402, «sin necesidad de una cuenta de Namefi ni de firma EIP-712»)