Litmus MCP Server

Permite que los LLMs y sistemas inteligentes interactúen con Litmus Edge para la configuración, monitoreo y gestión de dispositivos.

GitHub
12
Prueba este MCPPatrocinado

Documentación

Litmus logo

Documentation Follow on LinkedIn

Litmus MCP Server

El Litmus Automation oficial Servidor de Protocolo de Contexto de Modelo (MCP) permite que los LLM y sistemas inteligentes interactúen con Litmus Edge para la configuración, monitoreo y gestión de dispositivos. Está construido sobre el SDK de MCP y cumple con la especificación del Protocolo de Contexto de Modelo.

Litmus MCP Server Architecture Diagram

Tabla de Contenidos

Inicio Rápido

Iniciar un servidor MCP HTTP usando Docker

Ejecute el servidor en Docker (solo HTTP)

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

El servidor HTTP expone ambos transportes MCP en el puerto 8000:

  • http://<host>:8000/mcp - HTTP Streamable (especificación MCP actual, recomendado)
  • http://<host>:8000/sse - HTTP+SSE (transporte heredado, mantenido para clientes antiguos)

Los clientes que admiten HTTP Streamable deben apuntar a /mcp (por ejemplo, "type": "http", como en el ejemplo de Claude Code a continuación). Los ejemplos de clientes restantes usan el endpoint SSE; cambie a /mcp si su cliente lo admite, manteniendo los mismos encabezados.

NOTA: El Litmus MCP Server está construido para plataformas linux/AMD64. Si se ejecuta en Docker en ARM64, especifique el tipo de plataforma AMD64 incluyendo el argumento --platform:

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

Despliegue HTTPS

Hay dos formas admitidas de servir HTTPS: un proxy inverso con terminación TLS y certificados automáticos (recomendado cuando el servidor tiene un nombre de host público), o TLS nativo con sus propios archivos de certificado (para redes privadas con una CA corporativa).

Proxy inverso con certificados automáticos

El contenedor sirve HTTP plano por defecto y puede estar detrás de un proxy inverso con terminación TLS. deploy/docker-compose.https.yml incluye ese patrón usando Caddy, que obtiene y renueva certificados de Let's Encrypt automáticamente:

# 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

Los clientes MCP se conectan entonces a https://mcp.example.com/mcp (sin puerto) con los mismos encabezados que antes. Notas:

  • Solo Caddy se publica en el host (puertos 80/443); el servidor MCP permanece en la red interna de compose, y la interfaz web (:9000) deliberadamente no se proxya.
  • Los certificados persisten en el volumen caddy_data entre reinicios.
  • Para redes privadas sin DNS público, descomente tls internal en deploy/Caddyfile para usar la CA interna de Caddy en su lugar (los clientes deben confiar en esa CA).
  • Cualquier otro proxy con terminación TLS (Traefik, nginx, un balanceador de carga en la nube) funciona de la misma manera: reenvíe al puerto 8000 y mantenga las respuestas SSE sin almacenar en búfer.

TLS nativo (traiga su propio certificado)

