What can you do with this server?

Based on the exposed schema, this server provides read-only access to Watchgoose monitoring data. Capabilities include: * list_checks: list checks in the project, optionally filtered by slug or tags, with a maximum of 100 results. * get_check: fetch one check by its stable 40-character unique_key, including current state and schedule. * list_flips: list a check's status-change history, newest first, with optional time filters and a maximum of 200 flips. * Results include metadata about omitted or truncated entries and avoid exposing sensitive API fields. * With a read-write key and writes explicitly enabled, the README says additional management tools become available for pings, channels, and creating/updating/pausing/resuming/deleting checks.

How do I use watchgoose-mcp?

1. Click on "Install 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 Related Servers Score Discussions

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: uptrack-mcp

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.

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.

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

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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

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

ActivityNo data

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
healthchecksio 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
C
maintenance
MCP server for CronAlert uptime monitoring — manage monitors, check results, and incidents from any MCP-compatible AI client.
Updated 2 months ago (2026-07-01 20:17 UTC)
9
117
MIT
uptrack-mcpofficial
Monitoring Observability
Uptrack-App
A
license
Not graded
quality
D
maintenance
MCP server for Uptrack uptime monitoring. Manage monitors and incidents from AI agents like Claude, ChatGPT, and Cursor.
Updated 4 months ago (2026-05-06 13:56 UTC)
13
MIT
Drumbeats MCPofficial
Monitoring Observability
drumbeats-io
A
license
A
quality
A
maintenance
MCP server for Drumbeats monitoring. Enables creating monitors, triaging incidents, and running HTTP/SSL/DNS checks using natural language from any AI client.
Updated 2 days ago (2026-09-04 03:35 UTC)
16
20
2
Apache 2.0
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-09-05 18:44 UTC)
27
AGPL 3.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bartekrutkowski/watchgoose-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Watchgoose MCP

Hosted connector

Available in

Requirements

Claude Desktop

Claude Code

Cursor

VS Code

Environment

Tools

Security

Development

License

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

uptrack-mcpofficial

Drumbeats MCPofficial

uptimepageofficial

Latest Blog Posts

MCP directory API