What can you do with this server?

Summary: This server provides read-only access to Watchgoose cron/recurring-task monitoring data for a project — checks and their status history. * List checks (list_checks) — optionally filtered by exact slug, required tags, and limit (1–100); returns names, status, schedule, timeout/grace, channels, last/next ping, ping counts. * Get one check (get_check) — fetch a single check by its stable 40-character unique_key with full current state and schedule (cron/OnCalendar use schedule + grace; simple checks use timeout + grace). * List status changes (list_flips) — retained flips for a check, newest first, with optional start/end (Unix seconds) or seconds lookback and limit up to 200; up: 1 means the check became up. * Read-only and idempotent — all three tools are marked read-only, non-destructive, closed-world; no mutation, ping, or integration tools appear in this schema. * Writes exist but are not exposed here — per the README, list_pings, list_channels, create_check, update_check, pause_check, resume_check, and delete_check require an hcw_ read-write key and WATCHGOOSE_ENABLE_WRITES=true. * Bounded, privacy-trimmed output — results are capped (100 checks, 200 flips) and truncated with meta counts; UUIDs, ping URLs, IPs, and unknown API fields are stripped.

How do I use watchgoose-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@watchgoose-mcp show me the status of all my cron job checks" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

watchgoose-mcp

by bartekrutkowski

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Watchgoose MCP

Watchgoose MCP connects MCP-capable AI clients to the Watchgoose Management API. It lets you inspect cron and recurring-task monitoring, with check changes available only when you explicitly enable writes.

Hosted connector

Use the hosted Streamable HTTP endpoint in clients that support OAuth 2.1 and Dynamic Client Registration:

https://mcp.watchgoose.com/mcp

Available in

Watchgoose is available in the Claude connector directory.

Watchgoose is listed in ChatGPT plugins for GPT and Codex.

Watchgoose is listed in the official MCP Registry.

The watchgoose-mcp package is available on npm.

In Claude, open Settings > Connectors and add the endpoint as a custom connector. For Claude Code, run:

claude mcp add --transport http --scope user watchgoose https://mcp.watchgoose.com/mcp

The browser consent flow limits each connection to one project and defaults to read-only access. See the Watchgoose MCP documentation for the tool and privacy boundaries.

Related MCP server: uptimepage

Requirements

Node.js 20 or later
A project-scoped Watchgoose API key from Project settings → API Access → Create (read-only)

Use an hcr_ read-only key when you only need check state and status history. Use an hcw_ read-write key when you also need pings, integrations, or check changes.

Claude Desktop

Add this entry to claude_desktop_config.json and restart Claude Desktop:

{
  "mcpServers": {
    "watchgoose": {
      "command": "npx",
      "args": ["-y", "watchgoose-mcp"],
      "env": {
        "WATCHGOOSE_API_KEY": "hcr_your_project_key"
      }
    }
  }
}

Claude Code

claude mcp add --env WATCHGOOSE_API_KEY=hcr_your_project_key \
  --transport stdio --scope user watchgoose -- npx -y watchgoose-mcp

Run claude mcp get watchgoose to check the connection.

Cursor

Create .cursor/mcp.json in your project, or add the same entry to your user MCP configuration:

{
  "mcpServers": {
    "watchgoose": {
      "command": "npx",
      "args": ["-y", "watchgoose-mcp"],
      "env": {
        "WATCHGOOSE_API_KEY": "hcr_your_project_key"
      }
    }
  }
}

VS Code

Create .vscode/mcp.json:

{
  "servers": {
    "watchgoose": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "watchgoose-mcp"],
      "env": {
        "WATCHGOOSE_API_KEY": "hcr_your_project_key"
      }
    }
  }
}

Run MCP: List Servers and start watchgoose.

Environment