Cuando el servidor se ejecuta en una red privada sin DNS público (por lo que Let's Encrypt no puede emitir un certificado), el servidor puede terminar TLS por sí mismo usando un certificado y una clave que usted proporcione, por ejemplo, uno emitido por su 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

Los clientes MCP se conectan entonces a https://<hostname>:8000/mcp. Notas:

  • SSL_CERTFILE y SSL_KEYFILE son variables de entorno simples (como ENABLE_STDIO), no configuraciones de .env. Establecer solo una de ellas, o apuntar a un archivo faltante, aborta el inicio con un error en lugar de servir HTTP plano silenciosamente.
  • SSL_KEYFILE_PASSWORD está disponible para claves privadas cifradas.
  • El certificado debe emitirse para el nombre de host que usan los clientes, y los clientes deben confiar en su CA. Los certificados autofirmados son rechazados por claude.ai y Claude Desktop, así que use una CA en la que sus máquinas ya confíen.
  • A diferencia del patrón de Caddy, la renovación es manual: reemplace los archivos y reinicie el contenedor antes de que expire el certificado.

Interfaz Web

La imagen de Docker incluye una interfaz de chat integrada que le permite interactuar con Litmus Edge usando lenguaje natural — sin necesidad de configuración de cliente MCP.

Inicie el servidor con ambos puertos expuestos:

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 — Interfaz Web (interfaz de chat). Abra http://localhost:9000 en su navegador, agregue una instancia de Litmus Edge a través de la página de configuración y comience a chatear.
  • :8000 — Endpoint SSE para clientes MCP externos (Claude Desktop, Cursor, VS Code, etc.) — todavía disponible como de costumbre.

Nota de seguridad: la Interfaz Web es una consola de operador local. No tiene inicio de sesión y almacena claves de API de LLM y credenciales de Litmus Edge, así que solo publique el puerto 9000 en redes de confianza; el puerto 8000 (/mcp) es el único endpoint destinado a clientes MCP. Fuera de Docker, la interfaz se vincula a 127.0.0.1 a menos que establezca WEB_UI_HOST=0.0.0.0 (la imagen de Docker establece esto para que funcione el mapeo -p 9000:9000; simplemente omita el mapeo para mantener la interfaz privada). El acceso de navegador de origen cruzado a la interfaz está deshabilitado a menos que WEB_UI_CORS_ORIGINS esté configurado con una lista separada por comas de orígenes explícitos.

Proveedores de LLM admitidos: Anthropic Claude, OpenAI y Google Gemini. Proporcione una o más claves al inicio (ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY) o ingréselas a través de la pantalla de configuración de la Interfaz Web. El proveedor y modelo activos se pueden cambiar desde la página de configuración de la Interfaz Web en cualquier momento.

Múltiples instancias de Litmus Edge: La Interfaz Web le permite registrar y cambiar entre múltiples dispositivos Litmus Edge desde un solo servidor MCP. Cada instancia mantiene su propia URL y credenciales OAuth2; las credenciales de la instancia activa se reflejan automáticamente en EDGE_URL / EDGE_API_CLIENT_ID / EDGE_API_CLIENT_SECRET. Administre instancias bajo Config → Litmus Edge Instances, o verifique el estado por instancia desde la página Health.

Documentación en vivo de Litmus como Recursos MCP: El servidor expone URIs litmus://docs/<section> que obtienen contenido en vivo de docs.litmus.io bajo demanda, para que los clientes compatibles con MCP puedan extraer material de referencia actual directamente al contexto del modelo. Las páginas se obtienen como markdown (unos pocos KB cada una) en lugar de HTML renderizado (unos pocos cientos de KB, principalmente navegación), recurriendo a HTML solo donde no se publica una versión markdown. litmus://docs/api resuelve al enrutador de agentes del portal API en api.litmus.io/agents.md, y los enrutadores por producto a los que enlaza se exponen directamente como litmus://docs/api/edge, litmus://docs/api/edgemanager y litmus://docs/api/unify, junto con litmus://docs/cli para la guía de litmus-cli y litmus://docs/workflows para recetas de tareas de múltiples pasos. litmus://docs/api/index indexa todo lo que publica el portal API, incluidas páginas por componente que no se sirven como recursos aquí, y litmus://docs/reference/message-format documenta la forma JSON que devuelven las herramientas de temas NATS.

Si despliega el servidor MCP y el cliente web en hosts separados, establezca MCP_SSE_URL para apuntar el cliente web al servidor:

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

Configuración Persistente

Por defecto, la configuración guardada a través de la Interfaz Web (claves de API, instancias de Litmus Edge, preferencias de modelo, configuraciones de conexión) se escribe en .env dentro del contenedor y se pierde cuando se elimina el contenedor.

Para conservar la configuración entre reinicios y reemplazos del contenedor, monte un archivo del 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

Cualquier configuración que guarde en la interfaz se escribe en /opt/litmus-mcp/.env en el host. Un nuevo contenedor iniciado con el mismo indicador -v la recogerá automáticamente al inicio.

Nota: El archivo del lado del host debe crearse con touch antes de ejecutar el contenedor. Si no existe, Docker crea un directorio en esa ruta y la aplicación no podrá escribir la configuración.

Equivalente en 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 y INFLUX_PORT son opcionales en todas las configuraciones de cliente a continuación. Cuando se omiten, el servidor deriva los hosts de EDGE_URL (por defecto a nats://<edge-host>:4222 y http://<edge-host>:8086) y menciona el respaldo en las respuestas de las herramientas. Establézcalos solo cuando el plano de datos sea accesible en una dirección o puerto diferente al de la interfaz web de Edge.

CLI de Claude Code

Ejecute Claude desde un directorio que incluya un archivo de configuración en ~/.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}"
      }
    }
  }
}

