Litmus MCP Server

Permite que LLMs e sistemas inteligentes interajam com o Litmus Edge para configuração, monitoramento e gerenciamento de dispositivos.

GitHub

Experimente este MCPPatrocinado

Documentação

Litmus MCP Server

O Litmus Automation oficial Servidor Model Context Protocol (MCP) permite que LLMs e sistemas inteligentes interajam com o Litmus Edge para configuração, monitoramento e gerenciamento de dispositivos. Ele é construído sobre o SDK MCP e segue a especificação Model Context Protocol.

Início Rápido

Iniciar um servidor MCP HTTP usando Docker

Execute o servidor em Docker (somente HTTP)

docker run -d --name litmus-mcp-server -p 8000:8000 ghcr.io/litmusautomation/litmus-mcp-server:latest

O servidor HTTP expõe ambos os transportes MCP na porta 8000:

http://<host>:8000/mcp - HTTP Streamable (especificação MCP atual, recomendado)
http://<host>:8000/sse - HTTP+SSE (transporte legado, mantido para clientes mais antigos)

Clientes que suportam HTTP Streamable devem apontar para /mcp (ex.: "type": "http", como no exemplo do Claude Code abaixo). Os demais exemplos de clientes usam o endpoint SSE; troque para /mcp se o seu cliente suportar, mantendo os mesmos cabeçalhos.

NOTA: O Litmus MCP Server é construído para plataformas linux/AMD64. Se estiver executando em Docker em ARM64, especifique o tipo de plataforma AMD64 incluindo o argumento --platform:

docker run -d --name litmus-mcp-server --platform linux/amd64 -p 8000:8000 ghcr.io/litmusautomation/litmus-mcp-server:main

Implantação HTTPS

Existem duas formas suportadas de servir HTTPS: um proxy reverso com terminação TLS e certificados automáticos (recomendado quando o servidor tem um hostname público), ou TLS nativo com seus próprios arquivos de certificado (para redes privadas com uma CA corporativa).

Proxy reverso com certificados automáticos

O contêiner serve HTTP simples por padrão e pode ficar atrás de um proxy reverso com terminação TLS. deploy/docker-compose.https.yml traz esse padrão usando Caddy, que obtém e renova certificados Let's Encrypt automaticamente:

# DNS A/AAAA record for mcp.example.com must point at this machine
DOMAIN=mcp.example.com docker compose -f deploy/docker-compose.https.yml up -d

Os clientes MCP então se conectam a https://mcp.example.com/mcp (sem porta) com os mesmos cabeçalhos de antes. Notas:

Apenas o Caddy é publicado no host (portas 80/443); o servidor MCP permanece na rede interna do compose, e a interface web (:9000) deliberadamente não é proxyada.
Os certificados persistem no volume caddy_data entre reinicializações.
Para redes privadas sem DNS público, descomente tls internal em deploy/Caddyfile para usar a CA interna do Caddy (os clientes devem confiar nessa CA).
Qualquer outro proxy com terminação TLS (Traefik, nginx, um balanceador de carga em nuvem) funciona da mesma forma: encaminhe para a porta 8000 e mantenha as respostas SSE sem buffer.

TLS nativo (traga seu próprio certificado)

