Skip to main content
Glama
saas-alerts-mcp

saas-alerts-mcp

by am3cramirez

saas-alerts-mcp

A fully self-contained Model Context Protocol server for Kaseya SaaS Alerts — the SaaS security monitoring platform for Microsoft 365 and Google Workspace events.

It wraps the SaaS Alerts External Partner API (Reports) v0.20.0 and exposes it as 30 MCP tools plus 3 workflow prompts. The API client is vendored in-tree (src/sdk), so the server builds and runs with a single public dependency (@modelcontextprotocol/sdk) — no private packages, no external SDK to install.

Features

Domain

Tools

events

Query/count security events by severity, customer, user, event type; advanced Elasticsearch queries; scroll pagination; recommended actions

customers

List, get, create, update, delete customers; set IP/country and account whitelists

users

MSP user info, partner users, customer users

devices

Unify mapped/unmapped/ignored devices, device organizations

billing

Billing details by date, billing date history

reports

List/get/create/delete scheduled reports

partner

Partner profile, branding settings

  • Two navigation helpers — saas_alerts_navigate (browse a domain's tools) and saas_alerts_status (connectivity check against the authenticated MSP user).

  • Three prompts — alert-triage, customer-alert-summary, cross-tenant-anomaly.

  • Write/destructive guards — mutating tools carry annotations.destructiveHint and, where irreversible, a ⚠ DESTRUCTIVE description prefix. They request confirmation via MCP elicitation and fail open (proceed) if the client doesn't support it.

  • Empty-result guard — list tools return isError with a clear "No … found" message instead of an empty payload, to stop the model hallucinating results.

Related MCP server: superops-mcp

Authentication

SaaS Alerts authenticates with an API key sent as the api_key HTTP header (not Authorization: Bearer). Generate one in the SaaS Alerts UI under Settings → API Keys.

Set it via the SAAS_ALERTS_API_KEY environment variable.

Quick start

npm install      # also builds via the `prepare` script
npm run build    # or build explicitly
export SAAS_ALERTS_API_KEY=your-api-key
node dist/index.js          # stdio transport

Importing into Hermes (or any MCP host)

The server speaks standard MCP over stdio, so it drops into any MCP host that uses the common mcpServers config block. Build it once (npm run build), then point your host at dist/index.js.

Copy .mcp.json.example into your host's MCP config and edit the path + key:

{
  "mcpServers": {
    "saas-alerts": {
      "command": "node",
      "args": ["/absolute/path/to/saas-alerts-mcp/dist/index.js"],
      "env": {
        "SAAS_ALERTS_API_KEY": "your-saas-alerts-api-key",
        "MCP_TRANSPORT": "stdio"
      }
    }
  }
}

After import, the host will discover all 30 saas_alerts_* tools. Call saas_alerts_status first to confirm the key is valid and connectivity is up.

Tip: if your Hermes deployment prefers a network endpoint over a spawned process, run the server in HTTP mode (below) and register the http://host:8080/mcp URL instead.

HTTP mode

export SAAS_ALERTS_API_KEY=your-api-key
export MCP_TRANSPORT=http
export MCP_HTTP_PORT=8080
node dist/http.js
  • POST /mcp — MCP endpoint (stateless streamable-HTTP, JSON responses).

  • GET /health — liveness probe (does not require credentials).

Gateway mode (multi-tenant)

Set AUTH_MODE=gateway. The server then reads the per-request API key from the X-SaaS-Alerts-API-Key header instead of the environment, and isolates each request's credentials in an AsyncLocalStorage context. The HTTP transport is intentionally kept stateless to preserve that per-request tenant isolation.

Running with Docker

export SAAS_ALERTS_API_KEY=your-api-key
docker compose up --build

The container runs HTTP mode on port 8080 with a /health healthcheck, as a non-root user.

Configuration

Variable

Default

Description

SAAS_ALERTS_API_KEY

—

Required (env/stdio mode). Sent as the api_key header.

MCP_TRANSPORT

stdio

stdio or http.

MCP_HTTP_PORT

8080

HTTP mode listen port.

MCP_HTTP_HOST

0.0.0.0

HTTP mode bind host.

AUTH_MODE

env

env reads the key locally; gateway reads X-SaaS-Alerts-API-Key per request.

LOG_LEVEL

info

debug | info | warn | error (logs go to stderr).

Development

npm install
npm run build              # bundle to dist/ (ESM, with .d.ts)
npm test                   # vitest — SDK transport/resources + MCP domain handlers
npm run lint               # tsc --noEmit
npm run lint:destructive   # assert destructive tools carry warnings

Architecture

src/
  index.ts        stdio entrypoint
  http.ts         streamable-HTTP entrypoint (+ gateway mode)
  server.ts       MCP Server wiring: tools/list, tools/call, prompts
  prompts.ts      3 workflow prompts
  domains/        one handler per API domain (events, customers, …)
  elicitation/    destructive-action confirmation guard (fail-open)
  utils/          request-scoped credentials, result helpers, logger
  sdk/            vendored typed client for the SaaS Alerts Partner API
    http.ts       fetch transport: retries, timeouts, key redaction, typed errors
    resources/    one class per domain, mapping methods → REST endpoints
    client.ts     SaasAlertsClient façade

The API base URL defaults to the production host (https://us-central1-the-byway-248217.cloudfunctions.net/reportApi/api/v1) and can be overridden by constructing SaasAlertsClient with a baseUrl (dev/QA hosts are documented in the OpenAPI spec).

Attribution

The MCP surface design (domain layout, tool naming, destructive-action conventions) follows the open-source wyre-technology/saas-alerts-mcp project. This build vendors the API client in-tree so it is fully buildable and importable standalone.

License

Apache-2.0 — see LICENSE.

Available Tools

30 tools
saas_alerts_billing_get_detailsA
Read-onlyIdempotent

Retrieve billing details for a specific billing date. Use saas_alerts_billing_list_dates first to discover available dates.

Inputs: billing_date (required).

saas_alerts_billing_list_datesA
Read-onlyIdempotent

List all available billing dates for the authenticated partner. Use the returned dates as input to saas_alerts_billing_get_details.

Inputs: no named parameters.

saas_alerts_customers_createB

Create a new SaaS Alerts customer for the authenticated partner.

Inputs: body (required).

saas_alerts_customers_deleteA
Destructive

⚠ DESTRUCTIVE — IRREVERSIBLE. Permanently deletes a SaaS Alerts customer and all associated data. This action cannot be undone. Confirm with the user before invoking.

Inputs: customer_id (required).

saas_alerts_customers_getA
Read-onlyIdempotent

Get a single SaaS Alerts customer by ID.

Inputs: customer_id (required).

saas_alerts_customers_listA
Read-onlyIdempotent

List all SaaS Alerts customers for the authenticated partner.

Inputs: no named parameters.

saas_alerts_customers_set_account_whitelistsA
DestructiveIdempotent

⚠ HIGH-IMPACT. Replace the account-level whitelist for a customer. This overwrites the existing account whitelist. Confirm with the user before invoking.

Inputs: body (required), customer_id (required).

saas_alerts_customers_set_whitelistsA
DestructiveIdempotent

⚠ HIGH-IMPACT. Replace the IP/country whitelist for a customer. This overwrites the existing whitelist. Confirm with the user before invoking.

Inputs: body (required), customer_id (required).

saas_alerts_customers_updateA
Idempotent

Update an existing SaaS Alerts customer by ID.

Inputs: body (required), customer_id (required).

saas_alerts_devices_list_ignoredA
Read-onlyIdempotent

List devices that have been explicitly marked as ignored.

Inputs: organization_ids (required).

saas_alerts_devices_list_mappedA
Read-onlyIdempotent

List devices that have been mapped (unified) to SaaS Alerts customer organizations.

Inputs: organization_ids (required).

saas_alerts_devices_list_orgsA
Read-onlyIdempotent

List all device organizations visible to the authenticated partner.

Inputs: no named parameters.

saas_alerts_devices_list_unmappedA
Read-onlyIdempotent

List devices that have NOT yet been mapped to a SaaS Alerts organization. Optionally filter by confidence score or whether mapping suggestions are available.

Inputs: organization_ids (required), confidence, only_with_suggestions.

saas_alerts_events_countA
Read-onlyIdempotent

Count security events matching the given filters without fetching full records.

Inputs: end_date, event_type, start_date, customer_id, +1 more.

saas_alerts_events_count_advancedA
Read-onlyIdempotent

Count events using a raw Elasticsearch query body without fetching full records.

Inputs: query (required).

saas_alerts_events_queryB
Read-onlyIdempotent

Query security events from SaaS Alerts with optional filters. Returns a paginated list of events matching the specified criteria.

Inputs: from, size, end_date, time_sort, +5 more.

saas_alerts_events_query_advancedA
Read-onlyIdempotent

Execute an advanced Elasticsearch query against the SaaS Alerts events index. Accepts a raw Elasticsearch query body for maximum flexibility.

Inputs: query (required).

saas_alerts_events_scrollA
Read-onlyIdempotent

Continue paginating through a previous event query result set using a scroll ID. Call after saas_alerts_events_query_advanced returns a scroll ID.

Inputs: scroll_id (required).

saas_alerts_navigateA
Read-onlyIdempotent

Browse a domain to see its available tools and descriptions. All tools are callable at any time — navigation is optional discovery, not a gate.

Inputs: domain (required).

saas_alerts_partner_get_profileA
Read-onlyIdempotent

Get the partner profile associated with the authenticated API key.

Inputs: no named parameters.

saas_alerts_partner_update_brandingA
DestructiveIdempotent

⚠ HIGH-IMPACT. Update the partner branding settings (logo, colours, etc.). This overwrites existing branding. Confirm with the user before invoking.

Inputs: body (required).

saas_alerts_reports_create_scheduledB

Create a new scheduled report.

Inputs: body (required).

saas_alerts_reports_delete_scheduledA
Destructive

⚠ DESTRUCTIVE — IRREVERSIBLE. Permanently delete a scheduled report. This action cannot be undone. Confirm with the user before invoking.

Inputs: report_id (required).

saas_alerts_reports_get_scheduledA
Read-onlyIdempotent

Get a specific scheduled report by its ID.

Inputs: report_id (required).

saas_alerts_reports_list_scheduledA
Read-onlyIdempotent

List all scheduled reports configured for the authenticated partner.

Inputs: no named parameters.

saas_alerts_statusA
Read-onlyIdempotent

Check connectivity to SaaS Alerts by fetching the authenticated MSP user. Returns the list of available domains and connection status.

Inputs: no named parameters.

saas_alerts_users_get_mspA
Read-onlyIdempotent

Get the MSP user profile associated with the authenticated API key. Also used as a connectivity / credential check.

Inputs: no named parameters.

saas_alerts_users_list_by_customerA
Read-onlyIdempotent

List all users belonging to a specific SaaS Alerts customer.

Inputs: customer_id (required).

saas_alerts_users_list_partnerA
Read-onlyIdempotent

List all users associated with the authenticated partner account.

Inputs: no named parameters.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.6/5.0

    Scored across 30 tools

    Disambiguation5/5

    Each tool has a clearly distinct purpose: customers, devices, events, billing, reports, and partner operations are all separated. Even similar tools like events_query and events_query_advanced are differentiated by the use of raw Elasticsearch versus standard filters. No two tools appear to do the same thing.

    Naming Consistency5/5

    All tools follow the consistent pattern 'saas_alerts_<resource>_<action>', using snake_case throughout. Actions like list, get, create, update, delete, and set are used predictably. The few top-level tools (navigate, status) still retain the 'saas_alerts' prefix and are easy to understand.

    Tool Count2/5

    With 30 tools, the server exceeds the 25+ threshold that indicates an overly large tool set. The broad scope of SaaS Alerts management justifies many tools, but there is some redundancy (e.g., multiple device list tools and separate navigation/status tools) that could be consolidated.

    Completeness2/5

    Customer CRUD is well covered, but there are significant gaps: devices have only list operations (no mapping or ignoring actions), scheduled reports lack an update tool, and users have no management beyond listing. These missing operations create dead ends for agents trying to perform common workflows.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      B
      maintenance
      An MCP server for the NinjaOne RMM platform, enabling tools to manage devices, organizations, alerts, jobs, and policies through NinjaOne's API.
      29
      Apache 2.0
    • A
      license
      A
      quality
      B
      maintenance
      An MCP server for SuperOps PSA/RMM, enabling MSPs to manage tickets, assets, clients, and field technician operations through SuperOps's API.
      22
      3
      Apache 2.0
    • A
      license
      Not graded
      quality
      B
      maintenance
      MCP server for Kaseya VSA — endpoints, patches, procedures, alarms, and tickets. Enables AI assistants to manage and monitor devices via the Kaseya VSA RMM platform.
      Apache 2.0