Documentación de Anthropic

IDE Cursor

Agregue a ~/.cursor/mcp.json o .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>"
      }
    }
  }
}

Documentación de Cursor

VS Code / GitHub Copilot

Configuración Manual

En VS Code: Abra Configuración de Usuario (JSON) → Agregue:

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

O use .vscode/mcp.json en su proyecto.

Documentación MCP de VS Code

Windsurf

Agregue 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>"
      }
    }
  }
}

Documentación MCP de Windsurf

STDIO con Claude Desktop

Este servidor MCP admite conexiones locales con Claude Desktop y otras aplicaciones a través de Entrada/Salida Estándar de archivos (STDIO): https://modelcontextprotocol.io/legacy/concepts/transports

Para usar STDIO: Clone, instale dependencias y agregue el servidor al archivo de configuración de Claude Desktop con ENABLE_STDIO establecido en true. Claude Desktop inicia el proceso del servidor por sí mismo; sin ENABLE_STDIO el servidor se inicia en modo HTTP, nunca responde en stdin/stdout, y Claude Desktop se desconecta después de su tiempo de espera de inicialización de 60 segundos.

Clonar e instalar dependencias

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

# Using uv
uv sync

# Otherwise
pip install -e .

Agregar la definición json del servidor a su archivo de configuración de 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>"
      }
    }
  }
}

Consejos

Para desarrollo, use Entornos virtuales de Python, por ejemplo para puentear diferencias de versiones de la biblioteca mcp entre clientes de desarrollo como 'npx @modelcontextprotocol/inspector' y 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 */ }
    }
  }
}

Consulte claude_desktop_config_venv.example.json para la plantilla completa.