Quando o servidor roda em uma rede privada sem DNS público (então o Let's Encrypt não pode emitir um certificado), o servidor pode terminar o TLS por conta própria usando um certificado e chave que você fornece, por exemplo, um emitido pela sua CA corporativa:

services:
  litmus-mcp-server:
    image: ghcr.io/litmusautomation/litmus-mcp-server:latest
    ports:
      - "8000:8000"
    volumes:
      - /opt/litmus-mcp/certs:/certs:ro
    environment:
      SSL_CERTFILE: /certs/server.crt
      SSL_KEYFILE: /certs/server.key

Os clientes MCP então se conectam a https://<hostname>:8000/mcp. Notas:

SSL_CERTFILE e SSL_KEYFILE são variáveis de ambiente simples (como ENABLE_STDIO), não configurações de .env. Definir apenas uma delas, ou apontar para um arquivo ausente, aborta a inicialização com um erro em vez de servir HTTP simples silenciosamente.
SSL_KEYFILE_PASSWORD está disponível para chaves privadas criptografadas.
O certificado deve ser emitido para o hostname que os clientes usam, e os clientes devem confiar na sua CA. Certificados autoassinados são rejeitados pelo claude.ai e pelo Claude Desktop, então use uma CA em que suas máquinas já confiem.
Diferente do padrão Caddy, a renovação é manual: substitua os arquivos e reinicie o contêiner antes que o certificado expire.

Interface Web

A imagem Docker inclui uma interface de chat integrada que permite interagir com o Litmus Edge usando linguagem natural — sem necessidade de configuração de cliente MCP.

Inicie o servidor com ambas as portas expostas:

docker run -d --name litmus-mcp-server \
  -p 8000:8000 -p 9000:9000 \
  -e ANTHROPIC_API_KEY=<key> \
  ghcr.io/litmusautomation/litmus-mcp-server:latest

:9000 — Interface Web (interface de chat). Abra http://localhost:9000 no seu navegador, adicione uma instância do Litmus Edge pela página de configuração e comece a conversar.
:8000 — Endpoint SSE para clientes MCP externos (Claude Desktop, Cursor, VS Code, etc.) — ainda disponível normalmente.

Nota de segurança: a Interface Web é um console de operação local. Ela não tem login e armazena chaves de API de LLMs e credenciais do Litmus Edge, então publique apenas a porta 9000 em redes confiáveis; a porta 8000 (/mcp) é o único endpoint destinado a clientes MCP. Fora do Docker, a interface vincula-se a 127.0.0.1 a menos que você defina WEB_UI_HOST=0.0.0.0 (a imagem Docker define isso para que o mapeamento -p 9000:9000 funcione; basta omitir o mapeamento para manter a interface privada). Acesso de navegadores de outras origens à interface é desabilitado a menos que WEB_UI_CORS_ORIGINS seja definido com uma lista separada por vírgulas de origens explícitas.

Provedores de LLM suportados: Anthropic Claude, OpenAI e Google Gemini. Forneça uma ou mais chaves na inicialização (ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY) ou insira-as pela tela de configuração da Interface Web. O provedor e o modelo ativos podem ser alternados pela página de configuração da Interface Web a qualquer momento.

Múltiplas instâncias do Litmus Edge: A Interface Web permite registrar e alternar entre vários dispositivos Litmus Edge a partir de um único servidor MCP. Cada instância mantém sua própria URL e credenciais OAuth2; as credenciais da instância ativa são espelhadas automaticamente em EDGE_URL / EDGE_API_CLIENT_ID / EDGE_API_CLIENT_SECRET. Gerencie as instâncias em Config → Litmus Edge Instances, ou verifique o status por instância na página Health.

Documentação ao vivo do Litmus como Recursos MCP: O servidor expõe URIs litmus://docs/<section> que buscam conteúdo ao vivo de docs.litmus.io sob demanda, para que clientes cientes de MCP possam puxar material de referência atual diretamente para o contexto do modelo. As páginas são buscadas como markdown (alguns KB cada) em vez de HTML renderizado (algumas centenas de KB, principalmente navegação), com fallback para HTML apenas onde nenhuma versão markdown é publicada. litmus://docs/api resolve para o roteador de agentes do portal de API em api.litmus.io/agents.md, e os roteadores por produto aos quais ele vincula são expostos diretamente como litmus://docs/api/edge, litmus://docs/api/edgemanager e litmus://docs/api/unify, junto com litmus://docs/cli para o guia do litmus-cli e litmus://docs/workflows para receitas de tarefas em várias etapas. litmus://docs/api/index indexa tudo o que o portal de API publica, incluindo páginas por componente não servidas como recursos aqui, e litmus://docs/reference/message-format documenta a forma JSON que as ferramentas de tópicos NATS retornam.

Se você implantar o servidor MCP e o cliente web em hosts separados, defina MCP_SSE_URL para apontar o cliente web para o servidor:

-e MCP_SSE_URL=http://<mcp-server-host>:8000/sse

Configuração Persistente

Por padrão, a configuração salva pela Interface Web (chaves de API, instâncias do Litmus Edge, preferências de modelo, configurações de conexão) é gravada em .env dentro do contêiner e é perdida quando o contêiner é removido.

Para reter a configuração entre reinicializações e substituições do contêiner, monte um arquivo do host sobre /app/.env:

# One-time setup — the host file must exist before docker run
mkdir -p /opt/litmus-mcp
touch /opt/litmus-mcp/.env

# Run with the volume mount
docker run -d --name litmus-mcp-server \
  -p 8000:8000 -p 9000:9000 \
  -v /opt/litmus-mcp/.env:/app/.env \
  ghcr.io/litmusautomation/litmus-mcp-server:latest

Qualquer configuração que você salvar na interface é gravada em /opt/litmus-mcp/.env no host. Um novo contêiner iniciado com o mesmo sinalizador -v a detectará automaticamente na inicialização.

Nota: O arquivo do lado do host deve ser criado com touch antes de executar o contêiner. Se ele não existir, o Docker cria um diretório nesse caminho e o aplicativo falhará ao gravar a configuração.

Equivalente em Docker Compose:

services:
  litmus-mcp-server:
    image: ghcr.io/litmusautomation/litmus-mcp-server:latest
    ports:
      - "8000:8000"
      - "9000:9000"
    volumes:
      - /opt/litmus-mcp/.env:/app/.env

Nota: NATS_SOURCE, NATS_PORT, INFLUX_HOST e INFLUX_PORT são opcionais em todas as configurações de cliente abaixo. Quando omitidos, o servidor deriva os hosts de EDGE_URL (padronizando para nats://<edge-host>:4222 e http://<edge-host>:8086) e menciona o fallback nas respostas das ferramentas. Defina-os apenas quando o plano de dados estiver acessível em um endereço ou porta diferente da interface web do Edge.

Claude Code CLI

Execute o Claude a partir de um diretório que inclua um arquivo de configuração em ~/.claude/mcp.json:

{
  "mcpServers": {
    "litmus-mcp-server": {
      "type": "http",
      "url": "http://localhost:8000/mcp",
      "headers": {
        "EDGE_URL": "${EDGE_URL}",
        "EDGE_API_CLIENT_ID": "${EDGE_API_CLIENT_ID}",
        "EDGE_API_CLIENT_SECRET": "${EDGE_API_CLIENT_SECRET}",
        "NATS_SOURCE": "${NATS_SOURCE}",
        "NATS_PORT": "${NATS_PORT:-4222}",
        "NATS_PASSWORD": "${NATS_PASSWORD}",
        "INFLUX_HOST": "${INFLUX_HOST}",
        "INFLUX_PORT": "${INFLUX_PORT:-8086}",
        "INFLUX_DB_NAME": "${INFLUX_DB_NAME:-tsdata}",
        "INFLUX_USERNAME": "${INFLUX_USERNAME}",
        "INFLUX_PASSWORD": "${INFLUX_PASSWORD}"
      }
    }
  }
}

Documentação Anthropic

Cursor IDE

Adicione a ~/.cursor/mcp.json ou .cursor/mcp.json:

{
  "mcpServers": {
    "litmus-mcp-server": {
      "url": "http://<MCP_SERVER_IP>:8000/sse",
      "headers": {
        "EDGE_URL": "https://<LITMUSEDGE_IP>",
        "EDGE_API_CLIENT_ID": "<oauth2_client_id>",
        "EDGE_API_CLIENT_SECRET": "<oauth2_client_secret>",
        "NATS_SOURCE": "<LITMUSEDGE_IP>",
        "NATS_PORT": "4222",
        "NATS_PASSWORD": "<access_token_from_litmusedge>",
        "INFLUX_HOST": "<LITMUSEDGE_IP>",
        "INFLUX_PORT": "8086",
        "INFLUX_DB_NAME": "tsdata",
        "INFLUX_USERNAME": "<datahub_username>",
        "INFLUX_PASSWORD": "<datahub_password>"
      }
    }
  }
}

Documentação Cursor

VS Code / GitHub Copilot

Configuração Manual

No VS Code: Abra Configurações do Usuário (JSON) → Adicione:

{
  "mcpServers": {
    "litmus-mcp-server": {
      "url": "http://<MCP_SERVER_IP>:8000/sse",
      "headers": {
        "EDGE_URL": "https://<LITMUSEDGE_IP>",
        "EDGE_API_CLIENT_ID": "<oauth2_client_id>",
        "EDGE_API_CLIENT_SECRET": "<oauth2_client_secret>",
        "NATS_SOURCE": "<LITMUSEDGE_IP>",
        "NATS_PORT": "4222",
        "NATS_PASSWORD": "<access_token_from_litmusedge>",
        "INFLUX_HOST": "<LITMUSEDGE_IP>",
        "INFLUX_PORT": "8086",
        "INFLUX_DB_NAME": "tsdata",
        "INFLUX_USERNAME": "<datahub_username>",
        "INFLUX_PASSWORD": "<datahub_password>"
      }
    }
  }
}

Ou use .vscode/mcp.json no seu projeto.

Documentação MCP do VS Code

Windsurf

Adicione a ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "litmus-mcp-server": {
      "url": "http://<MCP_SERVER_IP>:8000/sse",
      "headers": {
        "EDGE_URL": "https://<LITMUSEDGE_IP>",
        "EDGE_API_CLIENT_ID": "<oauth2_client_id>",
        "EDGE_API_CLIENT_SECRET": "<oauth2_client_secret>",
        "NATS_SOURCE": "<LITMUSEDGE_IP>",
        "NATS_PORT": "4222",
        "NATS_PASSWORD": "<access_token_from_litmusedge>",
        "INFLUX_HOST": "<LITMUSEDGE_IP>",
        "INFLUX_PORT": "8086",
        "INFLUX_DB_NAME": "tsdata",
        "INFLUX_USERNAME": "<datahub_username>",
        "INFLUX_PASSWORD": "<datahub_password>"
      }
    }
  }
}

