Kaseya VSA

io.github.wyre-technologyPublished by GitHub account wyre-technologyv1.1.4Updated Oct 26, 2026

MCP server for Kaseya VSA RMM — agents, patches, procedures, alarms, tickets.

VerifiedSTDIODesktop onlyCloud & InfrastructureSecurity & Monitoring

Overview

AI-generated overview

MCP server for Kaseya VSA RMM that lets an assistant inspect managed endpoints, inventory, patches, alarms and tickets, and run procedures.

What you can do
  • List and inspect managed endpoints, including an interactive device card with status, OS and IP
  • Read installed software and hardware inventory for an agent
  • Check pending and installed patch status, and force a patch deployment
  • List and run agent procedures
  • List open alarms, Service Desk tickets, organizations and machine groups
When to use it
Useful for IT administrators or managed service providers who want an assistant to answer questions about Kaseya VSA endpoints, patch state, alarms and tickets, or to trigger patch deploys and procedures on managed machines.
Requirements
Runs locally over stdio (npm build/start or the container image). Needs KASEYA_VSA_TENANT_URL including /api/v1.0, plus either KASEYA_VSA_USERNAME and KASEYA_VSA_PASSWORD or KASEYA_VSA_K1_TOKEN. HTTP mode additionally requires CONDUIT_S2S_SECRET; gateway mode takes Kaseya credentials from X-Kaseya-VSA-* request headers.
Before you install
Stores RMM credentials (KASEYA_VSA_PASSWORD or KASEYA_VSA_K1_TOKEN) that grant control over managed endpoints. Deploying patches and running procedures are destructive actions that change machines, though the server asks for confirmation. HTTP mode needs CONDUIT_S2S_SECRET, which must not be committed or set to a placeholder; MCP_ALLOW_INSECURE_DEV=1 disables the S2S check and is for local development only.

Installation

In SourceWeft

  1. Open Kaseya VSA in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

Kaseya VSA MCP Server

[Release] [License: Apache 2.0]

Model Context Protocol (MCP) server for the Kaseya VSA RMM API. Exposes managed endpoints, software / hardware inventory, patch state, agent procedures, alarms, Service Desk tickets, organizations, and machine groups to AI assistants.

Tools