Variable	Required	Default	Description
`WATCHGOOSE_API_KEY`	Yes	-	Project-scoped `hcr_` read-only key, `hcw_` read-write key, or legacy 32-character key.
`WATCHGOOSE_API_URL`	No	`https://watchgoose.com/api/v3`	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.
`WATCHGOOSE_ENABLE_WRITES`	No	`false`	Set to `true` to expose mutation tools when the key is read-write.
`WATCHGOOSE_API_KEY_ACCESS`	Legacy keys only	-	Required as `read-only` or `read-write` for an unprefixed 32-character key.

The server classifies key prefixes locally and never probes the API to infer access. Setting WATCHGOOSE_ENABLE_WRITES=true cannot give a read-only key additional access.

Tools

Checks are addressed by stable 40-character unique_key values. UUIDs, ping URLs, and integration UUIDs are used only inside the server and are not shown to the AI client.

Tool	Required access	Management API mapping
`list_checks`	Read-only	`GET /checks/`
`get_check`	Read-only	`GET /checks/<unique_key>`
`list_flips`	Read-only	`GET /checks/<unique_key>/flips/`
`list_pings`	Read-write	Resolve `unique_key`, then `GET /checks/<uuid>/pings/`
`list_channels`	Read-write	`GET /channels/`
`create_check`	Read-write plus writes enabled	`POST /checks/`
`update_check`	Read-write plus writes enabled	Resolve `unique_key`, then `POST /checks/<uuid>`
`pause_check`	Read-write plus writes enabled	Resolve `unique_key`, then `POST /checks/<uuid>/pause`
`resume_check`	Read-write plus writes enabled	Resolve `unique_key`, then `POST /checks/<uuid>/resume`
`delete_check`	Read-write plus writes enabled	Resolve `unique_key`, then `DELETE /checks/<uuid>`

Integration assignments use exact integration names. Names must be non-empty and unique within the project.

create_check is a create-or-update operation when unique is supplied: a matching existing check has its supplied settings replaced. timeout without schedule also switches a scheduled check to interval monitoring: the stored schedule string remains, but no longer governs cadence. Include the confirmed schedule to retain scheduled monitoring. Other omitted settings remain unchanged. channels: [] clears all alert integration assignments. The tool therefore advertises destructiveHint: true. A new check awaits success/failure for completion-based cadence; a first failure can move it down. An optional start ping can initiate runtime monitoring before completion.

List results are capped at 100 checks, 100 pings, 200 flips, and 100 integrations. Every serialized tool result is also capped at 24,000 characters. Results include metadata when entries are omitted.

Security

Writes are disabled by default, even with an hcw_ key.
The API key is sent only in the X-Api-Key header and is never logged or returned.
API redirects are rejected so credentials cannot be forwarded to another host.
Check UUIDs, ping and update URLs, integration UUIDs, and unknown future API fields are removed from output.
Pings keep only type, date, n, scheme, method, and duration. Source IP addresses, user agents, run IDs, and body URLs are removed.
Ping bodies are never requested.
The server has no telemetry.

Protect client configuration files that contain API keys. Prefer a dedicated project and the least-privileged key that exposes the tools you need. Revoke a key from Watchgoose project settings when it is no longer in use.

Workflow skills

The repository includes portable skills for auditing scheduled-job coverage, drafting single-job setup, triaging missed heartbeats, reviewing existing monitoring health, and proposing approved create-only batches from an audit, list or CSV. See the skills guide for local installation, examples, and safety boundaries. Skills do not grant additional access, automatically run jobs, or change the existing directory listings.

Development

npm install
npm run format:check
npm run lint
npm run typecheck
npm test
npm run publish:dry-run

Production integration tests are opt-in and require dedicated test-project keys. They never run in CI.

License

MIT

Various badges

MCP Badge

Available Tools

3 tools

get_checkGet a Watchgoose checkA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`unique_key`	Yes	40-character stable check identifier from list_checks.

Output Schema

ParametersJSON Schema