Documentação MCP do Windsurf

STDIO com Claude Desktop

Este servidor MCP suporta conexões locais com o Claude Desktop e outros aplicativos via Entrada/Saída Padrão de Arquivo (STDIO): https://modelcontextprotocol.io/legacy/concepts/transports

Para usar STDIO: Clone, instale as dependências e adicione o servidor ao arquivo de configuração do Claude Desktop com ENABLE_STDIO definido como true. O Claude Desktop inicia o processo do servidor por conta própria; sem ENABLE_STDIO o servidor inicia em modo HTTP, nunca responde em stdin/stdout, e o Claude Desktop desconecta após seu tempo limite de inicialização de 60 segundos.

Clonar e instalar dependências

git clone https://github.com/litmusautomation/litmus-mcp-server.git
cd litmus-mcp-server

# Using uv
uv sync

# Otherwise
pip install -e .

Adicione a definição json do servidor ao seu arquivo de configuração do Claude Desktop:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "litmus-mcp-server": {
      "command": "/path/to/.venv/bin/python3",
      "args": [
        "/absolute/path/to/litmus-mcp-server/src/server.py"
      ],
      "env": {
        "ENABLE_STDIO": "true",
        "PYTHONPATH": "/absolute/path/to/litmus-mcp-server/src",
        "EDGE_URL": "https://<LITMUSEDGE_IP>",
        "EDGE_API_CLIENT_ID": "<oauth2_client_id>",
        "EDGE_API_CLIENT_SECRET": "<oauth2_client_secret>",
        "NATS_SOURCE": "<LITMUSEDGE_IP>",
        "NATS_PORT": "4222",
        "NATS_PASSWORD": "<access_token_from_litmusedge>",
        "INFLUX_HOST": "<LITMUSEDGE_IP>",
        "INFLUX_PORT": "8086",
        "INFLUX_DB_NAME": "tsdata",
        "INFLUX_USERNAME": "<datahub_username>",
        "INFLUX_PASSWORD": "<datahub_password>"
      }
    }
  }
}

