LightNow MCP Proxy

Conecta tus clientes de IA a tus servidores MCP—gestionados de forma segura en un solo lugar.

GitHub
2
Prueba este MCPPatrocinado

Documentación

LightNow MCP Proxy

PyPI Official MCP Registry Listed on LightNow

Conecta tus clientes de IA a tus servidores MCP, gestionados de forma segura en un solo lugar.

El LightNow MCP Proxy es el runtime local detrás de los perfiles de LightNow. Conecta Codex, Claude Desktop, Cursor, VS Code o Antigravity una sola vez, y luego gestiona los servidores MCP disponibles para ese cliente en LightNow en lugar de copiar la configuración del servidor y los secretos en cada herramienta.

  • Mantén el acceso MCP organizado en perfiles personales y de organización.
  • Conecta stdio locales y servidores remotos Streamable HTTP a través de una sola entrada.
  • Resuelve credenciales en la máquina del usuario en lugar de incrustarlas en la configuración del cliente MCP.
  • Aplica cambios de perfil y políticas sin reconstruir cada configuración de cliente.
  • Observa la salud de clientes, perfiles, servidores y el uso de herramientas. Los argumentos de herramientas se capturan por defecto con campos similares a credenciales redactados y se pueden deshabilitar; los resultados de herramientas y los secretos resueltos nunca se recopilan.

El comando instalado permanece como lightnow-proxy. Se ejecuta localmente, utiliza la sesión CLI de LightNow vinculada a la identidad, resuelve el perfil seleccionado y enruta las solicitudes de herramientas y recursos a los servidores MCP del perfil.

Las capacidades provienen de tu perfil de LightNow

El proxy deliberadamente no incluye herramientas de demostración. Sus capacidades MCP son las herramientas y recursos reales expuestos por los servidores seleccionados en el perfil activo de LightNow, por lo que la lista difiere entre equipos y clientes. Nombres como github__create_issue identifican tanto el servidor upstream como su herramienta y evitan colisiones cuando varios servidores usan el mismo nombre de herramienta.

El proxy soporta la revisión oficial de MCP 2026-07-28 con metadatos de protocolo sin estado y por solicitud, y server/discover. Mantiene compatibilidad automática con servidores y clientes de la era del handshake a través de 2025-11-25.

Instalación

Requisitos:

pipx install lightnow-cli
lightnow login

Instala el proxy con Homebrew:

brew tap lightnow-ai/tap
brew install lightnow-proxy

O instálalo con pipx:

pipx install lightnow-proxy

O instálalo con uv:

uv tool install lightnow-proxy

El paquete de Python instala el comando lightnow-proxy utilizado por los clientes MCP.

Para desarrollo local en el repositorio:

uv tool install --from . lightnow-proxy

Actualiza las instalaciones compatibles de CLI y Proxy a través de la CLI de LightNow:

lightnow update --check
lightnow update

Homebrew, pipx y uv están gestionados. El proxy solo reporta su versión observada y el estado de actualización en heartbeats de solo metadatos; nunca invoca un gestor de paquetes ni retrasa el inicio de MCP para verificar versiones.

Configurar un Cliente

Usa la CLI de LightNow. Esta escribe la entrada MCP del cliente y la configuración del Proxy Local por cliente.

lightnow sync --client codex --local-proxy
lightnow sync --client claude-desktop --local-proxy
lightnow sync --client cursor --local-proxy
lightnow sync --client vscode --local-proxy
lightnow sync --client antigravity --local-proxy

Reinicia el cliente MCP después de sincronizar.

Múltiples cuentas y organizaciones

Usa un alias distinto de --connection para cada cuenta, organización o perfil que deba aparecer en el mismo cliente MCP:

lightnow login
lightnow sync --client codex --local-proxy \
  --connection lightnow-personal --profile default

# Sign in with the organization account before creating this connection.
lightnow login
lightnow sync --client codex --local-proxy \
  --connection lightnow-acme --tenant <tenant-id> --profile engineering

Cada configuración de proxy generada tiene un ID de conexión estable y apunta a una sesión CLI nombrada bajo ~/.lightnow/sessions/. También registra el emisor y el sujeto esperados. El proxy rechaza solicitudes de Registry cuando esos valores no coinciden, por lo que un inicio de sesión CLI posterior no puede cambiar silenciosamente una conexión existente. No se escribe ningún token de acceso o actualización en el YAML del proxy.

Verifica la configuración local:

lightnow config-status --client codex

Verifica si el proxy puede resolver el perfil seleccionado y alcanzar sus servidores MCP upstream:

lightnow-proxy --health
lightnow-proxy --health --json