Name	Required	Description
`meta`	No
`check`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds useful behavioral detail beyond annotations: it returns current state and schedule, and explains that Cron/OnCalendar checks use schedule plus grace while simple checks use timeout plus grace.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no redundancy. The primary purpose and identifier are front-loaded, and the second sentence adds meaningful behavioral nuance without unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with strong annotations and an output schema, the description sufficiently explains what the tool does, what it returns, and the relevant scheduling nuance. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents unique_key as a 40-character stable identifier from list_checks. The description repeats 'stable unique_key' but adds no new parameter semantics beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Get'), resource ('one check'), identifier ('stable unique_key'), and the content returned ('current state and schedule'). It clearly distinguishes from siblings: list_checks lists checks, while this retrieves a single one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use this tool when you need a single check by its unique_key, not a list. It does not explicitly exclude alternatives, but the 'one check by its stable unique_key' phrasing implies the appropriate use case, and the schema parameter notes the key comes from list_checks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_checksList Watchgoose checksA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`slug`	No	Exact check slug to match, using lowercase letters, numbers, hyphens, or underscores.
`tags`	No	Tags that every returned check must have, for example ["production", "backup"].
`limit`	No	Maximum number of checks to return, from 1 to 100.

Output Schema

ParametersJSON Schema

Name	Required	Description
`meta`	Yes
`checks`	Yes

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful domain context about how pings arm checks and expectations after timeout/schedule plus grace period, but it does not disclose tool-specific behavior such as sorting, pagination, or response shape beyond the existing schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: the first sentence states the action, resource, and filters. The second sentence is concise and adds useful domain context, though it is somewhat tangential to actually invoking list_checks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity, read-only list operation with a fully described input schema, an output schema, and complete annotations, the description is largely sufficient. It specifies project scope and filtering, though explicit sibling differentiation would make it fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with slug, tags, and limit each already described in the input schema. The description only restates the slug/tags filter idea and adds no parameter-level meaning beyond what the schema provides, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise action and resource: 'List checks in this Watchgoose project'. It also states the optional filters (slug or tags), and the collection-scope wording naturally distinguishes this from the sibling tools get_check and list_flips.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through 'optionally filtered by slug or tags', but it never explicitly contrasts this tool with get_check or list_flips. There is no when-to-use vs. alternatives guidance, only a clear statement of what the tool does.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_flipsList a check's status changesA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`end`	No	Exclusive upper bound for status-change timestamps, as Unix seconds; for example 1592217980.
`limit`	No	Maximum number of status changes to return, from 1 to 200.
`start`	No	Inclusive lower bound for status-change timestamps, as Unix seconds; for example 1592214380.
`seconds`	No	Lookback window for status changes in seconds, from 0 to 31536000; for example 3600.
`unique_key`	Yes	40-character stable check identifier from list_checks.

Output Schema

ParametersJSON Schema

Name	Required	Description
`meta`	Yes
`flips`	Yes

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent annotations, the description explains key output semantics: up: 1 means became up, up: 0 includes down/paused/new-after-resume, and pause/resume that changes status records a flip. This materially helps an agent interpret results and is not visible in the schema alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core operation, followed by the essential semantics of the up field and flip recording. Every sentence contributes useful information with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations and an output schema present, the description sufficiently covers what the tool returns, how results are ordered, and what counts as a flip. The required unique_key and optional time filters are documented in the schema, so nothing critical is missing for invoking the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds only the general notion of 'optional time filters,' which aligns with start/end/seconds but provides no additional parameter-level meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'List retained status changes for a check.' It also states the ordering ('newest first') and clearly distinguishes this tool from siblings by focusing on status-change history rather than listing checks or fetching a single check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use this when you need a check's status changes with optional time filters. It does not explicitly name alternatives or say when not to use it, but the operation is distinct enough from list_checks and get_check that the intended use is evident.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

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

3 tool updatesv1.0.1Sep 4, 2026

Changedget_check1 field changed
- addedInput schema / properties / unique_key / description
```
Added value: +"40-character stable check identifier from list_checks."
```

Changedlist_checks3 fields changed

