saas-alerts-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| logging | {} |
| prompts | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| saas_alerts_navigateA | Browse a domain to see its available tools and descriptions. All tools are callable at any time — navigation is optional discovery, not a gate. |
| saas_alerts_statusA | Check connectivity to SaaS Alerts by fetching the authenticated MSP user. Returns the list of available domains and connection status. |
| saas_alerts_events_queryB | Query security events from SaaS Alerts with optional filters. Returns a paginated list of events matching the specified criteria. |
| saas_alerts_events_countA | Count security events matching the given filters without fetching full records. |
| saas_alerts_events_query_advancedA | Execute an advanced Elasticsearch query against the SaaS Alerts events index. Accepts a raw Elasticsearch query body for maximum flexibility. |
| saas_alerts_events_count_advancedA | Count events using a raw Elasticsearch query body without fetching full records. |
| saas_alerts_events_scrollA | Continue paginating through a previous event query result set using a scroll ID. Call after saas_alerts_events_query_advanced returns a scroll ID. |
| saas_alerts_recommended_actionsA | Get the list of recommended remediation actions for SaaS Alerts event types. Use this to map detected event types to actionable guidance. |
| saas_alerts_customers_listA | List all SaaS Alerts customers for the authenticated partner. |
| saas_alerts_customers_getA | Get a single SaaS Alerts customer by ID. |
| saas_alerts_customers_createB | Create a new SaaS Alerts customer for the authenticated partner. |
| saas_alerts_customers_updateA | Update an existing SaaS Alerts customer by ID. |
| saas_alerts_customers_deleteA | ⚠ DESTRUCTIVE — IRREVERSIBLE. Permanently deletes a SaaS Alerts customer and all associated data. This action cannot be undone. Confirm with the user before invoking. |
| saas_alerts_customers_set_whitelistsA | ⚠ HIGH-IMPACT. Replace the IP/country whitelist for a customer. This overwrites the existing whitelist. Confirm with the user before invoking. |
| saas_alerts_customers_set_account_whitelistsA | ⚠ HIGH-IMPACT. Replace the account-level whitelist for a customer. This overwrites the existing account whitelist. Confirm with the user before invoking. |
| saas_alerts_users_get_mspA | Get the MSP user profile associated with the authenticated API key. Also used as a connectivity / credential check. |
| saas_alerts_users_list_partnerA | List all users associated with the authenticated partner account. |
| saas_alerts_users_list_by_customerA | List all users belonging to a specific SaaS Alerts customer. |
| saas_alerts_devices_list_mappedA | List devices that have been mapped (unified) to SaaS Alerts customer organizations. |
| saas_alerts_devices_list_unmappedA | List devices that have NOT yet been mapped to a SaaS Alerts organization. Optionally filter by confidence score or whether mapping suggestions are available. |
| saas_alerts_devices_list_ignoredA | List devices that have been explicitly marked as ignored. |
| saas_alerts_devices_list_orgsA | List all device organizations visible to the authenticated partner. |
| saas_alerts_billing_get_detailsA | Retrieve billing details for a specific billing date. Use saas_alerts_billing_list_dates first to discover available dates. |
| saas_alerts_billing_list_datesA | List all available billing dates for the authenticated partner. Use the returned dates as input to saas_alerts_billing_get_details. |
| saas_alerts_reports_list_scheduledA | List all scheduled reports configured for the authenticated partner. |
| saas_alerts_reports_get_scheduledA | Get a specific scheduled report by its ID. |
| saas_alerts_reports_create_scheduledB | Create a new scheduled report. |
| saas_alerts_reports_delete_scheduledA | ⚠ DESTRUCTIVE — IRREVERSIBLE. Permanently delete a scheduled report. This action cannot be undone. Confirm with the user before invoking. |
| saas_alerts_partner_get_profileA | Get the partner profile associated with the authenticated API key. |
| saas_alerts_partner_update_brandingA | ⚠ HIGH-IMPACT. Update the partner branding settings (logo, colours, etc.). This overwrites existing branding. Confirm with the user before invoking. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| alert-triage | Triage SaaS Alerts security events — query critical events, rank by impact, cross-ref recommended actions |
| customer-alert-summary | Summarise security alerts for a specific customer over a time window |
| cross-tenant-anomaly | Use advanced Elasticsearch queries to find an event pattern across all customers |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 30 tools
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.
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.
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.
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.