Ir al contenido

Configuración

arcane-mcp lee su configuración de tres sitios. De menor a mayor precedencia:

  1. un fichero .env en el directorio de trabajo (un CLAVE=valor por línea; admite comentarios con # y el prefijo export; nunca sobrescribe una variable ya definida),
  2. el entorno del proceso,
  3. las opciones de línea de comandos.

El servidor se niega a arrancar, enumerando todos los problemas, si falta ARCANE_URL, si la superficie de herramientas no es una de las tres, si un valor no se puede leer (un interruptor, un número o una duración; en stdio solo cuentan los ajustes que stdio lee, consulta Notas), si un límite o un tiempo máximo está fuera de rango, si un origen de confianza está mal formado, si queda un argumento suelto tras las opciones o si —en modo stdio— no hay ni clave de API ni usuario y contraseña. arcane-mcp --help enumera todas las opciones y variables con su valor predeterminado.

VariableOpciónPredeterminadoSignificado
ARCANE_URL--arcane-url—URL del servidor Arcane (obligatoria), o varias como nombre=url,nombre=url (consulta Varias instancias)
ARCANE_API_KEY——Clave de API, enviada como X-API-Key (recomendada). Con varias instancias, una por instancia como nombre=clave,nombre=clave
ARCANE_USERNAME, ARCANE_PASSWORD——Inicio de sesión en lugar de una clave de API, o además de ella. Arcane solo acepta una sesión iniciada para unas pocas operaciones de cuenta (passkeys, MFA); con ambas configuradas, esas usan la sesión y todo lo demás la clave
ARCANE_ENVIRONMENT_ID--environment0Entorno que se usa cuando una acción no indica environmentId (0 es el Docker local de Arcane). Con varias instancias, un valor para todas o nombre=id,... por instancia (las que no aparecen usan 0)
ARCANE_MCP_INSTANCE--instance—Con varias instancias en ARCANE_URL, la que sirve un servidor stdio (obligatoria entonces); por HTTP los clientes eligen con X-Arcane-URL, así que definirla detiene el servidor
ARCANE_SKIP_TLS_VERIFY--skip-tls-verifyfalseAcepta certificados autofirmados
ARCANE_MCP_TOOL_SURFACE--tool-surfacedynamicdynamic, meta o individual
ARCANE_MCP_READ_ONLY--read-onlyfalseExpone solo las acciones de lectura
ARCANE_MCP_SAFE_MODE--safe-modefalseResponde a las llamadas que modifican con una vista previa
ARCANE_MCP_EXCLUDE_TOOLS--exclude-tools—IDs de acción (image.prune), dominios (swarm_node) o nombres de herramienta que ocultar, separados por comas. Una entrada que no coincide con nada se avisa en el log al arrancar
ARCANE_MCP_MAX_DOWNLOAD_BYTES—4194304Límite para descargas y para la salida recogida de los flujos
ARCANE_MCP_STDIO_MAX_LINE_BYTES—16777216Mayor mensaje stdio (una línea); uno más largo se responde con un error y la sesión continúa. El valor por defecto admite un upload.chunk_put con el fragmento de 10 MiB de Arcane codificado en base64, como ARCANE_MCP_HTTP_MAX_BODY_BYTES en HTTP
ARCANE_MCP_TIMEOUT—60sTiempo máximo de una petición que no es un flujo
ARCANE_MCP_ACTION_TIMEOUT--action-timeout30m, o ARCANE_MCP_TIMEOUT si es mayorPlazo global de una acción, flujos de progreso y descargas incluidos. Un valor explícito menor que ARCANE_MCP_TIMEOUT impide arrancar (consulta Seguridad). También limita cuánto espera un servidor stdio cuyo stdin se ha cerrado a las respuestas pendientes
ARCANE_MCP_ELICITATION--elicitationtruePreguntar al usuario mediante elicitación MCP, si el cliente lo admite, antes de una llamada destructiva sin confirm: true; con off se rechaza siempre (consulta Seguridad)
ARCANE_MCP_ELICITATION_TIMEOUT--elicitation-timeout5mCuánto esperar la respuesta del usuario antes de rechazar
ARCANE_MCP_AUDIT_LOG--audit-logtrueUn registro de log info por cada llamada a una herramienta (consulta Seguridad)
ARCANE_MCP_AUDIT_LOG_ARG_NAMES--audit-log-arg-namesfalseAñadir a los registros de auditoría los nombres de los argumentos pasados (nunca sus valores)
ARCANE_MCP_HTTP_ADDR--http—Sirve Streamable HTTP en esta dirección (ruta /mcp) en lugar de stdio
ARCANE_MCP_HTTP_TOKEN——Token bearer que deben presentar los clientes HTTP. Sin él, HTTP es solo para redes de confianza (consulta Modo HTTP). No tiene opción a propósito: la línea de comandos es visible para todos los usuarios del equipo
ARCANE_MCP_HTTP_MAX_API_KEYS--http-max-api-keys100Claves de API de Arcane distintas (X-Arcane-API-Key) atendidas a la vez; cada una tiene su propio servidor MCP
ARCANE_MCP_HTTP_API_KEY_IDLE_TIMEOUT--http-api-key-idle-timeout10mLibera el servidor de una clave este tiempo después de que terminen su última sesión y su última petición (0: solo cuando una clave nueva necesita el hueco)
ARCANE_MCP_HTTP_SESSION_IDLE_TIMEOUT--http-session-idle-timeout30mCierra una sesión tras este tiempo sin peticiones (0: nunca)
ARCANE_MCP_HTTP_MAX_SESSIONS--http-max-sessions1000Sesiones vivas sumando todas las claves
ARCANE_MCP_HTTP_MAX_CONCURRENT_REQUESTS--http-max-concurrent-requests64Peticiones POST y DELETE atendidas a la vez entre todos los clientes (los flujos de eventos no cuentan)
ARCANE_MCP_HTTP_MAX_BODY_BYTES--http-max-body-bytes16777216Cuerpo de petición más grande (16 MiB: un upload.chunk_put con el trozo de 10 MiB por defecto de Arcane, codificado en base64)
ARCANE_MCP_HTTP_TRUSTED_ORIGINS--http-trusted-origins—Orígenes de navegador (https://app.example.com), separados por comas, que pueden llamar a /mcp desde otro origen; * admite cualquiera y desactiva la protección
ARCANE_MCP_HTTP_ALLOWED_HOSTS--http-allowed-hosts— (cualquiera)Valores de Host, separados por comas, a los que responde /mcp: un nombre de host (mcp.example.com, cualquier puerto) o host:puerto. Configúralo siempre que el servidor escuche fuera de loopback sin token (DNS rebinding, consulta Modo HTTP)
ARCANE_MCP_HTTP_STATELESS--http-statelessfalseSirve Streamable HTTP sin estado, el transporte de la revisión 2026-07-28 del protocolo: sin sesiones, cada POST es independiente, GET y DELETE responden 405 (consulta HTTP sin estado)
ARCANE_MCP_HTTP_AUTH--http-authtokenCómo se autentican los clientes HTTP: token (el Bearer es ARCANE_MCP_HTTP_TOKEN y la clave de Arcane viaja en X-Arcane-API-Key o sale de la configuración) o apikey (el Bearer es la propia clave de API de Arcane de quien llama, comprobada contra Arcane). apikey junto con ARCANE_MCP_HTTP_TOKEN, ARCANE_API_KEY, ARCANE_USERNAME o ARCANE_PASSWORD detiene el servidor al arrancar (consulta Autenticación HTTP)
ARCANE_MCP_HTTP_AUTH_CACHE_TTL--http-auth-cache-ttl5mModo apikey: cuánto tiempo se atiende una clave que Arcane aceptó antes de volver a preguntarle
ARCANE_MCP_HTTP_AUTH_MAX_FAILURES--http-auth-max-failures10Autenticaciones fallidas (un token erróneo, una clave que Arcane rechaza) que puede hacer una dirección de cliente por ventana antes de recibir 429 durante el resto de ella (0: sin límite)
ARCANE_MCP_HTTP_AUTH_FAILURE_WINDOW--http-auth-failure-window1mLa ventana de ARCANE_MCP_HTTP_AUTH_MAX_FAILURES, contada desde el primer fallo
ARCANE_MCP_HTTP_AUTH_NETWORK_FACTOR--http-auth-network-factor10Un /48 de IPv6 recibe 429 cuando ha tenido este número de veces ARCANE_MCP_HTTP_AUTH_MAX_FAILURES credenciales rechazadas dentro de una ventana, sumando sus /64 (0: sin límite por /48; sin efecto cuando ARCANE_MCP_HTTP_AUTH_MAX_FAILURES es 0)
ARCANE_MCP_HTTP_TRUSTED_PROXIES--http-trusted-proxies—Direcciones o rangos CIDR de proxies (10.0.0.0/8, ::1), separados por comas, cuya ARCANE_MCP_HTTP_TRUSTED_PROXY_HEADER nombra la dirección del cliente. Se configuran las dos o ninguna
ARCANE_MCP_HTTP_TRUSTED_PROXY_HEADER--http-trusted-proxy-header—Cabecera en la que esos proxies ponen la dirección del cliente (X-Forwarded-For, X-Real-IP); Forwarded no se admite
ARCANE_MCP_HTTP_RATE_LIMIT_RPS--http-rate-limit-rps0 (desactivado)Peticiones por segundo sostenidas de una clave de Arcane (vale un decimal como 0.5); por encima, la clave recibe 429 con Retry-After
ARCANE_MCP_HTTP_TLS_CERT, ARCANE_MCP_HTTP_TLS_KEY--http-tls-cert, --http-tls-key—Sirve HTTPS (TLS 1.2 como mínimo) con este certificado (cadena) y clave PEM; los dos o ninguno. Si los ficheros no se pueden leer o no casan, el servidor no arranca; un par renovado se toma sin reiniciar (consulta Escucha, sondas y parada)
ARCANE_MCP_HTTP_SOCKET_MODE--http-socket-mode0660Permisos (octal) del socket unix cuando ARCANE_MCP_HTTP_ADDR es una ruta (/run/arcane-mcp.sock) o unix:<ruta>; en Windows decide la ACL del directorio (ver abajo)
ARCANE_MCP_HTTP_DRAIN_DELAY--http-drain-delay0sTras SIGTERM, cuánto tiempo responde /readyz 503 mientras el servidor sigue atendiendo, antes de dejar de aceptar conexiones (como mucho 5m)
ARCANE_MCP_HTTP_ALLOW_PLAINTEXT--http-allow-plaintext— (sin definir)Qué pasa con un puerto TCP al que llegan otras máquinas y que sirve HTTP sin cifrar: sin definir, se sirve y avisa al arrancar; true (o la opción sola) declara que algo delante cifra ese tramo, y se registra en INFO; false se niega a arrancarlo. TLS, loopback y un socket unix nunca se ven afectados. Consulta Escucha, sondas y parada
ARCANE_MCP_HTTP_RATE_LIMIT_BURST--http-rate-limit-burst40Peticiones que una clave puede hacer de golpe antes de que el ritmo la frene (al menos 1 si hay ritmo)
ARCANE_MCP_HTTP_SERVER_CARD—trueServir la tarjeta del servidor en /server-card y /mcp/server-card
ARCANE_MCP_HTTP_DISCOVERY_RATE_LIMIT_RPS--http-discovery-rate-limit-rps20Peticiones por segundo que una dirección de cliente puede hacer a la tarjeta del servidor (0: sin límite; como mucho 1000)
ARCANE_MCP_HTTP_DISCOVERY_RATE_LIMIT_BURST--http-discovery-rate-limit-burst200Peticiones a la tarjeta del servidor que una dirección de cliente puede hacer de golpe (0: sin límite; como mucho 10000)
ARCANE_MCP_ICONS—trueEnviar el icono de la marca con el servidor y con cada herramienta, prompt y recurso; off no envía ninguno, para un cliente que rechace iconos como URI data: (consulta Iconos)
ARCANE_MCP_OUTPUT_SCHEMAS—falseExperimental: en la superficie individual, declarar el esquema de salida de cada acción, derivado del documento OpenAPI de Arcane (consulta Esquemas de salida)
ARCANE_MCP_LOG_LEVEL--log-levelinfodebug, info, warn o error. Los logs van solo a stderr. Cualquier otro valor detiene el servidor al arrancar
LOG_LEVEL——Alias obsoleto de ARCANE_MCP_LOG_LEVEL, que solo se lee si esta no está definida, con un aviso al arrancar. Un valor que no es un nivel se ignora con un aviso (otro software puede usar este nombre)

Los interruptores (ARCANE_SKIP_TLS_VERIFY, ARCANE_MCP_READ_ONLY, ARCANE_MCP_SAFE_MODE, ARCANE_MCP_ELICITATION, ARCANE_MCP_AUDIT_LOG, ARCANE_MCP_AUDIT_LOG_ARG_NAMES, ARCANE_MCP_HTTP_STATELESS, ARCANE_MCP_ICONS, ARCANE_MCP_OUTPUT_SCHEMAS) aceptan true/false, 1/0, yes/no y on/off; cualquier otro valor detiene el servidor al arrancar, para que un interruptor de seguridad mal escrito nunca lo deje escribiendo.

arcane-mcp --version muestra la versión, el commit y la fecha de compilación, y termina. arcane-mcp --help muestra todas las opciones y variables con su valor predeterminado y termina con estado 0, contenga lo que contenga el entorno.

Comportamiento que la costumbre de otros servidores, o una lectura rápida de la tabla, quizá no hagan esperar. Lo que cambia cada versión está en el registro de cambios.

  • Una variable con un valor vacío o en blanco cuenta como no definida, en todos los ajustes: toma el valor predeterminado, y un fichero .env puede rellenarla. Las extensiones de escritorio y los clientes de registros envían un valor vacío para un campo que el usuario ha borrado, así que un ARCANE_MCP_TOOL_SURFACE vacío es la superficie predeterminada y un ARCANE_ENVIRONMENT_ID vacío es el entorno 0.
  • La imagen del contenedor tiene un HEALTHCHECK (arcane-mcp --probe, consulta Escucha, sondas y parada); un contenedor stdio queda sano.
  • --help (-h) termina con estado 0 y funciona aunque el entorno contenga un valor que el servidor rechazaría.
  • Un número o una duración mal formados (ARCANE_MCP_TIMEOUT=60, ARCANE_MCP_MAX_DOWNLOAD_BYTES=4MB) detienen el servidor al arrancar con estado 2 en lugar de usar el valor predeterminado. ARCANE_MCP_TIMEOUT además debe ser positivo.
  • Un argumento que sobra tras las opciones (--read-only false) es un error, así que ninguna opción posterior se descarta en silencio.
  • Las llamadas destructivas sin confirm: true preguntan al usuario mediante elicitación MCP en los clientes que lo admiten (ARCANE_MCP_ELICITATION), y cada llamada a una herramienta escribe un registro de auditoría (ARCANE_MCP_AUDIT_LOG).
  • Cada acción se ejecuta dentro de un plazo global (ARCANE_MCP_ACTION_TIMEOUT): 30m, o ARCANE_MCP_TIMEOUT si es mayor. También limita los flujos de progreso (descarga y construcción de imágenes, up y redespliegue de proyectos) y las descargas; si duran más, se cancelan con un error que nombra el plazo.
  • El nivel de log es ARCANE_MCP_LOG_LEVEL, como el resto de opciones. LOG_LEVEL se lee si ARCANE_MCP_LOG_LEVEL no está definida, con un aviso de obsolescencia; un valor de LOG_LEVEL que no es un nivel se ignora con un aviso. Un ARCANE_MCP_LOG_LEVEL o un --log-level ilegibles detienen el servidor al arrancar.
  • Una entrada de ARCANE_MCP_EXCLUDE_TOOLS que no coincide con ninguna acción, dominio ni nombre de herramienta (una errata, o un alias como el ID de operación de OpenAPI, que la exclusión no lee) se avisa en el log al arrancar; no oculta nada.
  • Streamable HTTP sin estado está disponible con ARCANE_MCP_HTTP_STATELESS (desactivado por defecto, consulta HTTP sin estado).
  • Por HTTP, una dirección de cliente que envía 10 tokens erróneos en un minuto recibe 429 con Retry-After hasta que acaba el minuto (ARCANE_MCP_HTTP_AUTH_MAX_FAILURES; 0 lo desactiva); detrás de un proxy inverso configura ARCANE_MCP_HTTP_TRUSTED_PROXIES y ARCANE_MCP_HTTP_TRUSTED_PROXY_HEADER, o todos los clientes compartirán el presupuesto del proxy. ARCANE_MCP_HTTP_AUTH=apikey y un límite de ritmo por clave están desactivados por defecto (consulta Autenticación HTTP).
  • El presupuesto de fallos de autenticación también bloquea un /48 de IPv6 entero cuando ha tenido diez veces ARCANE_MCP_HTTP_AUTH_MAX_FAILURES credenciales rechazadas dentro de una ventana (consulta Autenticación HTTP). El factor es ARCANE_MCP_HTTP_AUTH_NETWORK_FACTOR (10; 0 desactiva el límite por /48).
  • Dos combinaciones de proxies de confianza que no pueden funcionar detienen el servidor al arrancar: un ARCANE_MCP_HTTP_ADDR de socket unix cuyo ARCANE_MCP_HTTP_TRUSTED_PROXIES incluye direcciones pero no unix (un cliente por socket no tiene dirección, así que la cabecera nunca se creería), y unix en esa lista con una escucha TCP. Cada una cargaría a todos los clientes en un único presupuesto compartido. Consulta la tabla de combinaciones en Despliegue HTTP.
  • En Windows, un ARCANE_MCP_HTTP_ADDR que contiene \ es la ruta de un socket unix, como lo es en todas partes uno que contiene /.
  • Las vistas previas del modo seguro nunca repiten los argumentos que parecen credenciales: contraseñas, claves, tokens y el data de un secreto se muestran como (hidden) en los parámetros y en el cuerpo JSON, igual que en la pregunta de confirmación.
  • El contenido de los resultados lleva anotaciones de audiencia MCP: el bloque de texto va marcado para el asistente (audience: ["assistant"]) y una descarga binaria para el usuario (audience: ["user"]). Un cliente que filtre el contenido por audiencia puede no mostrar el texto al usuario o no pasar las descargas al modelo. Consulta Formato de salida.
  • /readyz?format=json no muestra la versión exacta de la que informa cada instancia de Arcane: no pide credencial, y la versión permitiría a cualquiera que llegue al servidor identificar el Arcane que hay detrás. Muestra versionMatch y catalogVersion; la versión exacta está en la línea del log al arrancar.
  • Un servidor stdio con un ajuste solo HTTP (ARCANE_MCP_HTTP_TOKEN, ARCANE_MCP_HTTP_RATE_LIMIT_RPS, ajustes de TLS, socket o proxies…) registra al arrancar un aviso que los nombra en lugar de ignorarlos sin decir nada. Consulta Notas.
  • Los booleanos aceptan lo mismo que strconv.ParseBool de Go (1, true, TRUE, 0, false…) además de yes/no y on/off. Los números son cantidades enteras de bytes o de elementos (16777216, no 16MiB). Un valor ilegible de cualquiera de ellos, o de una duración, detiene el servidor al arrancar en lugar de sustituirse por un valor que nadie eligió; un valor vacío equivale al predeterminado.
  • Las duraciones usan la sintaxis de Go con unidad: 90s, 2m, 1m30s (un 60 sin unidad se rechaza).
  • ARCANE_ENVIRONMENT_ID es un valor por defecto, no una restricción. Toda acción cuya ruta de Arcane cuelga de /environments/{id}/ admite un parámetro opcional environmentId; si se omite, se usa este valor. Usa environment.list para encontrar los IDs.
  • ARCANE_MCP_EXCLUDE_TOOLS reconoce IDs canónicos (container.kill), dominios (swarm_node), nombres de meta-herramienta (arcane_swarm_node) y nombres de herramienta individual (arcane_container_kill), de forma exacta (distingue mayúsculas). Una entrada que no coincide con ninguno no oculta nada y se nombra en un aviso al arrancar. Consulta Seguridad.
  • ARCANE_MCP_TIMEOUT acota las peticiones normales. Los flujos de progreso (descarga y construcción de imágenes; up, pull, build y redeploy de proyectos) se leen hasta el final, dentro de ARCANE_MCP_ACTION_TIMEOUT, que acota cada acción en su conjunto; las acciones de flujos en directo tienen su propio parámetro seconds; consulta Flujos y ficheros.
  • El modo HTTP no exige una credencial global del servidor: los clientes pueden aportar su propia clave de Arcane en X-Arcane-API-Key. Consulta Modo HTTP y Seguridad.
  • stdio lee un mensaje JSON-RPC por línea. Una línea que no lo es (no es JSON, es JSON pero no un mensaje, es un lote que la revisión del protocolo negociada no admite, pasa de ARCANE_MCP_STDIO_MAX_LINE_BYTES, 16 MiB por defecto, o un mensaje que anida JSON a más de 100 niveles, sin contar el propio array de un lote, que se rechaza antes de decodificarlo) se responde con un error JSON-RPC (-32700 o -32600) y la sesión continúa. Cerrar stdin termina el proceso con estado 0 en cuanto se han respondido las peticiones ya enviadas, así que echo '<petición>' | arcane-mcp y los scripts que cierran su extremo tras escribir reciben sus respuestas; la espera está limitada por ARCANE_MCP_ACTION_TIMEOUT, y una señal sigue terminando el proceso en 2 segundos como mucho. Arrancado a mano en un terminal (stdin es un terminal, algo que un cliente MCP nunca conecta), primero escribe una línea en stderr que dice que es un servidor MCP que debe arrancar un cliente, y dónde se explica cómo configurarlo.
  • Ajustes solo HTTP en stdio. Un servidor stdio ignora todos los ajustes ARCANE_MCP_HTTP_* salvo ARCANE_MCP_HTTP_ADDR (el token, los límites, TLS, el socket, los proxies y el cupo de autenticación). Cuando alguno está definido, en el entorno, en un fichero .env o con una opción, registra al arrancar un aviso que los nombra (nunca sus valores): stdio mode ignores HTTP-only settings, which apply only with ARCANE_MCP_HTTP_ADDR (--http): …. El servidor arranca como siempre, aunque alguno de esos valores no se pueda leer o esté fuera de rango (ARCANE_MCP_HTTP_RATE_LIMIT_RPS=abc, ARCANE_MCP_HTTP_SESSION_IDLE_TIMEOUT=-5s): esos valores solo los comprueba un servidor HTTP, que sigue negándose a arrancar con ellos. Una opción es distinta: un valor mal formado en la línea de órdenes (--http-rate-limit-rps abc) detiene cualquiera de los dos servidores, porque la línea de órdenes se lee antes de saber cuál es.

--http (o ARCANE_MCP_HTTP_ADDR) sirve Streamable HTTP en /mcp, además de dos sondas que nunca piden el token:

RutaResponde
/healthzVida (liveness): 200 ok mientras el proceso atiende, sea cual sea el estado de Arcane
/readyzDisponibilidad (readiness): 200 ready cuando Arcane responde a su comprobación de salud (GET /api/health, sin credencial) y el servidor no se está deteniendo; 503 not ready: … en otro caso. El resultado se guarda 5 segundos, para que las sondas no saturen Arcane. ?format=json añade la versión de Arcane y la del catálogo (campos); una versión distinta solo registra un aviso y nunca lo hace fallar

Lo que protege el transporte, con o sin token:

  • Un servidor por clave de Arcane, con límite. Cada X-Arcane-API-Key distinta tiene su propio servidor MCP. Se guardan como mucho ARCANE_MCP_HTTP_MAX_API_KEYS; el servidor de una clave solo se libera cuando no tiene sesiones vivas ni peticiones en curso (tras ARCANE_MCP_HTTP_API_KEY_IDLE_TIMEOUT, o en el acto cuando una clave nueva necesita el hueco), nunca cerrando la sesión de alguien. Si todos los servidores están en uso, una clave nueva recibe 503 con Retry-After y un error JSON-RPC que nombra el límite.
  • Una sesión queda ligada a su clave. Una petición sobre una sesión que lleva otra X-Arcane-API-Key distinta de la que la abrió (o ninguna, si se abrió con una) se rechaza con 403; la sesión sigue. El cliente debe enviar la misma clave en cada petición.
  • Sesiones y peticiones limitadas. Hay como mucho ARCANE_MCP_HTTP_MAX_SESSIONS sesiones vivas a la vez, una sesión inactiva durante ARCANE_MCP_HTTP_SESSION_IDLE_TIMEOUT se cierra (su siguiente petición recibe 404, la señal para inicializar de nuevo), se atienden como mucho ARCANE_MCP_HTTP_MAX_CONCURRENT_REQUESTS llamadas a la vez y un cuerpo mayor que ARCANE_MCP_HTTP_MAX_BODY_BYTES recibe 413. Un cuerpo con un mensaje que anida JSON a más de 100 niveles (sin contar el propio array de un lote) recibe 400 con un error JSON-RPC -40000, el id de la petición cuando va antes de la parte profunda, y la conexión cerrada; se mide mientras se lee, tras la autenticación, y nunca se decodifica. Una petición que supera un límite se rechaza en el acto con 503 y Retry-After; nunca queda esperando.
  • Hosts permitidos. Con ARCANE_MCP_HTTP_ALLOWED_HOSTS configurada, /mcp solo responde a una petición cuyo Host esté en la lista (403 en otro caso), en cualquier escucha; la lista sustituye entonces a la comprobación del SDK, que solo actúa en loopback, de modo que un proxy inverso en la misma máquina puede reenviar un nombre público. /healthz y /readyz no se restringen.
  • Protección entre orígenes. Una petición que un navegador hace en nombre de otro sitio (según Sec-Fetch-Site, o un Origin que nombra otro host) se rechaza con 403 en todos los métodos, salvo que su origen esté en ARCANE_MCP_HTTP_TRUSTED_ORIGINS, que además recibe las respuestas CORS que necesita el navegador. Los clientes que no envían Origin (todos los clientes MCP que no son navegadores) no se ven afectados. El SDK rechaza además una petición que llega a una dirección de loopback con un Host que no lo es (DNS rebinding).
  • Sin leer el cuerpo antes de autenticar. Los rechazos por falta de token, por un origen ajeno o por un host ajeno responden en el acto sin leer el cuerpo, con id null. Los rechazos posteriores leen como mucho 4 KiB del cuerpo, durante como mucho un segundo, para responder con el id de la petición. La petición completa debe llegar en dos minutos (las cabeceras en diez segundos); las respuestas y los flujos de eventos no tienen límite de tiempo.
  • Errores JSON-RPC. Todo rechazo lleva un cuerpo de error JSON-RPC, con el id de la petición cuando se ha leído: los estándar -32700, -32600 y -32601 cuando el fallo está en el propio mensaje y, si no, el estado HTTP por −100 (-40100 si falta el token, -40300, -42900, -50300…). El 404 de una sesión desconocida sigue siendo texto plano, como esperan los clientes.

ARCANE_URL puede listar varios gestores Arcane como pares nombre=url, por ejemplo ARCANE_URL=home=https://nas.lan:3552,lab=https://lab.example.com. Una única URL sin nombre funciona como antes. Los nombres usan minúsculas, dígitos, - y _; nombres y URL deben ser distintos, y toda URL de la lista debe ser http o https, sin credenciales (usuario:contraseña@), consulta ni fragmento.

  • Por HTTP cada petición nombra su instancia en la cabecera X-Arcane-URL: un nombre de la lista (home) o exactamente una URL de la lista (la barra final da igual). Si falta, se rechaza con 400; si no está en la lista, con 403; ambos son errores JSON-RPC que se responden antes de leer el cuerpo y de construir nada, y el valor nunca se repite en la respuesta. El servidor nunca envía una petición a una URL que su configuración no incluye, y nunca sigue una redirección de Arcane a otro esquema, host o puerto (una redirección dentro del mismo origen se sigue). En modo apikey, donde la instancia se comprueba antes que la clave, un nombre que no está en la lista cuenta contra el presupuesto de fallos de autenticación de la dirección del cliente, de modo que los nombres configurados no se pueden averiguar probando. Con una sola instancia la cabecera es opcional y, si se envía, debe nombrarla.
  • Cada instancia va aparte. La misma clave de Arcane en dos instancias tiene dos servidores, dos entradas en la caché de autenticación y dos cubos del límite de ritmo; una sesión queda ligada a su instancia igual que a su clave (403 si se usa con otra). En modo apikey la clave se comprueba con GET /api/auth/me en la instancia que nombra la petición. El presupuesto de fallos de autenticación sigue siendo por dirección de cliente, entre todas las instancias: cuenta los fallos del cliente, vayan a donde vayan.
  • Credenciales. ARCANE_API_KEY debe ser entonces una lista nombre=clave (una sola clave se enviaría a todas las instancias); una instancia sin clave solo atiende a clientes que traen la suya. ARCANE_USERNAME/ARCANE_PASSWORD sirven a una sola instancia, así que con varias por HTTP detienen el servidor al arrancar. ARCANE_ENVIRONMENT_ID puede ser un valor para todas o una lista nombre=id.
  • stdio sirve una instancia: con varias en la lista, ARCANE_MCP_INSTANCE (o --instance) debe nombrarla; su clave, su inicio de sesión y su entorno se usan como con una sola URL.
  • /readyz comprueba todas las instancias y las lista por nombre (nunca por URL): 200 ready cuando todas responden, 200 degraded cuando responden algunas (el servidor sigue atendiendo a los clientes de las demás, y un 503 lo sacaría de un balanceador para todos), 503 cuando no responde ninguna. Cada comprobación fallida queda en el log. La forma JSON (?format=json) lista en instances el name, el status y el versionMatch de cada instancia. /readyz no pide credencial, así que cualquiera que llegue a él conoce los nombres de las instancias (no sus URL) y si la versión de Arcane de cada una coincide con la del catálogo, nunca la versión exacta (solo la tiene el log).
  • El registro de auditoría nombra la instancia de cada llamada (instance=home); una URL sin nombre no añade nada.

ARCANE_MCP_HTTP_AUTH decide quién puede usar /mcp. En los dos modos el esquema Bearer se reconoce sin distinguir mayúsculas (bearer también vale).

  • token (predeterminado, el comportamiento de versiones anteriores): con ARCANE_MCP_HTTP_TOKEN cada petición necesita Authorization: Bearer <token>; cada cliente trae su clave de Arcane en X-Arcane-API-Key o actúa con la ARCANE_API_KEY o el inicio de sesión del servidor. Un cliente que envía la propia ARCANE_API_KEY del servidor se atiende exactamente igual que uno que no envía ninguna clave (esa clave y el inicio de sesión); cualquier otra clave nunca recibe el inicio de sesión. Un usuario remoto tiene entonces dos secretos.
  • apikey: el token Bearer es la clave de API de Arcane de quien llama, así que un cliente que solo puede poner Authorization (muchos conectores remotos, mcp-remote) no necesita nada más. La primera petición con una clave pregunta a Arcane GET /api/auth/me con ella (una lectura que cualquier usuario puede hacer de sí mismo; Arcane solo anota el último uso de la clave). La clave solo se acepta cuando Arcane responde 200 con su usuario; entonces se atiende durante ARCANE_MCP_HTTP_AUTH_CACHE_TTL sin volver a preguntar, y se olvida en el acto cuando una llamada con ella recibe 401 de Arcane (una clave revocada entretanto). Una clave que Arcane rechaza (401, o un token de acceso de entorno, que Arcane admite en X-API-Key pero que no es la clave de ningún usuario) recibe 401 con WWW-Authenticate: Bearer error="invalid_token". Cualquier otra respuesta (Arcane inaccesible, un 403 o una redirección de algo que está delante, una página que no es de Arcane) recibe 503 con Retry-After, y no se recuerda nada. No se recurre a ninguna credencial del servidor, así que en este modo ARCANE_MCP_HTTP_TOKEN, ARCANE_API_KEY y el inicio de sesión se rechazan al arrancar. X-Arcane-API-Key no hace falta; si un cliente la envía igualmente debe ser la misma clave que el Bearer (400 si no). Las sesiones quedan ligadas a la clave del Bearer, igual que a X-Arcane-API-Key en modo token. Pon TLS delante: el Bearer es una credencial de Arcane.

Los ajustes que un modo ignoraría detienen el servidor al arrancar: una caché con un TTL distinto del predeterminado en modo token, y proxies de confianza con el presupuesto desactivado.

Presupuesto de fallos de autenticación. En los dos modos, un token erróneo o una clave que Arcane rechaza cuentan contra la dirección del cliente; tras ARCANE_MCP_HTTP_AUTH_MAX_FAILURES dentro de ARCANE_MCP_HTTP_AUTH_FAILURE_WINDOW (10 por minuto por defecto) la dirección recibe 429 con Retry-After y un error JSON-RPC (-42900) hasta que acaba la ventana, sin que se compruebe su credencial. Solo cuentan las autenticaciones fallidas: una credencial ausente, un origen o un host rechazados, un servidor lleno, un cuerpo demasiado grande o una petición correcta nunca cuentan. En modo apikey, una clave que Arcane ya aceptó sigue funcionando desde una dirección bloqueada (la respuesta sale de memoria), así que un cliente que prueba claves no deja fuera a los demás detrás de la misma dirección. La dirección del cliente es la del otro extremo de la conexión; los clientes IPv6 se cuentan por su /64, y un /48 de IPv6 se bloquea entero, durante lo que queda de la ventana, cuando ha tenido ARCANE_MCP_HTTP_AUTH_NETWORK_FACTOR (10) veces ARCANE_MCP_HTTP_AUTH_MAX_FAILURES credenciales rechazadas dentro de ella, sumando todos sus /64 (100 por minuto por defecto), así que quien tiene un /48 no puede ir rotando por sus 65.536 presupuestos. ARCANE_MCP_HTTP_AUTH_NETWORK_FACTOR=0 desactiva el límite por /48 (cada /64 conserva su propio presupuesto, y un /48 puede rotar por ellos); un factor mayor hace el bloqueo más difícil de alcanzar, tanto para los demás como para un atacante. Ese bloqueo alcanza también a los demás /64 del /48, incluidos los clientes de un operador móvil o de un proveedor que da un /64 (o un /56 o /60) a cada abonado dentro de un /48 compartido; unas pocas credenciales caducadas no llegan a él, pero cualquiera dentro del /48 que gaste tantos intentos puede dejar fuera a los demás durante el resto de una ventana. Detrás de un proxy inverso, todos los clientes llegan desde la dirección del proxy y comparten por tanto un único presupuesto, salvo que ARCANE_MCP_HTTP_TRUSTED_PROXIES incluya el proxy y ARCANE_MCP_HTTP_TRUSTED_PROXY_HEADER nombre la cabecera que rellena; la cabecera solo se cree si viene de un proxy de la lista y se lee de derecha a izquierda, saltando los saltos de confianza. Se siguen como mucho 4096 direcciones a la vez; por encima, los fallos de todas las direcciones adicionales comparten un único presupuesto, y cuando se agota todas ellas quedan rechazadas hasta que caduca (en modo apikey, las claves ya aceptadas siguen pasando). Con el límite por /48 activo, un solo /48 no puede llegar ahí, porque se bloquea tras tantos presupuestos de fallos como indique el factor; llenar la tabla exige fallos desde 4096 direcciones IPv4, o desde unos 410 /48, a la vez. También se siguen como mucho 4096 /48; uno más no se agrega (sus /64 conservan su propio presupuesto) en lugar de compartir un registro que bloquearía a todos los clientes IPv6.

Límite de ritmo. Con ARCANE_MCP_HTTP_RATE_LIMIT_RPS configurada, cada clave de Arcane tiene un cubo de ARCANE_MCP_HTTP_RATE_LIMIT_BURST fichas que se rellena a ese ritmo, igual en el transporte con estado que en el sin estado, y que se conserva hasta que se rellena aunque se libere el servidor de la clave. Cada petición JSON-RPC gasta una (incluidas initialize, tools/list y tools/call; algunos clientes envían además server/discover al conectar), y un lote (en las revisiones del protocolo que lo admiten) gasta una por cada petición que contiene; las notificaciones y las respuestas nunca, de modo que una notificación rechazada nunca rompe la sesión de un cliente. Por encima del límite, una petición recibe 429, Retry-After con los segundos hasta la siguiente ficha y un error JSON-RPC -42900 con el id de la petición; un lote mayor que la ráfaga se rechaza entero, y un cuerpo que empieza un lote pero no es JSON válido recibe 400 con -32700. Las peticiones rechazadas antes de conocer su clave (autenticación, los límites de arriba) no gastan nada.

  • TLS. Con ARCANE_MCP_HTTP_TLS_CERT y ARCANE_MCP_HTTP_TLS_KEY el puerto habla solo HTTPS, TLS 1.2 o posterior. Los ficheros se leen al arrancar (un par que falta, no se puede leer o no casa detiene el servidor) y se vuelven a mirar como mucho una vez por segundo según llegan conexiones: un certificado renovado (certbot, cert-manager, un secreto montado) se sirve sin reiniciar, y un cambio que no se puede cargar (un fichero a medio escribir) mantiene el certificado que ya se servía y queda en el log una vez. Los handshakes fallidos (escáneres de puertos, HTTP sin cifrar enviado al puerto HTTPS, clientes que rechazan un certificado autofirmado) quedan en el log como un aviso por minuto con el número de los omitidos desde el anterior (los omitidos al final de una ráfaga se cuentan un minuto después), y cada uno en nivel debug. TLS no cambia la autenticación: sin token siguen valiendo los avisos de red de confianza.
  • HTTP sin cifrar en la red. Un puerto TCP sin TLS al que llegan otras máquinas (un comodín como :8080 o 0.0.0.0:8080, que es lo que escucha un contenedor, una dirección enrutable o un nombre que resuelve a algo que no es loopback) registra un aviso al arrancar, en cualquier modo de autenticación: el token, las claves de Arcane y cada respuesta cruzan la red en claro. ARCANE_MCP_HTTP_ALLOW_PLAINTEXT=true (o --http-allow-plaintext) declara que algo delante cifra ese tramo, como un proxy inverso que termina TLS y llega al servidor por una red privada o un puente de contenedores; la línea se registra entonces en INFO. ARCANE_MCP_HTTP_ALLOW_PLAINTEXT=false es el modo endurecido: un puerto así detiene el servidor al arrancar (estado 1) con un mensaje que nombra la dirección y las salidas, mientras que TLS en el propio servidor, una dirección de loopback (o un nombre que solo resuelve a loopback) y un socket unix arrancan como siempre. La opción gana a la variable, pero una variable ilegible (ARCANE_MCP_HTTP_ALLOW_PLAINTEXT=maybe) sigue deteniendo un servidor HTTP aunque también se dé la opción, como con cualquier ajuste.
  • Socket unix. Cuando ARCANE_MCP_HTTP_ADDR es una ruta (contiene /, o \ en Windows) o unix:<ruta>, el servidor escucha en un socket unix con ARCANE_MCP_HTTP_SOCKET_MODE (creado solo para el propietario y luego con esos permisos). Un socket que dejó una ejecución anterior solo se sustituye si es un socket en el que no responde nadie; cualquier otro fichero, o un servidor vivo, detiene el arranque. El socket se borra al parar. A un socket solo llegan los procesos que permiten sus permisos y nunca un navegador, así que no se emiten los avisos de red de confianza ni de DNS rebinding; ARCANE_MCP_HTTP_ALLOWED_HOSTS y las comprobaciones de origen funcionan igual que en TCP. Las conexiones de un socket no tienen dirección de cliente: el presupuesto de fallos de autenticación las carga todas a una misma clave, unix, salvo que ARCANE_MCP_HTTP_TRUSTED_PROXIES contenga unix (un proxy inverso en el mismo equipo) y ARCANE_MCP_HTTP_TRUSTED_PROXY_HEADER nombre al cliente. Windows 10 y posteriores también tienen sockets unix (C:\ProgramData\arcane-mcp\mcp.sock, o unix:C:\...), pero no bits de permisos: el socket toma la lista de control de acceso de su directorio, así que ponlo en un directorio que solo puedan abrir los usuarios previstos; allí ARCANE_MCP_HTTP_SOCKET_MODE no decide quién puede conectarse.
  • arcane-mcp --probe pide /healthz al puerto local (/readyz con --ready) y termina con 0 ante un 200 y con 1 en otro caso, dentro de --timeout (3 s). Lee ARCANE_MCP_HTTP_ADDR y ARCANE_MCP_HTTP_TLS_CERT igual que el servidor (un fichero .env, el entorno, o --http / --http-tls-cert tras --probe), no necesita URL ni credencial de Arcane y nunca arranca un servidor. Una dirección comodín (:8080, 0.0.0.0, [::]) se consulta en loopback; HTTPS a loopback o a un socket no se verifica (la sonda pregunta a su propio servidor), en otro caso se verifica con las raíces del sistema y el certificado configurado. Un puerto 0 no se puede encontrar: pasa el puerto del log con --http. Sin dirección HTTP (modo stdio) lo dice y termina con 0. El HEALTHCHECK de la imagen la ejecuta: un contenedor HTTP queda sano cuando responde /healthz, y uno stdio (docker run -i) queda sano mientras se ejecuta, en vez de marcarse como no sano por no tener un puerto que nunca tuvo.
  • /healthz?format=json (o Accept: application/json sin más; el application/json, text/event-stream de un cliente MCP mantiene la respuesta en texto) responde {"status":"ok","draining":false,"version":…,"commit":…,"date":…,"configDigest":…}. El resumen son los 12 primeros dígitos hexadecimales de un SHA-256 de los ajustes que dan forma al servidor (superficie, modos de solo lectura y seguro, exclusiones, plazos, límites, el modo de autenticación, los nombres de instancia…), nunca una credencial, una URL ni una ruta: dos réplicas con el mismo resumen se arrancaron igual. ok en texto plano sigue siendo lo predeterminado.
  • Vaciado. Con ARCANE_MCP_HTTP_DRAIN_DELAY, SIGTERM pone primero /readyz en 503 (y draining en true) mientras el servidor sigue atendiendo, para que un balanceador deje de enviar peticiones nuevas; pasado ese tiempo se hace la parada ordenada de siempre. Mantén el retraso por debajo del plazo de parada del orquestador (10 s por defecto en Docker).

Por HTTP el servidor publica una tarjeta del servidor (SEP-2127, tipo de medio application/mcp-server-card+json) en /mcp/server-card, el lugar que la extensión reserva junto al punto final MCP, y en /server-card. Un cliente o un registro la lee antes de conectarse, sin credencial. Contiene:

  • la identidad del servidor, como en su entrada del registro MCP: name (io.github.jmrplens/arcane-mcp), version (la de la compilación en marcha), title, description, websiteUrl, repository e icons;
  • un punto final Streamable HTTP, {baseUrl}/mcp. baseUrl es una variable que el cliente rellena con la dirección desde la que obtuvo la tarjeta, porque el servidor no puede saber la dirección por la que lo alcanzan los clientes (detrás de un proxy, una redirección de puertos o un socket);
  • las revisiones del protocolo que sirve ese punto final (2026-07-28 solo con ARCANE_MCP_HTTP_STATELESS);
  • las cabeceras que necesita una conexión, según el modo de autenticación, nunca con su valor: Authorization (obligatoria) cuando ARCANE_MCP_HTTP_TOKEN está definido o en modo apikey; X-Arcane-API-Key en modo token, marcada como obligatoria solo cuando no hay token y ninguna instancia tiene clave o inicio de sesión propios (con token aparece como opcional, y su descripción no dice si el servidor tiene credencial de Arcane propia); X-Arcane-URL, obligatoria con varias instancias cuando no hay token o en modo apikey, y con token siempre como opcional, para que la tarjeta no diga cuántas instancias hay.

Nunca contiene herramientas, recursos, prompts ni capacidades (la extensión los deja al listado en vivo), ninguna credencial ni nada sobre las instancias de Arcane que hay detrás (ni URL, ni nombre de instancia, ni versión de Arcane). La versión de la compilación que muestra es la que ya muestra /healthz?format=json.

La respuesta lleva Cache-Control: public, max-age=3600 y un ETag (derivado de los bytes de la tarjeta, así que las réplicas coinciden): una petición con If-None-Match recibe 304. Cualquier origen puede leerla (Access-Control-Allow-Origin: *), como pide la extensión para metadatos públicos; OPTIONS responde a la comprobación previa, y cualquier método que no sea GET, HEAD u OPTIONS recibe 405. ARCANE_MCP_HTTP_ALLOWED_HOSTS se aplica como en /mcp.

Cada dirección de cliente tiene un cubo de fichas en estas rutas (ARCANE_MCP_HTTP_DISCOVERY_RATE_LIMIT_RPS, 20 por segundo, y ARCANE_MCP_HTTP_DISCOVERY_RATE_LIMIT_BURST, 200), tanto si la petición recibe 200 o 304 como si es una comprobación previa; detrás de un proxy la dirección la decide ARCANE_MCP_HTTP_TRUSTED_PROXIES, igual que para el presupuesto de fallos de autenticación. Pasado el límite, una petición recibe 429, Retry-After y un error JSON-RPC -42900. Cualquiera de los dos ajustes a 0 desactiva el límite, para un proxy que ya limita estas rutas.

Está activada por defecto porque no le dice a un llamante sin autenticar nada que no pudiera saber ya por /mcp y /healthz: /healthz?format=json muestra la versión de la compilación; sin token /mcp responde a cualquiera, así que no es ningún secreto si un cliente debe traer su propia clave de Arcane; con token /mcp responde 401, que dice que hace falta un token, y entonces la tarjeta no dice si el servidor tiene credencial de Arcane propia; con varias instancias, /mcp sin token, o en modo apikey con cualquier Bearer, responde 400 a una petición sin X-Arcane-URL antes de comprobar la clave, mientras que con token pide primero el token y entonces la tarjeta tampoco dice cuántas hay. Un cliente que descubre servidores necesita la tarjeta. ARCANE_MCP_HTTP_SERVER_CARD=off quita las dos rutas (responden 404).

ARCANE_MCP_HTTP_STATELESS=on (o --http-stateless) sirve el transporte Streamable HTTP sin estado que exige la revisión 2026-07-28 del protocolo. Está desactivado por defecto: el transporte con estado atiende hoy a todos los clientes, y los que hablan 2026-07-28 vuelven a 2025-11-25 con él, mientras que el transporte sin estado quita algo a los clientes de la era 2025 (consulta la tabla). Las protecciones del Modo HTTP se aplican a ambos, salvo las que tratan de sesiones.

Con estado (predeterminado)Sin estado
Revisiones del protocolo2025-11-25 y anteriores; a un cliente 2026-07-28 se le indica que vuelva a una anterior2026-07-28 y anteriores
SesionesMcp-Session-Id, ligada a la clave que la abrió (403 con otra clave)Ninguna: un Mcp-Session-Id recibido se ignora, nunca se rechaza
Clave de ArcaneLa de la apertura de la sesiónSe lee en cada POST (X-Arcane-API-Key, o si no la clave o el inicio de sesión del servidor), así que peticiones seguidas pueden usar claves distintas
GET (flujo de eventos), DELETESe atienden405 con Allow: POST y un error JSON-RPC (-40500)
Confirmación de llamadas destructivasElicitación en todas las revisionesEn 2026-07-28 la pregunta viaja en el resultado de la llamada y el cliente reintenta con la respuesta; a un cliente de la era 2025 no se le puede preguntar (haría falta una petición del servidor fuera de una llamada) y recibe en el acto el rechazo que pide confirm: true
Notificaciones de progresoEn el flujo de eventos de la propia llamadaIgual: viajan en el flujo de eventos del POST mientras dura la llamada
ARCANE_MCP_HTTP_MAX_SESSIONS, ARCANE_MCP_HTTP_SESSION_IDLE_TIMEOUTSe aplicanNo se aplican
El servidor de una clave cuenta como en usoMientras tiene una sesión viva o una petición en cursoSolo mientras atiende una petición

En el transporte sin estado, una llamada 2026-07-28 cuyo cliente se ha ido se cancela, con su petición a Arcane, porque su respuesta ya no puede entregarse. El servidor no envía pings de keep-alive en ningún transporte. El token, las comprobaciones de host y de origen, los límites de cuerpo y de concurrencia, el límite de claves y los rechazos JSON-RPC se comportan igual; el 405 se responde tras comprobar el token y sin leer el cuerpo.

Un asistente de solo lectura en la superficie meta, fijado a un entorno remoto:

Ventana de terminal
ARCANE_URL=https://arcane.example.com \
ARCANE_API_KEY=arc_... \
./arcane-mcp --tool-surface meta --read-only --environment 6791a839-...

Un cliente de navegador en otro origen, como el MCP Inspector en http://localhost:6274 conectándose directamente:

Ventana de terminal
./arcane-mcp --http 127.0.0.1:8080 --http-trusted-origins http://localhost:6274

Un punto HTTP compartido por un equipo, en el que cada miembro aporta su propia clave de Arcane, accesible desde una aplicación web:

Ventana de terminal
ARCANE_URL=https://arcane.example.com \
ARCANE_MCP_HTTP_TOKEN=$(openssl rand -hex 32) \
./arcane-mcp --http 0.0.0.0:8080 --http-max-api-keys 20 \
--http-trusted-origins https://app.example.com \
--http-allowed-hosts mcp.example.com

Un endpoint remoto al que cada usuario se conecta solo con su clave de API de Arcane como token Bearer (para conectores que solo pueden poner Authorization), detrás de un proxy inverso en 10.0.0.2, con 5 llamadas por segundo por clave:

Ventana de terminal
ARCANE_URL=https://arcane.example.com \
ARCANE_MCP_HTTP_AUTH=apikey \
./arcane-mcp --http 0.0.0.0:8080 --http-allowed-hosts mcp.example.com \
--http-trusted-proxies 10.0.0.2 --http-trusted-proxy-header X-Forwarded-For \
--http-rate-limit-rps 5

El transporte sin estado detrás de un proxy inverso, para clientes que hablan la revisión 2026-07-28 del protocolo:

Ventana de terminal
ARCANE_URL=https://arcane.example.com \
ARCANE_MCP_HTTP_TOKEN=$(openssl rand -hex 32) \
./arcane-mcp --http 0.0.0.0:8080 --http-stateless --http-allowed-hosts mcp.example.com

Todo salvo la gestión de nodos Swarm y la limpieza de imágenes, con vista previa de cada cambio:

Ventana de terminal
ARCANE_MCP_EXCLUDE_TOOLS=swarm_node,image.prune \
ARCANE_MCP_SAFE_MODE=true \
./arcane-mcp