Resumen

  • La política propuesta por Charleston Road Registry vincula la elegibilidad para registrar un nombre .mcp con cuatro formas de participación en MCP.
  • El consejo de política mencionado en la solicitud tendría poder de consentimiento sobre los cambios, aunque el expediente público no explica quién lo integra ni cómo se apela una exclusión.

Conviene separar dos preguntas que la sigla MCP puede hacer parecer una sola. El Model Context Protocol es un proyecto técnico abierto. La extensión .mcp, si llega a delegarse, sería un espacio administrado por un registro de dominios bajo un contrato. Que una persona participe en el protocolo no significa automáticamente que tenga derecho a obtener un nombre dentro de ese espacio.

La solicitud de Charleston Road Registry Inc. (CRR), la entidad solicitante de Google Registry, ofrece cuatro vías de elegibilidad: acreditar contribuciones a los repositorios oficiales de MCP; operar un servidor MCP activo y conforme; ser titular o representante autorizado de una entrada del registro oficial de MCP; o mantener una membresía vigente en Agentic AI Foundation (AAIF). La empresa afirma que el operador del registro comprobaría los requisitos con ayuda del .MCP Policy Council. En su respuesta a la pregunta 151, añade que la política solo podría modificarse con el consentimiento de ese consejo.

Las vías no son equivalentes. Una contribución puede verificarse en el historial de repositorios; la operación exige actividad técnica actual; la entrada en el registro se refiere a una representación; la membresía AAIF depende de una relación institucional. Una persona nueva en el proyecto, un mantenedor y una empresa que presta herramientas tendrían expedientes y riesgos distintos. La solicitud enumera las categorías, pero el registro público no detalla los umbrales de prueba, qué ocurre si un repositorio no refleja una contribución o cómo se impugna una denegación.

La gobernanza de la lista también queda abierta. La solicitud nombra al .MCP Policy Council como apoyo en la aplicación y como órgano cuyo consentimiento sería necesario para modificar las reglas. Pero no identifica a sus integrantes, el modo de nombramiento o destitución, la duración del mandato, los conflictos de interés ni el procedimiento para que una persona rechazada cuestione la decisión. Tampoco explica su relación formal con la gobernanza técnica de MCP. Esa ausencia no demuestra captura ni mala fe; sí deja sin resolver quién responde por una puerta de acceso potencialmente duradera.

La documentación pública del proyecto describe otra estructura. La página de gobernanza de MCP enumera un Steering Group y funciones de Lead, Core y Maintainer. Señala que la gobernanza técnica recae en personas y que no hay puestos reservados a empresas. No menciona al .MCP Policy Council. Por tanto, no hay base documental para identificar a ese consejo con la dirección técnica del protocolo ni para suponer que las decisiones del proyecto obligarán al registro. Un registro puede administrar condiciones contractuales para sus nombres; eso no equivale a decidir quién contribuye a MCP, qué implementación cumple el estándar o hacia dónde evoluciona el protocolo.

El calendario de la ICANN requiere la misma precisión. El archivo del Reveal Day publicado el 7 de octubre agrupa cinco solicitudes iniciales para .mcp: CRR, OPENAI OPCO, Radix, ShortDot y Tidal Case. Los cinco resúmenes públicos figuran como Active / Pre-Evaluation Processing. Solo el de CRR muestra Community en el campo público tldTypes; los otros cuatro muestran listas vacías. Ese campo vacío no prueba que carezcan de una pretensión comunitaria. Además, la ICANN no considera definitivos los grupos hasta que termine la evaluación de cadenas.

Si CRR mantiene la designación comunitaria y opta por participar, una Community Priority Evaluation podría afectar la prioridad en la contienda. La guía de solicitantes vigente define la CPE como una evaluación independiente para determinar prioridad entre solicitudes en conflicto. Antes deben completarse los procesos de evaluación, objeción y apelación que correspondan; los compromisos de registro propuestos también pasan por una evaluación separada. Una solicitud comunitaria que apruebe puede prevalecer frente a las no comunitarias; si aprueban varias, pasan a subasta. La CPE usa cuatro criterios y exige 12 de 16 puntos.

No determina si MCP existe como comunidad: la solicitud identifica la comunidad y la CPE evalúa si la candidatura merece prioridad. Tampoco es un plebiscito sobre la legitimidad de las instituciones técnicas del proyecto.

La Nota 72 sirve para formular una pregunta, no para trasladar una regla. Su advertencia de que una lista de correo, una reunión o un consenso no crean por sí solos un mandato se refiere al poder de los registros regionales sobre los recursos de numeración. Un registro de dominios opera bajo otro contrato y necesita administrar nombres. Aquí la pregunta más acotada es si los criterios de acceso estarán delimitados, serán explicables y podrán recurrirse; y si cada participante sabrá quién puede cambiar esas reglas.

.mcp aún no está delegado y la política propuesta no está aprobada. El expediente ya permite distinguir los riesgos: participar en MCP no es lo mismo que ser elegible para un dominio; verificar una relación exige una vía de apelación; el poder de modificación del consejo debe hacerse transparente; y una decisión del registro no equivale a un aval técnico del protocolo. Si la solicitud avanza, conocer la carta del consejo será tan importante como leer las cuatro categorías.

Fuentes