omniwatchguard-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OWG_API_KEY | No | OmniWatchGuard API key (owg_live_...). Optional: without it the server starts and lists its tools. |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_monitorsA | List all OmniWatchGuard monitors of the authenticated user, with the number of changes in the last 7 days and the last detected change. |
| get_monitorA | Get the full details of one monitor and its last 20 check results. |
| create_monitorA | Create a new monitor for a web page. Types: text, price, stock, css, api, seo, ssl (tech_stack and whois need the matching add-on). The number of monitors and the available check intervals depend on the user's plan. |
| update_monitorC | Update fields of an existing monitor: name, URL, selector, check interval or price/stock thresholds. |
| set_monitor_statusC | Pause or resume an existing monitor. |
| delete_monitorC | Delete an existing monitor. |
| list_alertsB | List the latest alerts sent to the user (email, webhook, Slack, Discord, Telegram), with details of the change that triggered each one. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool has a clearly distinct purpose: CRUD for monitors, one status toggle, and one alert listing. The only potential overlap between update_monitor and set_monitor_status is explicitly resolved by the descriptions (fields vs. pause/resume).
All tool names follow a consistent snake_case verb_noun pattern (list_monitors, get_monitor, create_monitor, update_monitor, delete_monitor, set_monitor_status). The one deviation, set_monitor_status, is still the same convention with a compound noun.
Seven tools is a well-scoped set for a monitor-and-alert service, covering the lifecycle without bloat. Every tool has a clear place in the workflow.
The surface covers monitor CRUD, pause/resume, and alert listing, which are the core operations. Minor gaps exist, such as no alert acknowledgement/mark-read, no bulk operations, and no check-history retrieval beyond the last 20 results in get_monitor.