Directorios y botones de instalación

Además de los canales de paquetes (ver Publicación de versiones), los clientes y directorios de MCP descubren servidores mediante unos cuantos manifiestos del repositorio y mediante los botones de instalación del README. Nada de esto está publicado ni listado todavía: cada listado de abajo necesita que el repositorio sea público y que haya salido la primera versión, y casi todos necesitan un paso del propietario.

Los manifiestos

Fichero	Lo lee	Se mantiene al día con
server.json	El MCP Registry (y los directorios que lo replican)	publish-registry.yml, en cada versión más reciente (MCP Registry)
glama.json	Glama: nombra a jmrplens como mantenedor que puede reclamar el listado	Escrito a mano; un test comprueba su forma
plugin.json, mcp.json	Los anfitriones de Agent Plugins 1.0 (agent-plugins.org): el plugin y su servidor MCP, la imagen de contenedor con todas las variables que declara server.json reenviadas	Escritos a mano; test/release valida ambos contra los esquemas de Agent Plugins incluidos y mantiene el nombre, la versión (VERSION), la descripción y los enlaces iguales a los de los demás manifiestos
.plugin/plugin.json, .plugin/plugin.schema.json	Los anfitriones que siguen con la estructura antigua de Open Plugins (un logo y mcpServers: ./mcp.json)	Escritos a mano; se validan contra su propio esquema y se mantienen iguales a plugin.json
lhm.plugin.json	El LobeHub Marketplace: sus distintivos de capacidades salen de los tools, prompts y resources del manifiesto, porque no puede inspeccionar un binario ni una imagen	cmd/gen_lhm_manifest escribe las tres listas a partir de un tools/list, prompts/list y resources/list reales de la superficie predeterminada; make check falla cuando están desfasadas
llms.txt	Los asistentes y herramientas que leen el índice llms.txt	cmd/gen_llms lo escribe a partir del catálogo (una línea por dominio) y comprueba cada enlace a la documentación contra las páginas del sitio; make check falla cuando está desfasado
llms-install.md	Los asistentes a los que se pide instalar el servidor (la convención que introdujo Cline)	Escrito a mano

Cada descripción que cita el tamaño del catálogo (« actions in domains») se comprueba contra el catálogo, y cada version contra VERSION, así que una versión los actualiza junto con VERSION.

Botones de instalación

La tabla de instalación del README tiene botones de un clic para VS Code y VS Code Insiders (que piden ARCANE_URL y, oculta, ARCANE_API_KEY), Cursor, LM Studio y Kiro (que registran marcadores para editar), todos registrando la imagen de contenedor ghcr.io/jmrplens/arcane-mcp:latest con -e ARCANE_URL -e ARCANE_API_KEY, además de los tres paquetes .mcpb por sistema para Claude Desktop y la orden de Claude Code. La configuración de un botón viaja dentro de su URL, así que ninguna búsqueda de texto la ve, y cada cliente la lee de una forma: la redirección de VS Code y Kiro toman JSON codificado en porcentaje, Cursor y LM Studio base64, y solo VS Code toma definiciones de avisos, de un parámetro inputs de primer nivel junto a config (insiders.vscode.dev solo reenvía name, ese parámetro y los campos de la entrada; los avisos anidados en config se pierden). cmd/audit_install_buttons (make check) lee cada botón del README, de docs/, de llms-install.md y de las fuentes del sitio según las reglas de su destino, y mcp.json, y los contrasta con un destino conocido y el nombre arcane, con la imagen que declara server.json, con variables que server.json declara e internal/config lee (las dos obligatorias siempre reenviadas y el bloque env fijando exactamente las reenviadas), con avisos de primer nivel en VS Code (la clave oculta) y marcadores en los demás, con una única lista de argumentos para todos los botones y con descargas de .mcpb de las versiones de este repositorio que declara server.json.

Los distintivos de directorios del README (Glama, LobeHub, MCP Toplist, Cursor Directory) y los de SonarCloud están escritos en un comentario HTML hasta que exista cada listado: el distintivo de un listado que no existe se muestra como un error. Este repositorio aún no tiene proyecto en SonarCloud (sonar.yml omite el análisis hasta que exista SONAR_TOKEN).

Listados que envía el propietario

1. MCP Registry: nada que hacer; publish-registry.yml publica cada versión más reciente.
2. Glama: cuando el repositorio sea público, busca el servidor en glama.ai (o añádelo con la URL de su repositorio) y reclámalo con la sesión de GitHub de jmrplens; Glama comprueba la reclamación contra glama.json. Después Glama puntúa el servidor; añade su distintivo al README.
3. LobeHub Marketplace: desde una máquina con Node, una vez: npx -y @lobehub/market-cli@0.0.44 login y npx -y @lobehub/market-cli@0.0.44 github connect (ambas interactivas), y después el primer listado con npx -y @lobehub/market-cli@0.0.44 plugin publish https://github.com/jmrplens/arcane-mcp. Tras cada versión posterior, make publish-lobehub (comprueba el manifiesto y ejecuta plugin update). El listado es jmrplens-arcane-mcp.
4. Cursor Directory: envía el repositorio en cursor.directory, con la sesión de GitHub; el listado enlaza el botón de instalación de Cursor.
5. MCP Toplist: lista los servidores del MCP Registry, así que la primera publicación en el registro debería bastar; añade su distintivo cuando aparezca el servidor.
6. Directorio de extensiones de Claude Desktop: un formulario de envío aparte para la extensión .mcpb. Pide una política de privacidad (Privacidad) y credenciales de prueba: un Arcane accesible y una clave de API que puedan usar los revisores. Si mantener ese Arcane, y qué puede hacer esa clave (una clave de solo lectura en una instancia desechable), lo decide el propietario; hasta entonces, la extensión se ofrece solo desde las versiones publicadas.