Por defecto, esto lee ~/.lightnow/lightnow-proxy/default.yaml, que se escribe cuando el perfil predeterminado se sincroniza en modo Proxy Local. Para una configuración específica de cliente, pasa la ruta generada explícitamente:

lightnow-proxy --config ~/.lightnow/lightnow-proxy/codex.yaml --health
lightnow-proxy --config ~/.lightnow/lightnow-proxy/codex.yaml --health --json

Las conexiones nombradas usan archivos separados como ~/.lightnow/lightnow-proxy/codex-lightnow-acme.yaml. El informe de salud JSON muestra su alias de conexión no secreto, ID, etiqueta de cuenta, alcance, perfil y estado de vinculación de identidad. Las configuraciones heredadas que usan cli_config_path siguen siendo legibles, pero están restringidas al emisor de autenticación configurado.

Cuando la telemetría está habilitada, las verificaciones de salud activas y los eventos de runtime se envían al LightNow Control Plane. Los argumentos de llamadas de herramientas se capturan por defecto y se pueden deshabilitar de forma independiente en la configuración del Proxy Local. Los campos similares a credenciales se redactan antes de la transmisión. El proxy también envía presencia del dispositivo inmediatamente al inicio y cada dos minutos. El Control Plane puede entonces mostrar qué dispositivos, clientes y perfiles están activos, saludables, degradados o fallando, junto con las versiones de CLI/Proxy y el estado de actualización. Los resultados de herramientas, los secretos resueltos de LightNow, los valores de autorización no redactados, las direcciones de red, los identificadores de hardware y las rutas locales no se almacenan. Los campos de argumentos similares a credenciales, incluidos los encabezados de autorización, se reemplazan con [REDACTED] antes de la transmisión.

Los proveedores de vault configurados para resolución en runtime se resuelven en este host, después de que la API de Registry haya devuelto una referencia de proveedor sin credenciales o un valor secreto. La auto-autenticación de HashiCorp Vault Proxy en 127.0.0.1:8200 es el valor predeterminado. Los listeners de loopback específicos del proveedor se pueden mapear bajo runtime_secrets.providers en el YAML generado; la CLI de LightNow preserva estos mapeos no secretos en sincronizaciones posteriores. La ruta opcional del keyring del sistema operativo está disponible con lightnow-proxy[keyring]. Los fallos de resolución cierran de forma segura y los valores en texto plano nunca se agregan a la caché del esquema de herramientas.

Archivos de runtime gestionados

Los servidores STDIO pueden adjuntar runtime_files acotados y no secretos a su configuración de cliente de Runtime Profile. LightNow Proxy escribe cada conjunto de archivos bajo ~/.lightnow/runtime-files en un directorio inmutable direccionado por contenido antes de que se inicie el proceso upstream. Los archivos usan el modo 0600; los directorios gestionados usan el modo 0700.

Referencia el directorio resuelto con ${LIGHTNOW_RUNTIME_DIR} en argumentos, valores de entorno o el directorio de trabajo:

{
  "transport": "stdio",
  "command": "npx",
  "args": [
    "@bytebase/dbhub@latest",
    "--config",
    "${LIGHTNOW_RUNTIME_DIR}/dbhub.toml"
  ],
  "env": {
    "DBHUB_DSN": "${DBHUB_DSN}"
  },
  "runtime_files": [
    {
      "path": "dbhub.toml",
      "content": "[[sources]]\nid = \"analytics\"\ndsn = \"${DBHUB_DSN}\"\n"
    }
  ]
}

Los archivos de runtime son texto UTF-8 y están limitados a 16 archivos, 64 KiB por archivo y 256 KiB por configuración de servidor. Las rutas deben ser relativas y no pueden contener segmentos de traversal ni barras invertidas. Los valores secretos deben permanecer en los buckets de secretos de runtime de LightNow; los archivos pueden referirse a los nombres de entorno correspondientes pero no deben incrustar credenciales en texto plano. Las materializaciones inválidas o modificadas cierran de forma segura antes de que el upstream se inicie.

Más Documentación

Guías detalladas de configuración, ejemplos, diagramas, rutas de clientes compatibles, comportamiento de telemetría y solución de problemas viven en la documentación de LightNow:

Desarrollo Local

Para contribuyentes que trabajan en este repositorio:

uv venv
uv pip install -e .[dev]
make test

Ejecuta el proxy con la configuración de ejemplo:

uv run lightnow-proxy --config config.example.yaml

Ejecuta el proxy como servidor MCP stdio:

uv run lightnow-proxy --config config.example.yaml --transport stdio

Ejecuta una verificación de salud local contra la configuración de ejemplo:

uv run lightnow-proxy --config config.example.yaml --health