Dicas

Para desenvolvimento, use Ambientes virtuais Python, por exemplo, para fazer a ponte entre diferenças de versão da lib mcp entre clientes de desenvolvimento como 'npx @modelcontextprotocol/inspector' e o litmus-mcp-server

{
  "mcpServers": {
    "litmus-mcp-server": {
      "command": "/absolute/path/to/litmus-mcp-server/.venv/bin/python",
      "args": ["/absolute/path/to/litmus-mcp-server/src/server.py"],
      "env": { /* same as above */ }
    }
  }
}

Veja claude_desktop_config_venv.example.json para o modelo completo.

Guia de Configuração de Cabeçalhos:

EDGE_URL: URL base do Litmus Edge (inclua https://)
EDGE_API_CLIENT_ID / EDGE_API_CLIENT_SECRET: credenciais OAuth2 do Litmus Edge
NATS_SOURCE: IP do Litmus Edge (sem http/https); opcional, derivado de EDGE_URL quando omitido
NATS_PASSWORD: token de acesso de System → Access Control → Tokens (nenhum nome de usuário necessário)
INFLUX_HOST: IP do Litmus Edge (sem http/https)
INFLUX_USERNAME / INFLUX_PASSWORD: credenciais de usuário do DataHub
VALIDATE_CERTIFICATE: verificar o certificado TLS do Litmus Edge (padrão true; veja abaixo)

Verificação de certificado TLS

VALIDATE_CERTIFICATE padroniza para true, então conexões com o Litmus Edge e o Litmus Edge Manager verificam o certificado a menos que você opte por sair. Isso se aplica aos modos HTTP e STDIO igualmente, às ferramentas baseadas em litmus-cli e à Interface Web, que lê a mesma configuração de .env e a mostra como o alternador Validate TLS Certificates na sua página de configuração.

Certificados autoassinados são comuns em hardware de borda, então um certificado rejeitado não quebra a chamada. O servidor executa a ferramenta novamente com a verificação desativada e retorna esse resultado. O rebaixamento nunca é silencioso. A resposta carrega um tls_warning nomeando o host, para que o operador lendo a saída e o modelo agindo sobre ela ambos saibam que os dados cruzaram um canal não verificado:

{
  "success": true,
  "devices": [],
  "tls_warning": "TLS certificate verification FAILED for https://192.168.1.50 and the call was retried without verification, so this data crossed an unverified channel and could have been intercepted. Treat it as untrusted until the certificate is fixed. ..."
}

Notas:

A nova tentativa ocorre na chamada da ferramenta, não na configuração da conexão, porque os auxiliares de conexão do SDK apenas constroem um objeto de configuração: nada chega à rede até que a ferramenta emita sua primeira solicitação, que é o momento mais cedo em que um certificado inválido pode aparecer.
Somente uma rejeição de certificado aciona a nova tentativa. Uma senha incorreta, uma conexão recusada ou um tempo limite falha como sempre falhou, portanto as credenciais nunca são repetidas em um canal não verificado devido a um erro não relacionado. Um certificado rejeitado aborta o handshake antes que qualquer solicitação seja entregue, então reexecutar a ferramenta não pode repetir trabalho que o host já aplicou.
Definir VALIDATE_CERTIFICATE=false é uma decisão explícita de pular a verificação. Isso é honrado sem qualquer nova tentativa e não relata aviso, que é a maneira de silenciar o aviso para uma borda que você conscientemente executa com um certificado autoassinado.
Um valor não reconhecido (um erro de digitação como flase) verifica em vez de ser lido como consentimento para pular a verificação.
A nova tentativa não é armazenada em cache, então uma borda cujo certificado é corrigido posteriormente volta a verificar na próxima chamada. Enquanto permanecer autoassinado, cada chamada paga primeiro um handshake rejeitado.
Os testes de conexão e verificações de saúde da interface web seguem a mesma política: eles tentam novamente sem verificação em um certificado rejeitado e retornam o mesmo tls_warning junto com o resultado.
A correção limpa é instalar um certificado em que seus clientes confiem. Veja Implantação HTTPS para o TLS próprio do servidor MCP, que é uma configuração separada desta.

Ferramentas Disponíveis

62 ferramentas em 13 categorias. As ferramentas aceitam argumentos estruturados e retornam JSON.

Categoria	Nome da Função	Descrição
DeviceHub, Dispositivos	`get_litmusedge_driver_list`	Listar drivers suportados do Litmus Edge (ex.: ModbusTCP, OPCUA, BACnet).
	`get_devicehub_devices`	Listar todos os dispositivos DeviceHub configurados com configurações de conexão e status.
	`create_devicehub_device`	Criar um novo dispositivo com driver especificado e configuração padrão.
	`get_device_connection_status` **	Verificar se os dispositivos estão publicando dados ativamente via heartbeat InfluxDB (conectado/desatualizado/sem_dados).
DeviceHub, Tags	`get_devicehub_device_tags`	Recuperar tags (pontos de dados/registradores) para um dispositivo específico ou todos os dispositivos, paginado via `limit`/`offset` para que qualquer contagem de tags possa ser paginada.
	`get_current_value_of_devicehub_tag`	Ler o valor em tempo real atual de uma tag específica do dispositivo.
	`create_devicehub_tag`	Criar uma nova tag (registrador) em um dispositivo. Propriedades exigidas pelo driver são preenchidas automaticamente a partir dos padrões.
	`update_devicehub_tag`	Atualizar campos mutáveis de uma tag existente (nome de exibição, descrição, propriedades).
	`delete_devicehub_tag`	Excluir uma tag de um dispositivo. Destrutivo.
	`get_tag_status`	Retornar estado de tempo de execução (OK/Falhou/Desconhecido) para tags em um dispositivo específico. Opcionalmente, filtrar para uma única tag.
	`get_all_tags_status`	Retornar status de tags em todos os dispositivos. Padrão é apenas não-OK para que problemas apareçam primeiro.
Identidade do Dispositivo	`get_litmusedge_friendly_name`	Obter o nome legível atribuído ao dispositivo Litmus Edge.
	`set_litmusedge_friendly_name`	Atualizar o nome amigável do dispositivo Litmus Edge.
Nuvem / Ativação LEM	`get_cloud_activation_status`	Verificar registro na nuvem e status de conexão com o Litmus Edge Manager (LEM).
Gerenciamento Docker	`get_all_containers_on_litmusedge`	Listar todos os contêineres Docker em execução no Litmus Edge Marketplace.
	`run_docker_container_on_litmusedge`	Implantar e executar um novo contêiner Docker no Litmus Edge Marketplace.
Tópicos NATS *	`list_nats_topics`	Descobrir quais tópicos existem, mesclados de analytics, tags DeviceHub e instâncias de gêmeos digitais.
	`get_current_value_from_topic`	Assinar um tópico NATS e retornar a próxima mensagem publicada.
	`get_multiple_values_from_topic`	Coletar múltiplos valores sequenciais de um tópico NATS para análise de tendências.
InfluxDB / Séries Temporais **	`get_historical_data_from_influxdb`	Consultar dados históricos de séries temporais do InfluxDB por medição e intervalo de tempo.
	`list_influxdb_measurements`	Listar todos os nomes de medições no banco de dados `tsdata`, descoberta para consultas posteriores.
	`get_device_historical_data`	Correspondência difusa de nomes de dispositivos para medições InfluxDB e puxar dados históricos por correspondência.
	`query_tag_data`	Consultar dados históricos para uma tag específica resolvendo seu tópico de saída. Mais recentes primeiro.
	`get_tag_statistics`	Estatísticas agregadas para uma tag: média, mín, máx, desvio padrão, contagem, além de intervalo de linha de base (média +/- 2 sigma).
	`get_device_data_for_inference`	Payload composto para inferência de IA: metadados do dispositivo, todas as tags, estatísticas por tag e amostras recentes.
Sistema, Eventos	`get_system_events`	Recuperar eventos do sistema filtrados por intervalo de tempo, componente e gravidade (INFO/WARN/ALERT/ERROR).
	`get_system_event_stats`	Instantâneo de saúde do sistema e eventos: tamanho do armazenamento de eventos, contagens de eventos da última hora por gravidade, uso de memória/armazenamento, contagem de CPU.
Servidor	`get_mcp_server_info`	Informações de versão sobre o próprio servidor MCP (servidor, litmussdk, litmus-cli, Python). Opcional `check_updates` compara com os lançamentos mais recentes do GitHub; `upgrade_cli` baixa e ativa o litmus-cli mais recente. Não precisa de conexão com a borda.
Sistema, Rede	`get_firewall_rules`	Retornar regras de firewall configuradas: portas, protocolos, ações ALLOW/DENY.
	`get_network_interface_info`	Detalhes da interface de rede: IP, MAC, gateway, status do link, MTU, velocidade. Padrão é `eth0`.
	`get_packet_capture_interfaces`	Listar interfaces de rede disponíveis para captura de pacotes.
	`get_packet_capture_status`	Estado atual da captura de pacotes e lista de arquivos `.pcap` capturados com metadados.
	`start_packet_capture`	Iniciar uma captura de pacotes em uma interface. Duração de 1 a 30 minutos.
	`stop_packet_capture`	Parar uma captura de pacotes em andamento.
Gêmeos Digitais	`list_digital_twin_models`	Listar todos os modelos de Gêmeos Digitais com ID, nome, descrição e versão.
	`create_digital_twin_model`	Criar um novo modelo de Gêmeo Digital.
	`list_digital_twin_instances`	Listar todas as instâncias de Gêmeos Digitais ou filtrar por ID do modelo.
	`create_digital_twin_instance`	Criar uma nova instância de Gêmeo Digital a partir de um modelo existente.
	`list_static_attributes`	Listar atributos estáticos (pares chave-valor fixos) para um modelo, uma instância (por id ou nome), ou todas as instâncias de uma vez (`all_instances`).
	`list_dynamic_attributes`	Listar atributos dinâmicos (pontos de dados em tempo real) para um modelo, uma instância (por id ou nome), ou todas as instâncias de uma vez (`all_instances`).
	`list_transformations`	Listar regras de transformação de dados configuradas para um modelo de Gêmeo Digital.
	`get_digital_twin_hierarchy`	Obter a configuração de hierarquia para um modelo de Gêmeo Digital.
	`save_digital_twin_hierarchy`	Salvar uma nova configuração de hierarquia para um modelo de Gêmeo Digital.
Litmus Edge Manager (LEM) ***	`lem_list_devices`	Listar dispositivos de borda registrados em um projeto LEM (paginado).
	`lem_get_device_details`	Registro completo do lado LEM para um único dispositivo de borda (versões, licença, última vez visto, configuração).
	`lem_list_device_versions`	Listar versões do Litmus Edge registradas em um projeto LEM.
	`lem_list_device_groups`	Listar rótulos de grupos de dispositivos (agrupamentos em nível de projeto) definidos em um projeto LEM.
	`lem_get_license_expiry`	Listar dispositivos cuja licença expira nos próximos N dias.
	`lem_get_expired_licenses`	Listar dispositivos em um projeto LEM cuja licença já expirou.
	`lem_dashboard_usage`	Resumo de uso do projeto (contagens de dispositivos, uso de licença, estatísticas de implantação).
	`lem_get_project_alerts`	Listar alertas ativos em nível de projeto (dispositivo offline, problemas de licença, etc.).
	`lem_list_companies`	Listar todas as empresas no tenant LEM com contagens de projetos/dispositivos/modelos.
	`lem_get_company_details`	Detalhes completos para uma única empresa por nome (equipes, licença, cotas).
	`lem_list_company_projects`	Listar todos os projetos pertencentes a uma determinada empresa.
	`lem_get_project_details`	Detalhes de um único projeto (fuso horário, TTL de dados, slots alocados, plano de cobrança).
	`lem_deployment_info`	Informações de implantação do tenant LEM (versão, build, metadados de lançamento).
	`lem_get_system_time`	Relógio do servidor LEM; útil ao comparar carimbos de data/hora da borda.
LEM Bridge ***	`lem_bridge_list_devicehub_devices`	Listar dispositivos devicehub em uma borda específica por tunelamento através do LEM (sem troca de instância ativa).
	`lem_bridge_get_le_info`	Informações de identidade (nome amigável, ativação na nuvem) para uma borda via bridge LEM.
Fallback SDK (CLI) ****	`litmus_sdk_discover`	Navegar pelo catálogo completo do SDK gerado (~550 funções) por prefixo de caminho pontilhado.
	`litmus_sdk_read`	Invocar uma função SDK somente leitura (Get/List/Browse/...) por caminho pontilhado.
	`litmus_sdk_write`	Invocar uma função SDK que altera estado por caminho pontilhado. Sujeito a aprovação; potencialmente destrutivo.

Notas de Uso das Ferramentas

* Requisitos das Ferramentas de Tópicos NATS: Para usar get_current_value_from_topic e get_multiple_values_from_topic, você deve configurar o controle de acesso no Litmus Edge (list_nats_topics não precisa de acesso ao broker, pois lê nomes de tópicos das APIs REST/GraphQL em vez de assinar):

Navegue até: Litmus Edge → System → Access Control → Tokens
Crie ou configure um token de acesso com permissões apropriadas
Forneça o token nos cabeçalhos de configuração do seu cliente MCP

** Requisitos das Ferramentas InfluxDB / Séries Temporais: Para usar qualquer ferramenta marcada com ** (get_historical_data_from_influxdb, list_influxdb_measurements, get_device_historical_data, query_tag_data, get_tag_statistics, get_device_data_for_inference, get_device_connection_status), você deve permitir acesso à porta InfluxDB:

Navegue até: Litmus Edge -> System -> Network -> Firewall
Adicione uma regra de firewall para permitir a porta 8086 em TCP
Garanta que o InfluxDB esteja acessível a partir do host do servidor MCP
Forneça INFLUX_HOST, INFLUX_PORT, INFLUX_DB_NAME, INFLUX_USERNAME, INFLUX_PASSWORD nos cabeçalhos do seu cliente MCP *** Requisitos das Ferramentas LEM: As ferramentas LEM se comunicam com um tenant do Litmus Edge Manager (nuvem) em vez de um único edge. Para usar qualquer ferramenta marcada com ***, forneça estes cabeçalhos na configuração do seu cliente MCP:

EDGE_MANAGER_URL: URL base do Litmus Edge Manager (inclua https://)
EDGE_API_TOKEN: token de API emitido pelo LEM
EDGE_MANAGER_PROJECT_ID (opcional): ID de projeto padrão, usado quando o argumento project_id de uma ferramenta é omitido
EDGE_MANAGER_ADMIN_URL (opcional): URL de administração, padrão para o host EDGE_MANAGER_URL na porta 8446

**** Requisitos das Ferramentas de Fallback do SDK: litmus_sdk_discover, litmus_sdk_read e litmus_sdk_write são suportados pelo binário Go autônomo litmus-cli, assim como as ferramentas selecionadas de atributos de gêmeo digital e status de tags. A imagem Docker o instala no momento da construção, e run.sh o instala ou atualiza automaticamente para execuções locais (verificado por checksum em .venv/bin, fixado na mesma versão da imagem Docker via ARG LITMUS_CLI_VERSION do Dockerfile). Se o servidor for iniciado sem ele (por exemplo, um python src/server.py simples), ele se autoinstala na versão fixada no primeiro uso: baixado dos lançamentos oficiais, verificado por SHA256 e armazenado em cache em ~/.cache/litmus-mcp-server. Hosts isolados (air-gapped) sem acesso ao GitHub devem pré-instalar o binário. Para usar um binário diferente, defina LITMUS_CLI_PATH (ignora toda a inicialização) ou instale um dos lançamentos cli-v* em https://github.com/litmusautomation/litmus-sdk-releases/releases e coloque-o no PATH. Eles expõem toda a superfície gerada do SDK além das ferramentas selecionadas acima. Notas:

Os cabeçalhos de conexão são encaminhados para a CLI por chamada; nenhum perfil de CLI é lido ou gravado.
litmus_sdk_read aceita apenas funções somente leitura (segmento final começando com Get, List, Browse, Describe, Read, Search, Find, Query ou Count); todo o resto passa por litmus_sdk_write.
litmus_sdk_write pode invocar funções destrutivas do SDK (create/update/delete/restart). Cada chamada exige aprovação explícita do usuário por meio do argumento user_approved, que o assistente só pode definir após você aprovar a função e os argumentos exatos.
Prefira as ferramentas dedicadas acima quando uma delas cobrir a operação.
As funções unify.* do catálogo têm como alvo o Litmus Unify, que autentica separadamente do Litmus Edge. Envie UNS_URL, UNS_USERNAME e UNS_PASSWORD (mais UNS_VALIDATE_CERTIFICATE: false para um certificado autoassinado) para usá-las. Sem UNS_URL, o namespace fica oculto de litmus_sdk_discover, pois cada chamada falharia sem as credenciais; nenhum outro namespace precisa desses cabeçalhos.
VALIDATE_CERTIFICATE (opcional): verifica certificados TLS na ponte LEM (padrão true; consulte verificação de certificado TLS)

As ferramentas lem_bridge_* adicionalmente fazem túnel através do LEM para um edge específico e exigem tanto project_id quanto device_id (o ID do dispositivo LEM, como com lem_device_id abaixo) como argumentos de chamada. A página Config -> Litmus Edge Manager da interface web gerencia múltiplas conexões LEM e grava esses cabeçalhos automaticamente.

Roteamento da ponte LEM por chamada para ferramentas de edge: Quando EDGE_MANAGER_URL está configurado, toda ferramenta que visa edge (DeviceHub, Digital Twins, sistema, marketplace e as ferramentas de fallback do SDK) também aceita argumentos opcionais project_id e lem_device_id. Passar ambos roteia essa única chamada para o edge gerenciado correspondente através da ponte LEM, de modo que uma configuração somente LEM (URL + token, sem EDGE_URL) ainda possa usar o conjunto completo de ferramentas do Litmus Edge: o assistente descobre IDs com lem_list_devices e então chama as ferramentas de edge diretamente contra qualquer dispositivo na frota. Os cabeçalhos EDGE_MANAGER_PROJECT_ID e EDGE_MANAGER_DEVICE_ID permanecem suportados como padrões estáticos.

lem_device_id é o ID do dispositivo LEM de lem_list_devices, não o ID do dispositivo DeviceHub que get_devicehub_devices retorna; os dois são namespaces diferentes. O argumento era chamado device_id antes, o que colidia com esse ID do DeviceHub, e o nome antigo ainda é aceito para que clientes existentes continuem funcionando.

Ferramentas selecionadas com suporte da CLI: As ferramentas de listagem de atributos/transformações de gêmeo digital e as ferramentas de status de tags são executadas através do binário litmus-cli incluído (mesma camada de conexão das ferramentas de fallback do SDK) em vez do SDK Python, para que dispositivos ou gêmeos com dados incomuns não falhem mais na validação estrita do lado do cliente, e o roteamento da ponte LEM se aplica uniformemente.

Litmus Central

Baixe ou experimente o Litmus Edge via Litmus Central.

Registros de servidores MCP

Glama

MCP.so