Staygreen MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STAYGREEN_API_TOKEN | No | A workspace API token created by an administrator in the dashboard under Agents and API (read-only or read-and-write), sent as `Authorization: Bearer <token>`. Used by the local stdio server (`npx -y staygreen mcp`) and for CI/scripts. Optional: with OAuth sign-in (the hosted server at https://staygreen.io/mcp) no token is needed, and without a token the local server can still run `scan_app`. |
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": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_appA | Run a one-time silent-failure scan of a public app URL. Reports certificate/domain expiry, a discoverable status page, detected sign-in dependencies with DNS/TLS/frontend evidence and suggested HTTP/CNAME/NS monitors, optional Supabase health and Stripe delivery failures over 30 days. Optional keys are used once, never stored or returned. Repository cron findings may be supplied by the client. MCP server health is Coming soon. Requires read access; limited per credential and globally. No monitor is created. |
| list_monitorsA | List monitors in your workspace with their app ids, current state and last check, ordered by id. The app, type and status filters combine, each narrowing the same list; with none you get every monitor, automatic SSL checks included. last_check_precision says whether last_check is an exact outcome, the start of its latest five-minute check window, or no data. Never returns credentials or heartbeat URLs. Use get_status instead for each app's overall state and open incidents, get_uptime for history. Call again with cursor set to next_cursor until null. |
| get_statusA | Read the current status of one app or every app: its overall state, monitors (private ones included), status page components and open incidents with their latest published note. Omit app or pass * for the whole workspace; an app id outside your workspace returns not_found. Start here: its app, monitor and incident ids feed the other tools. Use get_uptime or get_incidents for history. No draft notes are returned. |
| get_uptimeA | Read measured uptime, downtime minutes, incident counts and daily history. With monitor omitted or *, every monitor is returned a page at a time (follow next_cursor); a monitor id returns that monitor alone, so pass no cursor with it. window is capped at 30d unless your plan includes a year of history, and the result's window says which one applied. Unmeasured time is no data, not 100% uptime. Use get_response_times instead for latency, and get_incidents for what failed and why. |
| get_response_timesA | Read response-time series for a monitor, optionally by city and country. Uses 5-minute windows for 24h, hourly up to 30d, daily beyond. Larger buckets report maxima of the recorded percentiles, not an exact percentile of raw requests. Follow next_cursor for all points. |
| get_incidentsA | Read incident evidence and timelines for diagnosis, optionally filtered by app, start date and state. Returns incident ids for draft_incident_update, cities and countries, failing assertions and masked snippets. Only the latest published note is included. Follow next_cursor for older pages. |
| get_ssl_and_domain_expiryA | Read certificate and domain expiry dates, with days remaining, for the hosts your SSL monitors check. Omit app for every SSL monitor in the workspace, or pass an app id for that app's hosts only. A null date means Staygreen has no date to show for that host; it never guesses one. Use this for renewal deadlines; use get_status instead for whether a site is up now. Follow next_cursor to read every host. |
| provision_appA | Set up a new app in one transaction: its website check, an automatic SSL/domain check when url is https on port 443 with a hostname that has no SSL monitor yet, a status page, and one heartbeat per crons_from entry. Optional checks come in pairs, supabase_url with supabase_key and stripe_key with stripe_endpoints: half a pair is reported in skipped, and a full pair that fails verification refuses the whole call. mcp_url and status_domain are reported in skipped when supplied. A new app's explicit name must be free; without one, the hostname is made unique. Every option is validated and checked first; then, if url matches an existing app, that app comes back with its monitors as they were (add checks with create_monitor), plus a status page if it had none. A plan_limit error creates nothing and lists what was not created. Heartbeat URLs are returned only to this request and its retries with the same request_id. Needs write access. |
| create_monitorA | Create one monitor in an existing app; for a new app use provision_app instead. type decides what target is and which config keys apply: http takes a URL with method, expect, keyword, slowMs, assertions and headers; tcp a hostname or public IP with port, tls and slowMs; ssl a hostname and no config; dns a record name with record and expected; heartbeat ignores target and takes schedule, tz, graceMin, maxRunMin and assertions, so give it a name; supabase a project URL with key and databaseRead; stripe https://api.stripe.com with key, endpoints, critical, failureThreshold, windowMin and pendingMin. A key belonging to another type is refused. Validation, public-address checks and plan quotas match the dashboard, and Stripe and Supabase checks must verify before saving. Returns a first test result but never a heartbeat's URL, which the dashboard shows. Supply request_id for safe retries. Needs write access. |
| pauseA | Temporarily pause exactly one monitor or every monitor of one app for at most 1440 minutes, then resume automatically. Get ids from list_monitors or get_status. A repeated request_id returns the original pause deadline without extending it. Needs write access. |
| draft_incident_updateA | Save a new plain-text incident note as a draft and return the builder's approval link. Get the incident id from get_incidents. The note never appears publicly until the builder publishes it in the dashboard. Supply request_id for safe retries. Needs write access. |
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 11 tools
The six read tools (get_status, list_monitors, get_uptime, get_response_times, get_incidents, get_ssl_and_domain_expiry) sit close together, but each description explicitly states its distinct metric and cross-references the alternatives ('Use get_uptime ... instead for latency'), which keeps selection reliable. The only real proximity risk is provision_app vs create_monitor, which is handled by an explicit 'for a new app use provision_app instead' rule.
All snake_case with a mostly verb_noun pattern (get_incidents, list_monitors, create_monitor, provision_app, scan_app, draft_incident_update). Minor deviations: the bare verb 'pause' has no object, and draft_incident_update orders the noun before the action, but neither is confusing.
Eleven tools is well within a comfortable range and each one covers a distinct facet: status, monitors, uptime, latency, incidents, expiry, creation, pausing, incident notes, and a one-off scan. No filler tools are apparent.
Read coverage is thorough and provisioning is solid, but the write surface is thin: no update_monitor or delete_monitor, no way to resume a paused monitor early, no app update/delete, and no incident publish (drafting only). Agents can work around some of this via the dashboard, but lifecycle coverage is notably incomplete.