38.9% de este índice nunca ha respondido.

Qué dice esto que un listado de directorio no puede decir

Una entrada de registro es una afirmación: alguien publicó un nombre, una descripción y dónde vive el código. Nada en el Registry registra si la cosa se ejecuta. Todos los demás directorios de MCP vuelven a publicar esas afirmaciones, así que el único conteo que cualquiera de ellos puede producir es cuántas entradas copiaron.

Este índice conecta. Adquiere el paquete, lo inicia sin red ni credenciales, envía initialize y pide la lista de herramientas. Esa es la única razón por la que el número más grande aquí puede existir: 14.494 servidores — 38.9% de todo lo indexado — nunca han completado ese handshake ni una vez. No se reportan como fallidos, porque no se observó nada que justifique decirlo. No están observados, y la diferencia importa.

La otra mitad es el panorama más familiar: 12.079 servidores verificados como funcionales, 4665 que exigen credenciales que la sonda deliberadamente no lleva, y 5984 fallidos.

Dónde se detiene la mitad alcanzada

El censo dice cuántos servidores hay en cada estado. No dice dónde se detuvieron, porque la etapa se registra por ejecución y no por estado — así que esta parte es una muestra, y el tamaño de la muestra se indica para que pueda juzgarse por lo que es.

En 180 servidores extraídos de manera uniforme de todo el índice, ninguno falló mientras se adquiría el paquete. Todos los servidores que fueron alcanzados y no se verificaron se detuvieron más adelante: 36 durante el handshake del protocolo, y 5 que completaron el handshake y luego fallaron al listar las herramientas. Los servidores que quieren credenciales también fallan en el handshake, que es por lo que gran parte del índice no verificado se detiene en el mismo punto — el servidor respondió, y lo que dijo no era el protocolo.

Esos mismos 180 servidores llevan la única estimación de esta página. De los 37 que tienen un informe registrado de calidad de herramientas, el servidor mediano dedica 1,511 tokens a describir sus herramientas antes de que un modelo haya hecho trabajo alguno. Ese es un costo fijo que se paga en cada conversación que carga el servidor, y es una mediana de muestra y no un conteo.

Cómo se cuenta esto

Cada estado es una regla sobre la última observación, y las reglas son las mismas que usan los filtros del directorio, así que esta página y el listado nunca pueden discrepar. Un servidor verificado que pasa 30 días sin otro éxito pasa a obsoleto sin que le ocurra nada más. Un servidor que falla dos veces, con al menos 15 minutos de diferencia, pasa a fallido. Un servidor sin ninguna fila de observación se cuenta como sin observar en lugar de excluirse del total.

Los conteos se toman en vivo cuando se solicita esta página. Se comprobaron de forma independiente contra una muestra uniforme de 720 servidores extraídos de manera uniforme de todo el índice, que coincidió con el conteo exacto en cada estado dentro del error de muestreo.

Qué no dice esto

Sin observar no es lo mismo que fallido, abandonado o malo. Un servidor puede estar sin observar porque el ejecutor no pudo alcanzarlo, porque su paquete no pudo adquirirse, o simplemente porque el índice ha crecido más rápido de lo que la sonda ha llegado a él — esta página no distingue entre esos casos, y cualquier afirmación sobre cuál predomina sería una conjetura disfrazada de hallazgo.

Un servidor verificado no es un servidor seguro. La sonda nunca llama a una herramienta, nunca lee una implementación y no evalúa el tratamiento de datos, los permisos, las dependencias ni la seguridad. Registra que un handshake tuvo éxito en un momento dado. El método describe los límites en su totalidad, y acerca de describe qué afirma y qué no afirma este proyecto.

Estos números describen este índice el día en que se cargó, y el índice crece. La API expone las mismas cifras a cualquiera que quiera comprobarlas.