Kaseya BMS

Kaseya BMS viene eseguito in locale a partire da un’immagine container in un registro OCI come Docker Hub o GitHub Container Registry: ghcr.io/wyre-technology/kaseya-bms-mcp:v1.1.4. Comunica via MCP su stdio, quindi il client lo avvia come programma e dialoga con esso tramite standard input e standard output. Richiede Docker o un altro runtime di container OCI; si avvia con docker run - il comando abituale è docker run -i --rm -e KASEYA_BMS_TENANT_SUBDOMAIN -e KASEYA_BMS_API_TOKEN -e KASEYA_BMS_K1_TOKEN -e MCP_TRANSPORT -e AUTH_MODE -e LOG_LEVEL ghcr.io/wyre-technology/kaseya-bms-mcp:v1.1.4. Legge queste variabili d’ambiente: KASEYA_BMS_TENANT_SUBDOMAIN (obbligatorio), KASEYA_BMS_API_TOKEN (segreto), KASEYA_BMS_K1_TOKEN (segreto), MCP_TRANSPORT, AUTH_MODE e LOG_LEVEL; vanno impostate nella configurazione del client per questo server.

Nel formato JSON mcpServers, letto da molti client MCP desktop e per editor di codice, la voce si presenta così (segnaposto tra parentesi angolari):

{
  "mcpServers": {
    "kaseya-bms-mcp": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "KASEYA_BMS_TENANT_SUBDOMAIN",
        "-e",
        "KASEYA_BMS_API_TOKEN",
        "-e",
        "KASEYA_BMS_K1_TOKEN",
        "-e",
        "MCP_TRANSPORT",
        "-e",
        "AUTH_MODE",
        "-e",
        "LOG_LEVEL",
        "ghcr.io/wyre-technology/kaseya-bms-mcp:v1.1.4"
      ],
      "env": {
        "KASEYA_BMS_TENANT_SUBDOMAIN": "<valore>",
        "KASEYA_BMS_API_TOKEN": "<segreto>",
        "KASEYA_BMS_K1_TOKEN": "<segreto>",
        "MCP_TRANSPORT": "<valore>",
        "AUTH_MODE": "<valore>",
        "LOG_LEVEL": "<valore>"
      }
    }
  }
}

Ricavato dalla voce del registro, non testato qui. Cosa fa il server, e a quali condizioni, lo stabilisce il suo editore; prima di concedergli l’accesso ai propri account o file conviene consultarne il repository o il sito web. Come aggiungere un server MCP a un assistente · Prima di collegare un server