LightNow MCP Proxy

LightNow MCP Proxy

Conecte seus clientes de IA aos seus servidores MCP—gerenciados com segurança em um só lugar.

O LightNow MCP Proxy é o runtime local por trás dos perfis LightNow. Conecte Codex, Claude Desktop, Cursor, VS Code ou Antigravity uma única vez e depois gerencie os servidores MCP disponíveis para esse cliente no LightNow, em vez de copiar a configuração do servidor e os segredos em cada ferramenta.

• Mantenha o acesso MCP organizado em perfis pessoais e organizacionais.
• Conecte stdio locais e servidores HTTP Streamable remotos por meio de um único ponto de entrada.
• Resolva credenciais na máquina do usuário em vez de incorporá-las na configuração do cliente MCP.
• Aplique alterações de perfil e políticas sem reconstruir cada configuração de cliente.
• Observe a saúde do cliente, perfil, servidor e uso de ferramentas. Os argumentos das ferramentas são capturados por padrão com campos semelhantes a credenciais redigidos e podem ser desativados; resultados de ferramentas e segredos resolvidos nunca são coletados.

O comando instalado permanece lightnow-proxy. Ele é executado localmente, usa a sessão CLI do LightNow vinculada à identidade, resolve o perfil selecionado e roteia solicitações de ferramentas e recursos para os servidores MCP do perfil.

As capacidades vêm do seu perfil LightNow

O proxy deliberadamente não inclui ferramentas de demonstração. Suas capacidades MCP são as ferramentas e recursos reais expostos pelos servidores selecionados no perfil LightNow ativo, portanto a lista difere entre equipes e clientes. Nomes como github__create_issue identificam tanto o servidor upstream quanto sua ferramenta e evitam colisões quando vários servidores usam o mesmo nome de ferramenta.

O proxy suporta a revisão oficial do MCP 2026-07-28 com metadados de protocolo sem estado, por solicitação, e server/discover. Ele mantém compatibilidade automática com servidores e clientes da era do handshake por meio de 2025-11-25.

Instalação

Requisitos:

• Python 3.11 ou superior
• pipx
• uma conta LightNow
• a CLI do LightNow

pipx install lightnow-cli
lightnow login

Instale o proxy com Homebrew:

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

Ou instale com pipx:

pipx install lightnow-proxy

Ou instale com uv:

uv tool install lightnow-proxy

O pacote Python instala o comando lightnow-proxy usado pelos clientes MCP.

Para desenvolvimento local no repositório:

uv tool install --from . lightnow-proxy

Atualize as instalações suportadas de CLI e Proxy por meio da CLI do LightNow:

lightnow update --check
lightnow update

Homebrew, pipx e uv são gerenciados. O proxy apenas relata sua versão observada e o estado de atualização em heartbeats somente de metadados; ele nunca invoca um gerenciador de pacotes nem atrasa a inicialização do MCP para verificar versões.

Configurar um Cliente

Use a CLI do LightNow. Ela grava a entrada MCP do cliente e a configuração do 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

Reinicie o cliente MCP após a sincronização.

Múltiplas contas e organizações

Use um alias --connection distinto para cada conta, organização ou perfil que deve aparecer no mesmo 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 configuração de proxy gerada tem um ID de conexão estável e aponta para uma sessão CLI nomeada em ~/.lightnow/sessions/. Ela também registra o emissor e o assunto esperados. O proxy recusa solicitações do Registry quando esses valores não correspondem, portanto um login CLI posterior não pode alternar silenciosamente uma conexão existente. Nenhum token de acesso ou atualização é gravado no YAML do proxy.

Verifique a configuração local:

lightnow config-status --client codex

Verifique se o proxy consegue resolver o perfil selecionado e alcançar seus servidores MCP upstream:

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

Por padrão, isso lê ~/.lightnow/lightnow-proxy/default.yaml, que é gravado quando o perfil padrão é sincronizado no modo Proxy Local. Para uma configuração específica de cliente, passe o caminho gerado explicitamente:

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

Conexões nomeadas usam arquivos separados, como ~/.lightnow/lightnow-proxy/codex-lightnow-acme.yaml. O relatório de saúde em JSON mostra seu alias de conexão não secreto, ID, rótulo da conta, escopo, perfil e status de vinculação de identidade. Configurações legadas que usam cli_config_path permanecem legíveis, mas são restritas ao emissor de autenticação configurado.

Quando a telemetria está habilitada, verificações de saúde ativas e eventos de runtime são enviados ao LightNow Control Plane. Os argumentos de chamadas de ferramenta são capturados por padrão e podem ser desativados independentemente nas configurações do Proxy Local. Campos semelhantes a credenciais são redigidos antes da transmissão. O proxy também envia presença de dispositivo imediatamente na inicialização e a cada dois minutos. O Control Plane pode então mostrar quais dispositivos, clientes e perfis estão ativos, saudáveis, degradados ou com falha, juntamente com versões de CLI/Proxy e status de atualização. Resultados de ferramentas, segredos LightNow resolvidos, valores de autorização não redigidos, endereços de rede, identificadores de hardware e caminhos locais não são armazenados. Campos de argumento semelhantes a credenciais, incluindo cabeçalhos de autorização, são substituídos por [REDACTED] antes da transmissão.

Provedores de cofre configurados para resolução em runtime são resolvidos neste host, após a API do Registry retornar uma referência de provedor sem credenciais ou um valor secreto. A auto-autenticação do HashiCorp Vault Proxy em 127.0.0.1:8200 é o padrão. Listeners de loopback específicos do provedor podem ser mapeados em runtime_secrets.providers no YAML gerado; a CLI do LightNow preserva esses mapeamentos não secretos em sincronizações subsequentes. O caminho opcional do keyring do SO está disponível com lightnow-proxy[keyring]. Falhas de resolução são fail-closed e valores em texto puro nunca são adicionados ao cache de esquema de ferramentas.

Arquivos de runtime gerenciados

Servidores STDIO podem anexar runtime_files limitados e não secretos à configuração do cliente do Runtime Profile. O LightNow Proxy grava cada conjunto de arquivos em ~/.lightnow/runtime-files em um diretório imutável endereçado por conteúdo antes de o processo upstream iniciar. Os arquivos usam o modo 0600; diretórios gerenciados usam o modo 0700.

Referencie o diretório resolvido com ${LIGHTNOW_RUNTIME_DIR} em argumentos, valores de ambiente ou no diretório de trabalho:

{
  "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"
    }
  ]
}

Os arquivos de runtime são texto UTF-8 e são limitados a 16 arquivos, 64 KiB por arquivo e 256 KiB por configuração de servidor. Os caminhos devem ser relativos e não podem conter segmentos de travessia ou barras invertidas. Valores secretos devem permanecer nos buckets de segredos de runtime do LightNow; os arquivos podem referenciar os nomes de ambiente correspondentes, mas não devem incorporar credenciais em texto puro. Materializações inválidas ou modificadas falham de forma fechada antes de o upstream iniciar.

Mais Documentação

Guias de configuração detalhados, exemplos, diagramas, caminhos de clientes suportados, comportamento de telemetria e solução de problemas estão na documentação do LightNow:

• Conectar clientes MCP
• Referência da CLI
• Processo de lançamento

Desenvolvimento Local

Para colaboradores que trabalham neste repositório:

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

Execute o proxy com a configuração de exemplo:

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

Execute o proxy como um servidor MCP stdio:

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

Execute uma verificação de saúde local contra a configuração de exemplo:

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