Certificación

Esta página lista las comprobaciones que su servidor debe pasar antes de entrar en producción y en qué orden ocurre cada fase. No revisamos su código: usted registra el servidor, lo evaluamos contra esta lista y recibe el mismo informe que vemos nosotros.

Fases

Las comprobaciones que escriben se ejecutan solo contra el entorno de pruebas declarado. La batería nunca escribe en su producción.

Verifíquelo usted antes de avisarnos

La mayor parte de esta lista se comprueba sola. El servidor de referencia trae el verificador como comando y corre contra cualquier servidor MCP, no solo contra él:

git clone https://github.com/AndresTorresCode/asixto-mcp-reference
cd asixto-mcp-reference && npm install
node scripts/conformance.mjs https://su-entorno-de-pruebas/mcp SU-TOKEN --allow-writes

Sale con código 1 si falla una comprobación bloqueante, así que sirve en su pipeline. Imprime además la era de protocolo detectada: ya no hay que copiárnosla —la detectamos nosotros al registrar—, pero verla antes le confirma que su entorno de pruebas acuerda revisión y que el alta va a pasar.

Es de solo lectura por omisión. La comprobación de idempotencia es la única que ejecuta una herramienta de escritura —dos veces, con la misma clave— y solo corre con --allow-writes. Sin la bandera, «0 bloqueantes» no significa que la idempotencia esté verificada, y el veredicto se lo dice con esas palabras. Por eso el comando de arriba apunta a su entorno de pruebas.

Lo que el verificador no cubre: latencia bajo carga, propiedad del registro con datos reales, estados terminales y los campos mínimos por dominio de la página 04. Esas cuatro tampoco las mide la batería automática todavía —salen en su informe como «Todavía no automatizada»—: las revisamos con su equipo con datos suyos, que es la única forma de comprobarlas sin escribir en su producción.

Comprobaciones

Bloqueante impide la activación. Aviso queda en el informe y no bloquea.

Cómo leer su informe. Cada fila sale con uno de cuatro resultados, y cada uno dice de quién es la siguiente acción:

Si su servidor no responde, responde con un estado inservible, rechaza la credencial del alta o devuelve algo que no es un sobre JSON-RPC, eso sí sale como fallida y con instrucciones: que responda —aunque responda mal— nos permite decirle exactamente qué arreglar.

Protocolo y transporte

Autenticación

Garantías de negocio

Rendimiento

Autoevaluación previa

Antes de registrar, verifique por su cuenta. Ahorra una vuelta completa:

• Cada herramienta probada con el Inspector y con un test automatizado.
• Esquemas cerrados en todas.
• 401 correcto sin credencial y con credencial inválida.
• Todo parámetro opcional acepta null en su type.
• Escritura invocada dos veces con la misma clave de _meta: un solo efecto.
• Escritura invocada con un identificador de otro contacto: PERMISSION.
• Operación sobre una entidad en estado terminal: VALIDATION.
• Búsqueda sin resultados: éxito con lista vacía y total: 0, no error.
• Respuestas revisadas a ojo: sin identificadores internos ni campos administrativos, ≤ 3.000 caracteres.
• Solo los seis error_type de la página 06.
• Búsquedas respetan el limit recibido y devuelven total, limit y offset.
• Nombres ≤ 40 caracteres y descripciones ≤ 700.
• Cada herramienta declara readOnlyHint con un booleano. Sin él no se publica: no podemos saber si escribe.
• Ninguna descripción da instrucciones al modelo ni trae caracteres invisibles.
• Ninguna herramienta deja elegir el método HTTP: una de lectura y una por cada acción que escribe.
• Cada herramienta declara com.asixto/capability o capabilities (claves válidas) y com.asixto/verb.
• Cada dominio devuelve sus campos mínimos (página 04).
• Ningún token en sus logs.

Requisitos que no se verifican desde fuera

Estos no aparecen arriba porque ninguna batería puede comprobarlos desde el exterior de su sistema. Forman parte del criterio de aceptación igualmente, y se declaran en el registro:

Dicho de otro modo: la batería comprueba la forma; lo de esta tabla es compromiso, y es lo que se revisa si algún día hay un incidente.

Qué certifica Asixto y qué no

La certificación verifica que su servidor cumple este contrato, observado desde fuera: transporte, autenticación, garantías de negocio y rendimiento. Es determinista y repetible, y por eso puede correr sin que nadie lea su código.

Lo que no es: una auditoría de su código, de su infraestructura o de sus datos, ni un sustituto de sus propios controles. La operación, la disponibilidad, la seguridad y el comportamiento de su servidor —y de los sistemas que hay detrás— son suyos. Asixto ejecuta la batería, le entrega el resultado por comprobación y suspende un escenario cuando el servidor deja de responder (página 10); no administra ni supervisa su servidor.

Un resultado aprobado significa que el contrato se cumple en el momento de la ejecución. No es una garantía sobre el contenido de sus respuestas: los datos que devuelve son suyos y el agente los traslada al cliente final tal como los recibe (página 05).

Recertificación