Guía de Configuración de Encabezados:

  • EDGE_URL: URL base de Litmus Edge (incluya https://)
  • EDGE_API_CLIENT_ID / EDGE_API_CLIENT_SECRET: Credenciales OAuth2 de Litmus Edge
  • NATS_SOURCE: IP de Litmus Edge (sin http/https); opcional, derivada de EDGE_URL cuando se omite
  • NATS_PASSWORD: Token de acceso de System → Access Control → Tokens (no se necesita nombre de usuario)
  • INFLUX_HOST: IP de Litmus Edge (sin http/https)
  • INFLUX_USERNAME / INFLUX_PASSWORD: Credenciales de usuario de DataHub
  • VALIDATE_CERTIFICATE: verifique el certificado TLS de Litmus Edge (por defecto true; consulte a continuación)

Verificación de certificado TLS

VALIDATE_CERTIFICATE por defecto es true, por lo que las conexiones a Litmus Edge y Litmus Edge Manager verifican el certificado a menos que opte por no hacerlo. Esto se aplica a los modos HTTP y STDIO por igual, a las herramientas respaldadas por litmus-cli, y a la Interfaz Web, que lee la misma configuración de .env y la muestra como el interruptor Validate TLS Certificates en su página de configuración.

Los certificados autofirmados son comunes en hardware de borde, por lo que un certificado rechazado no rompe la llamada. El servidor ejecuta la herramienta nuevamente con la verificación desactivada y devuelve ese resultado. La degradación nunca es silenciosa. La respuesta lleva un tls_warning que nombra el host, para que el operador que lee la salida y el modelo que actúa sobre ella sepan que los datos cruzaron un canal no 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:

  • El reintento ocurre en la llamada a la herramienta, no en la configuración de la conexión, porque los ayudantes de conexión del SDK solo construyen un objeto de configuración: nada llega a la red hasta que la herramienta emite su primera solicitud, que es el momento más temprano en que un certificado defectuoso puede aparecer.
  • Solo un rechazo de certificado activa el reintento. Una contraseña incorrecta, una conexión rechazada o un tiempo de espera agotado fallan como siempre lo hicieron, por lo que las credenciales nunca se reenvían a través de un canal no verificado debido a un error no relacionado. Un certificado rechazado aborta el protocolo de enlace antes de que se entregue cualquier solicitud, por lo que volver a ejecutar la herramienta no puede repetir trabajo que el host ya aplicó.
  • Establecer VALIDATE_CERTIFICATE=false es una decisión explícita de omitir la verificación. Se respeta sin ningún reintento y no informa ninguna advertencia, que es la forma de silenciar la advertencia para un borde que usted sabe que ejecuta con un certificado autofirmado.
  • Un valor no reconocido (un error tipográfico como flase) verifica en lugar de leerse como consentimiento para omitir la verificación.
  • El reintento no se almacena en caché, por lo que un borde cuyo certificado se corrige más tarde vuelve a verificar en la siguiente llamada. Mientras permanezca autofirmado, cada llamada paga primero un protocolo de enlace rechazado.
  • Las pruebas de conexión y las comprobaciones de salud de la interfaz web siguen la misma política: reintentan sin verificar ante un certificado rechazado y devuelven el mismo tls_warning junto con el resultado.
  • La solución limpia es instalar un certificado en el que sus clientes confíen. Consulte Implementación HTTPS para el TLS propio del servidor MCP, que es una configuración separada de esta.

Herramientas Disponibles

62 herramientas en 13 categorías. Las herramientas aceptan argumentos estructurados y devuelven JSON.

CategoríaNombre de FunciónDescripción
DeviceHub, Dispositivosget_litmusedge_driver_listListar controladores compatibles de Litmus Edge (por ejemplo, ModbusTCP, OPCUA, BACnet).
get_devicehub_devicesListar todos los dispositivos DeviceHub configurados con ajustes de conexión y estado.
create_devicehub_deviceCrear un nuevo dispositivo con el controlador especificado y la configuración predeterminada.
get_device_connection_status **Comprobar si los dispositivos están publicando datos activamente mediante el latido de InfluxDB (conectado/desactualizado/sin_datos).
DeviceHub, Etiquetasget_devicehub_device_tagsRecuperar etiquetas (puntos de datos/registros) para un dispositivo específico o todos los dispositivos, paginado mediante limit/offset para que cualquier cantidad de etiquetas pueda paginarse.
get_current_value_of_devicehub_tagLeer el valor en tiempo real actual de una etiqueta de dispositivo específica.
create_devicehub_tagCrear una nueva etiqueta (registro) en un dispositivo. Las propiedades requeridas por el controlador se autocompletan desde los valores predeterminados.
update_devicehub_tagActualizar campos mutables de una etiqueta existente (nombre para mostrar, descripción, propiedades).
delete_devicehub_tagEliminar una etiqueta de un dispositivo. Destructivo.
get_tag_statusDevolver el estado de ejecución (OK/Error/Desconocido) para etiquetas en un dispositivo específico. Opcionalmente, filtrar a una sola etiqueta.
get_all_tags_statusDevolver el estado de etiquetas en todos los dispositivos. Por defecto, solo las que no son OK para que los problemas aparezcan primero.
Identidad del Dispositivoget_litmusedge_friendly_nameObtener el nombre legible asignado al dispositivo Litmus Edge.
set_litmusedge_friendly_nameActualizar el nombre descriptivo del dispositivo Litmus Edge.
Nube / Activación LEMget_cloud_activation_statusComprobar el registro en la nube y el estado de conexión con Litmus Edge Manager (LEM).
Gestión de Dockerget_all_containers_on_litmusedgeListar todos los contenedores Docker que se ejecutan en Litmus Edge Marketplace.
run_docker_container_on_litmusedgeImplementar y ejecutar un nuevo contenedor Docker en Litmus Edge Marketplace.
Temas NATS *list_nats_topicsDescubrir qué temas existen, combinados desde análisis, etiquetas DeviceHub e instancias de gemelos digitales.
get_current_value_from_topicSuscribirse a un tema NATS y devolver el siguiente mensaje publicado.
get_multiple_values_from_topicRecopilar múltiples valores secuenciales de un tema NATS para análisis de tendencias.
InfluxDB / Series Temporales **get_historical_data_from_influxdbConsultar datos históricos de series temporales desde InfluxDB por medición y rango de tiempo.
list_influxdb_measurementsListar todos los nombres de mediciones en la base de datos tsdata, descubrimiento para consultas posteriores.
get_device_historical_dataCoincidencia difusa de nombres de dispositivos con mediciones de InfluxDB y extracción de datos históricos por coincidencia.
query_tag_dataConsultar datos históricos para una etiqueta específica resolviendo su tema de salida. Más recientes primero.
get_tag_statisticsEstadísticas agregadas para una etiqueta: media, mínimo, máximo, desviación estándar, recuento, más rango de referencia (media +/- 2 sigma).
get_device_data_for_inferenceCarga útil compuesta para inferencia de IA: metadatos del dispositivo, todas las etiquetas, estadísticas por etiqueta y muestras recientes.
Sistema, Eventosget_system_eventsRecuperar eventos del sistema filtrados por rango de tiempo, componente y severidad (INFO/WARN/ALERT/ERROR).
get_system_event_statsInstantánea de salud del sistema y eventos: tamaño del almacén de eventos, recuentos de eventos de la última hora por severidad, uso de memoria/almacenamiento, número de CPU.
Servidorget_mcp_server_infoInformación de versión sobre el propio servidor MCP (servidor, litmussdk, litmus-cli, Python). Opcionalmente, check_updates compara con las últimas versiones de GitHub; upgrade_cli descarga y activa el litmus-cli más reciente. No necesita conexión al borde.
Sistema, Redget_firewall_rulesDevolver reglas de firewall configuradas: puertos, protocolos, acciones PERMITIR/DENEGAR.
get_network_interface_infoDetalles de interfaz de red: IP, MAC, puerta de enlace, estado del enlace, MTU, velocidad. Por defecto a eth0.
get_packet_capture_interfacesListar interfaces de red disponibles para captura de paquetes.
get_packet_capture_statusEstado actual de captura de paquetes y lista de archivos .pcap capturados con metadatos.
start_packet_captureIniciar una captura de paquetes en una interfaz. Duración de 1 a 30 minutos.
stop_packet_captureDetener una captura de paquetes en curso.
Gemelos Digitaleslist_digital_twin_modelsListar todos los modelos de Gemelos Digitales con ID, nombre, descripción y versión.
create_digital_twin_modelCrear un nuevo modelo de Gemelo Digital.
list_digital_twin_instancesListar todas las instancias de Gemelos Digitales o filtrar por ID de modelo.
create_digital_twin_instanceCrear una nueva instancia de Gemelo Digital a partir de un modelo existente.
list_static_attributesListar atributos estáticos (pares clave-valor fijos) para un modelo, una instancia (por id o nombre), o cada instancia a la vez (all_instances).
list_dynamic_attributesListar atributos dinámicos (puntos de datos en tiempo real) para un modelo, una instancia (por id o nombre), o cada instancia a la vez (all_instances).
list_transformationsListar reglas de transformación de datos configuradas para un modelo de Gemelo Digital.
get_digital_twin_hierarchyObtener la configuración de jerarquía para un modelo de Gemelo Digital.
save_digital_twin_hierarchyGuardar una nueva configuración de jerarquía en un modelo de Gemelo Digital.
Litmus Edge Manager (LEM) ***lem_list_devicesListar dispositivos de borde registrados en un proyecto LEM (paginado).
lem_get_device_detailsRegistro completo del lado LEM para un solo dispositivo de borde (versiones, licencia, última vez visto, configuración).
lem_list_device_versionsListar versiones de Litmus Edge registradas en un proyecto LEM.
lem_list_device_groupsListar etiquetas de grupos de dispositivos (agrupaciones a nivel de proyecto) definidas en un proyecto LEM.
lem_get_license_expiryListar dispositivos cuya licencia expira dentro de los próximos N días.
lem_get_expired_licensesListar dispositivos en un proyecto LEM cuya licencia ya ha expirado.
lem_dashboard_usageResumen de uso del proyecto (recuentos de dispositivos, uso de licencias, estadísticas de implementación).
lem_get_project_alertsListar alertas activas a nivel de proyecto (dispositivo fuera de línea, problemas de licencia, etc.).
lem_list_companiesListar todas las empresas en el inquilino LEM con recuentos de proyectos/dispositivos/modelos.
lem_get_company_detailsDetalles completos para una sola empresa por nombre (equipos, licencia, cuotas).
lem_list_company_projectsListar todos los proyectos que pertenecen a una empresa determinada.
lem_get_project_detailsDetalles de un solo proyecto (zona horaria, TTL de datos, espacios asignados, plan de facturación).
lem_deployment_infoInformación de implementación del inquilino LEM (versión, compilación, metadatos de versión).
lem_get_system_timeReloj del servidor LEM; útil al comparar marcas de tiempo del borde.
Puente LEM ***lem_bridge_list_devicehub_devicesListar dispositivos devicehub en un borde específico mediante túnel a través de LEM (sin cambio de instancia activa).
lem_bridge_get_le_infoInformación de identidad (nombre descriptivo, activación en la nube) para un borde a través del puente LEM.
Respaldo SDK (CLI) ****litmus_sdk_discoverExplorar el catálogo completo del SDK generado (~550 funciones) por prefijo de ruta punteada.
litmus_sdk_readInvocar una función SDK de solo lectura (Get/List/Browse/...) por ruta punteada.
litmus_sdk_writeInvocar una función SDK que cambia el estado por ruta punteada. Con aprobación; potencialmente destructivo.

Notas de Uso de Herramientas

* Requisitos de Herramientas de Temas NATS: Para usar get_current_value_from_topic y get_multiple_values_from_topic, debe configurar el control de acceso en Litmus Edge (list_nats_topics no necesita acceso al broker, ya que lee los nombres de temas desde las API REST/GraphQL en lugar de suscribirse):

  1. Navegue a: Litmus Edge → Sistema → Control de Acceso → Tokens
  2. Cree o configure un token de acceso con los permisos apropiados
  3. Proporcione el token en los encabezados de configuración de su cliente MCP

** Requisitos de Herramientas de InfluxDB / Series Temporales: Para usar cualquier herramienta marcada con ** (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), debe permitir el acceso al puerto de InfluxDB:

  1. Navegue a: Litmus Edge -> Sistema -> Red -> Firewall
  2. Agregue una regla de firewall para permitir el puerto 8086 en TCP
  3. Asegúrese de que InfluxDB sea accesible desde el host del servidor MCP
  4. Proporcione INFLUX_HOST, INFLUX_PORT, INFLUX_DB_NAME, INFLUX_USERNAME, INFLUX_PASSWORD en los encabezados de su cliente MCP *** Requisitos de las herramientas LEM: Las herramientas LEM se comunican con un tenant de Litmus Edge Manager (nube) en lugar de un solo edge. Para usar cualquier herramienta marcada con ***, proporcione estos encabezados en la configuración de su cliente MCP:
  • EDGE_MANAGER_URL: URL base de Litmus Edge Manager (incluya https://)
  • EDGE_API_TOKEN: token de API emitido por LEM
  • EDGE_MANAGER_PROJECT_ID (opcional): id de proyecto predeterminado, utilizado cuando se omite el argumento project_id de una herramienta
  • EDGE_MANAGER_ADMIN_URL (opcional): URL de administración, por defecto el host de EDGE_MANAGER_URL en el puerto 8446

**** Requisitos de las herramientas de respaldo del SDK: litmus_sdk_discover, litmus_sdk_read y litmus_sdk_write están respaldados por el binario Go independiente litmus-cli, al igual que las herramientas seleccionadas de atributos de gemelos digitales y estado de etiquetas. La imagen de Docker lo instala en tiempo de compilación, y run.sh lo instala o actualiza automáticamente para ejecuciones locales (verificado por checksum en .venv/bin, fijado a la misma versión que la imagen de Docker mediante el ARG LITMUS_CLI_VERSION del Dockerfile). Si el servidor se inicia sin él (por ejemplo, un python src/server.py simple), se autoinstala la versión fijada en el primer uso: descargada de los lanzamientos oficiales, verificada con SHA256 y almacenada en caché en ~/.cache/litmus-mcp-server. Los hosts aislados sin acceso a GitHub deben preinstalar el binario en su lugar. Para usar un binario diferente, configure LITMUS_CLI_PATH (omite todo el arranque) o instale uno desde los lanzamientos de cli-v* en https://github.com/litmusautomation/litmus-sdk-releases/releases y colóquelo en PATH. Exponen toda la superficie del SDK generado más allá de las herramientas seleccionadas anteriores. Notas:

  • Los encabezados de conexión se reenvían a la CLI por llamada; no se lee ni escribe ningún perfil de CLI.
  • litmus_sdk_read acepta solo funciones de solo lectura (segmento final que comienza con Get, List, Browse, Describe, Read, Search, Find, Query o Count); todo lo demás pasa por litmus_sdk_write.
  • litmus_sdk_write puede invocar funciones destructivas del SDK (crear/actualizar/eliminar/reiniciar). Cada llamada requiere aprobación explícita del usuario mediante el argumento user_approved, que el asistente solo puede establecer después de que usted apruebe la función y los argumentos exactos.
  • Prefiera las herramientas dedicadas anteriores cuando una cubra la operación.
  • Las funciones unify.* del catálogo apuntan a Litmus Unify, que se autentica por separado de Litmus Edge. Envíe UNS_URL, UNS_USERNAME y UNS_PASSWORD (más UNS_VALIDATE_CERTIFICATE: false para un certificado autofirmado) para usarlas. Sin UNS_URL, el espacio de nombres está oculto de litmus_sdk_discover, ya que cada llamada fallaría por credenciales faltantes; ningún otro espacio de nombres necesita estos encabezados.
  • VALIDATE_CERTIFICATE (opcional): verificar certificados TLS en el puente LEM (por defecto true; consulte verificación de certificados TLS)

Las herramientas lem_bridge_* además se tunelizan a través de LEM a un edge específico y requieren tanto project_id como device_id (el id de dispositivo LEM, como con lem_device_id a continuación) como argumentos de llamada. La página Config -> Litmus Edge Manager de la interfaz web gestiona múltiples conexiones LEM y escribe estos encabezados automáticamente.

Enrutamiento del puente LEM por llamada para herramientas de edge: Cuando EDGE_MANAGER_URL está configurado, cada herramienta dirigida a edge (DeviceHub, Digital Twins, sistema, marketplace y las herramientas de respaldo del SDK) acepta además argumentos opcionales project_id y lem_device_id. Pasar ambos enruta esa única llamada al edge gestionado correspondiente a través del puente LEM, por lo que una configuración solo-LEM (URL + token, sin EDGE_URL) aún puede usar el conjunto completo de herramientas de Litmus Edge: el asistente descubre ids con lem_list_devices y luego llama a las herramientas de edge directamente contra cualquier dispositivo de la flota. Los encabezados EDGE_MANAGER_PROJECT_ID y EDGE_MANAGER_DEVICE_ID siguen siendo compatibles como valores predeterminados estáticos.

lem_device_id es el id de dispositivo LEM de lem_list_devices, no el id de dispositivo DeviceHub que devuelve get_devicehub_devices; los dos son espacios de nombres diferentes. El argumento se llamaba device_id antes, lo que colisionaba con ese id de DeviceHub, y el nombre antiguo aún se acepta para que los clientes existentes sigan funcionando.

Herramientas seleccionadas respaldadas por CLI: Las herramientas de listado de atributos/transformaciones de gemelos digitales y las herramientas de estado de etiquetas se ejecutan a través del binario litmus-cli incluido (misma capa de conexión que las herramientas de respaldo del SDK) en lugar del SDK de Python, por lo que los dispositivos o gemelos con datos inusuales ya no fallan en la validación estricta del lado del cliente, y el enrutamiento del puente LEM se aplica de manera uniforme.

Litmus Central

Descargue o pruebe Litmus Edge a través de Litmus Central.

Registros de servidores MCP

Litmus MCP server

© 2026 Litmus Automation, Inc. Todos los derechos reservados.