addedInput schema / properties / limit / description

Added value: +"Maximum number of checks to return, from 1 to 100."

addedInput schema / properties / slug / description

Added value: +"Exact check slug to match, using lowercase letters, numbers, hyphens, or underscores."

addedInput schema / properties / tags / description

Added value: +"Tags that every returned check must have, for example [\"production\", \"backup\"]."

Changedlist_flips5 fields changed

addedInput schema / properties / end / description

Added value: +"Exclusive upper bound for status-change timestamps, as Unix seconds; for example 1592217980."

addedInput schema / properties / limit / description

Added value: +"Maximum number of status changes to return, from 1 to 200."

addedInput schema / properties / seconds / description

Added value: +"Lookback window for status changes in seconds, from 0 to 31536000; for example 3600."

addedInput schema / properties / start / description

Added value: +"Inclusive lower bound for status-change timestamps, as Unix seconds; for example 1592214380."

addedInput schema / properties / unique_key / description

Added value: +"40-character stable check identifier from list_checks."

3 tool updatesv1.0.0Sep 3, 2026
- First observedget_check
- First observedlist_checks
- First observedlist_flips

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-09-04 13:30 across 3 tools

Disambiguation5/5

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.

Naming Consistency5/5

All tool names follow a consistent lowercase verb_noun pattern: list_checks, get_check, list_flips. The singular/plural difference is natural and appropriate.

Tool Count5/5

Three tools is well-scoped for a read-only monitoring server. Each tool provides a distinct capability with no redundancy or filler.

Completeness4/5

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.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

sentinelOAuth
io.rootstuff
Uptime, SSL, DNS and domain monitoring you can talk to from Claude or any MCP client.
Monitoring Observability
21
UptimeRobotOAuth
com.uptimerobot
Monitor websites, APIs, and servers: create monitors, triage incidents, and query uptime stats.
Monitoring Observability
123
Healthchecks.io MCP by usefulapi A
io.usefulapi
Manage cron/heartbeat checks, read pings and flips, pause/resume/delete on Healthchecks.io.
Monitoring Observability
122
AIStatusDashboard
io.github.aistatusdashboard
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Monitoring Observability
2

Related MCP Servers

cronalert-mcp
Monitoring Observability
jaredhobbs
A
license
A
quality
B
maintenance
MCP server for CronAlert uptime monitoring — manage monitors, check results, and incidents from any MCP-compatible AI client.
Updated 15 days ago (2026-09-25 20:19 UTC)
9
131 npm
MIT
uptimepageofficial
Monitoring Observability
uptimepage
A
license
Not graded
quality
A
maintenance
MCP server for Uptimepage uptime monitoring. An LLM client can read your monitors and incidents, run a check on demand, and post incident updates. Writes need an OAuth login and a scoped token, and each one is logged.
Updated 12 hours ago (2026-10-10 11:36 UTC)
42
AGPL 3.0
keepitalive-mcp
Monitoring Observability
salab3rt
A
license
Not graded
quality
B
maintenance
MCP server for KEEPitALIVE monitoring, enabling AI agents to read and manage monitors, incidents, triggers, and notification routing via the v1 API, with scope-based tool filtering and safety modes.
Updated 2 months ago (2026-08-22 17:47 UTC)
5 npm
1
MIT
uptime-kuma-rest
Monitoring Observability
gaido-dev
A
license
Not graded
quality
B
maintenance
Enables LLM clients to manage Uptime Kuma HTTP(S) monitors, groups, tags, and notifications, and to retrieve heartbeats, stats, and incident history through MCP tools.
Updated a month ago (2026-09-06 14:07 UTC)
MIT

Watchgoose MCP

Hosted connector

Available in

Requirements

Claude Desktop

Claude Code

Cursor

VS Code

Environment

Tools

Security

Workflow skills

Development

License

Various badges

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

cronalert-mcp

uptimepageofficial

keepitalive-mcp

uptime-kuma-rest