watchgoose-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WATCHGOOSE_API_KEY | Yes | Project-scoped Watchgoose API key: hcr_ read-only or hcw_ read-write. Create it in Project settings → API Access. | |
| WATCHGOOSE_API_URL | No | Management API base URL. HTTPS is required except for loopback development hosts. The key is sent to this host, so use only a URL you trust. | https://watchgoose.com/api/v3 |
| WATCHGOOSE_ENABLE_WRITES | No | Set to true to expose mutation tools when the key is read-write. | false |
| WATCHGOOSE_API_KEY_ACCESS | No | Required as read-only or read-write for an unprefixed 32-character key. |
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_checksA | List checks in this Watchgoose project, optionally filtered by slug or tags. A successful ping arms a new check; Watchgoose then expects the next success within its timeout or schedule plus grace period. |
| get_checkA | Get one check by its stable unique_key, including its current state and schedule. Cron and OnCalendar checks use schedule plus grace; simple checks use timeout plus grace. |
| list_flipsA | List retained status changes for a check, newest first, with optional time filters. In results, up: 1 means the check became up; up: 0 means any other status, including down, paused, and new after resume. A pause or resume that changes the check's status records a flip. |
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 3 tools
The three tools are clearly distinct: list checks, get a single check by key, and list status changes. There is no meaningful overlap or ambiguity between them.
All tool names follow a consistent lowercase verb_noun pattern: list_checks, get_check, list_flips. The singular/plural difference is natural and appropriate.
Three tools is well-scoped for a read-only monitoring server. Each tool provides a distinct capability with no redundancy or filler.
The read-only monitoring surface is coherent: discover checks, inspect a check, and view its flip history. Check management and ping actions appear to happen outside MCP, so the lack of mutation tools is a minor gap rather than a fatal one.