ToolDescription
kaseya_vsa_list_agentsList managed endpoints (agents). Optional $filter.
kaseya_vsa_get_agentGet an agent's details by ID (renders as an interactive card in MCP Apps hosts).
kaseya_vsa_get_software_inventoryInstalled software for an agent.
kaseya_vsa_get_hardware_inventoryHardware audit for an agent.
kaseya_vsa_get_patch_statusPending and installed patches for an agent.
kaseya_vsa_deploy_patches_nowForce a patch deploy on an agent (destructive — confirmation required).
kaseya_vsa_list_proceduresAgent procedures available to run.
kaseya_vsa_run_procedureExecute a procedure on an agent (destructive — confirmation required).
kaseya_vsa_list_alarmsOpen alarms (optional state filter; date-window elicitation if missing).
kaseya_vsa_list_ticketsService Desk tickets (returns a friendly message if SD module isn't enabled).
kaseya_vsa_list_organizationsTenant organizations.
kaseya_vsa_list_machine_groupsMachine group hierarchy.

When the user omits required filters or runs a destructive action, the server uses MCP elicitation to prompt for choices or confirm.

Interactive device card (MCP Apps)

kaseya_vsa_get_agent renders as a read-only interactive device card in MCP Apps hosts (Claude Desktop/web), showing the endpoint's name, online status, organization, machine group, OS, IP address, and last check-in. The card is neutral by default, brandable via window.__BRAND__ injection or MCP_BRAND_* env vars (MCP_BRAND_NAME, MCP_BRAND_LOGO_URL, MCP_BRAND_PRIMARY_COLOR, MCP_BRAND_ACCENT_COLOR, MCP_BRAND_BG, MCP_BRAND_TEXT) applied at serve time. Plain-JSON behavior is unchanged in other hosts. After editing ui/, regenerate the embedded bundle with npm run build:ui.

Configuration

Copy .env.example and set the variables below.

VariableRequiredDescription
KASEYA_VSA_TENANT_URLFor stdio and AUTH_MODE=envFull base URL incl. /api/v1.0. The Compose gateway service does not load this.
KASEYA_VSA_USERNAMEFor stdio and AUTH_MODE=envLocal-auth username (with password). The Compose gateway service does not load this.
KASEYA_VSA_PASSWORDFor stdio and AUTH_MODE=envLocal-auth password (secret). The Compose gateway service does not load this.
KASEYA_VSA_K1_TOKENFor stdio and AUTH_MODE=envKaseya One SSO token (alternative to username + password). The Compose gateway service does not load this.
MCP_TRANSPORTNostdio (default) or http
AUTH_MODENogateway (Docker image and Compose default) or env (code default when unset). Gateway mode requires the X-Kaseya-VSA-* headers on each /mcp request and never falls back to KASEYA_VSA_*. env uses those variables only after S2S auth succeeds.
CONDUIT_S2S_SECRETYes for HTTPService-to-service secret. Generate with openssl rand -hex 32. The HTTP server logs an error and exits non-zero when this is empty or a known placeholder (changeme, your-s2s-secret, secret, placeholder, an unresolved ${...} value, and similar public examples). Compose will not start without it. Never commit a real value. The value is never logged.
MCP_ALLOW_INSECURE_DEVNoSet to exactly 1 only for local development to start HTTP without CONDUIT_S2S_SECRET. The process logs a warning, does not enforce X-Gateway-S2S, and forces the listener onto 127.0.0.1 even if MCP_HTTP_HOST is a wider address. A known placeholder secret is still refused.
MCP_HTTP_HOSTNoBind address when MCP_TRANSPORT=http. Defaults to 127.0.0.1 when unset. A configured CONDUIT_S2S_SECRET honors this value. The container image sets 0.0.0.0.
MCP_HTTP_PORTNoHTTP port. Defaults to 8080.

Either the username + password pair OR KASEYA_VSA_K1_TOKEN is required for stdio and AUTH_MODE=env.

/health stays unauthenticated and does not read credentials. The stdio transport does not use CONDUIT_S2S_SECRET.

HTTP authentication

With MCP_TRANSPORT=http and CONDUIT_S2S_SECRET set, every /mcp request must include X-Gateway-S2S. The check is verifyS2sHeader in src/s2s-verify.ts: the header value is t=<unix seconds>,v1=<hex>, where the hex is HMAC-SHA256 of the literal string t=<unix seconds> keyed with CONDUIT_S2S_SECRET (64 lowercase hex characters). The timestamp must be within 300 seconds of the server clock. A missing or invalid header returns HTTP 401 before vendor credentials are read.

In AUTH_MODE=gateway, /mcp also requires X-Kaseya-VSA-Tenant-Url plus either (X-Kaseya-VSA-Username and X-Kaseya-VSA-Password) or X-Kaseya-VSA-K1-Token. Those headers are the only credential source for that request. A request missing them returns 401 and does not fall back to KASEYA_VSA_* in the process environment.

Each accepted request creates a fresh server instance with isolated credentials — no cross-tenant process.env pollution.

Local development

bash
npm installnpm run buildKASEYA_VSA_TENANT_URL=https://vsa.example.com/api/v1.0 \  KASEYA_VSA_USERNAME=... \  KASEYA_VSA_PASSWORD=... \  npm start

HTTP refuses to start until CONDUIT_S2S_SECRET is set:

bash
CONDUIT_S2S_SECRET="$CONDUIT_S2S_SECRET" MCP_TRANSPORT=http npm startcurl http://127.0.0.1:8080/health

Local HTTP without a secret is development-only. It binds 127.0.0.1 only and logs a warning. A non-loopback MCP_HTTP_HOST is ignored and the override is logged:

bash
MCP_TRANSPORT=http MCP_ALLOW_INSECURE_DEV=1 npm start

Docker

The image listens on 0.0.0.0 inside the container (MCP_HTTP_HOST) and defaults to AUTH_MODE=gateway. Publish the port on loopback and pass the S2S secret. In gateway mode, Kaseya credentials arrive on each request as headers; they are not read from the environment.

bash
docker build -t kaseya-vsa-mcp .docker run --rm \  -e CONDUIT_S2S_SECRET="$CONDUIT_S2S_SECRET" \  -p 127.0.0.1:8080:8080 \  kaseya-vsa-mcp

Compose refuses to start when CONDUIT_S2S_SECRET is unset, sets AUTH_MODE=gateway, does not inject static KASEYA_VSA_* credentials, and publishes 127.0.0.1:8080:8080:

bash
CONDUIT_S2S_SECRET="$CONDUIT_S2S_SECRET" docker compose up

Single-tenant HTTP (AUTH_MODE=env) still requires the S2S secret, then uses KASEYA_VSA_*:

bash
docker run --rm \  -e CONDUIT_S2S_SECRET="$CONDUIT_S2S_SECRET" \  -e AUTH_MODE=env \  -e KASEYA_VSA_TENANT_URL=https://vsa.example.com/api/v1.0 \  -e KASEYA_VSA_USERNAME=... \  -e KASEYA_VSA_PASSWORD=... \  -p 127.0.0.1:8080:8080 \  kaseya-vsa-mcp

License

Apache-2.0

Source: README.md at commit 27c3dc7

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

1
  1. v1.1.4LatestSep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts