Staygreen
NPM · STAYGREEN · 2 COMPONENTS
Uptime monitoring and status pages for apps built with coding agents: status, incidents, setup.
Available components
Last scanned (10 hours ago)
Scores higher than 48% of npm servers
Category Monitoring and Observability
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security100
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- No production dependencies, so there is no dependency health to assess. View diagnostics → Pass
Provenance & Transparency48
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (Apache-2.0).Pass
- Actively maintained (last published 7 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability63
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 2671 tokens (~242/item across 11 items; 11 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management33
- Stability observed for 10 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 11 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 12 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 5 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes.
- 3 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.
- 1 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.
- 30 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.
- 28 Oct 26 +12
- Known CVEs: unverified → pass ▲ security
- Dependency health: unverified → pass ▲ functional
- Security disclosure: fail → pass ▲ functional
- 27 Oct 26 +5
- Known CVEs: pass → unverified ▼ security
- Malware scan: unverified → pass ▲ security
- Dependency health: pass → unverified ▼ functional
- Stability: unverified → 0.03 ▲ functional
- Package version: 0.1.2 → 0.1.3 functional
- 26 Oct 26 53
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Analysed npm/staygreen@0.1.3
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | npm |
Background: How many MCP packages publish verified provenance →
Dependencies 0 packages
| Packages resolved | 0 |
|---|---|
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
create_monitor Create monitor ~388
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.
| Name | Type | Req | Description |
|---|---|---|---|
| app | string | yes | App id from list_monitors, get_status or provision_app. |
| config | object | – | Settings for the chosen type only. Unknown keys and settings for other types are refused. |
| name | string | – | Monitor name. Without one, Staygreen picks a default (a heartbeat's is "Scheduled job"), which this tool does not return; list_monitors shows it. |
| request_id | string | yes | A new UUID for this write. Retry with the same UUID and identical inputs after a lost reply; never reuse it for another operation. |
| target | string | yes | HTTP or Supabase URL, SSL hostname, TCP hostname or public IP, or DNS record name. HTTP(S) URL hostnames may be at most 80 characters. Stripe uses https://api.stripe.com; a heartbeat ignores it. |
| type | string | yes | Monitor type. MCP server monitors are not available yet. |
| Name | Type | Req | Description |
|---|---|---|---|
| first_check | object | yes | – |
| monitor | string | yes | – |
No examples provided.
draft_incident_update Draft incident update ~154
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.
| Name | Type | Req | Description |
|---|---|---|---|
| incident | string | yes | Incident id from get_incidents or get_status. |
| request_id | string | yes | A new UUID for this write. Retry with the same UUID and identical inputs after a lost reply; never reuse it for another operation. |
| state | string | – | State proposed in the draft; does not change the incident or publish the note. |
| text | string | yes | Plain-text draft for the builder to review. This tool never publishes. |
| Name | Type | Req | Description |
|---|---|---|---|
| approval_url | string | yes | – |
| draft | string | yes | – |
| published | boolean | yes | – |
No examples provided.
get_incidents Get incidents ~166
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.
| Name | Type | Req | Description |
|---|---|---|---|
| app | string | – | App id from list_monitors, get_status or provision_app. |
| cursor | string | – | Call again with cursor set to the returned next_cursor until next_cursor is null. |
| limit | integer | – | Maximum records in this page, from 1 to 100; defaults to 50. |
| since | string | – | Only incidents opened at or after this ISO 8601 timestamp; defaults to the plan's history window. |
| state | string | – | Filter to open or resolved incidents. |
| Name | Type | Req | Description |
|---|---|---|---|
| incidents | array | yes | – |
| next_cursor | string|null | yes | – |
No examples provided.
get_response_times Get response times ~180
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.
| Name | Type | Req | Description |
|---|---|---|---|
| cursor | string | – | Call again with cursor set to the returned next_cursor until next_cursor is null. |
| limit | integer | – | Maximum records in this page, from 1 to 100; defaults to 50. |
| location | string | – | Optional check location, using the city and country returned by get_incidents. |
| monitor | string | yes | Monitor id from list_monitors or create_monitor. |
| window | string | – | History window ending now, capped at 30 days without history_1y. The result reports the effective window. |
| Name | Type | Req | Description |
|---|---|---|---|
| aggregation | string | yes | – |
| monitor | string | yes | – |
| next_cursor | string|null | yes | – |
| resolution | string | yes | – |
| series | array | yes | – |
| window | string | yes | – |
No examples provided.
get_ssl_and_domain_expiry Get ssl and domain expiry ~165
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.
| Name | Type | Req | Description |
|---|---|---|---|
| app | string | – | App id from list_monitors, get_status or provision_app. |
| cursor | string | – | Call again with cursor set to the returned next_cursor until next_cursor is null. |
| limit | integer | – | Maximum records in this page, from 1 to 100; defaults to 50. |
| Name | Type | Req | Description |
|---|---|---|---|
| hosts | array | yes | – |
| next_cursor | string|null | yes | – |
No examples provided.
get_status Get status ~114
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.
| Name | Type | Req | Description |
|---|---|---|---|
| app | – | – | App id from list_monitors or provision_app, or * for all apps. |
| Name | Type | Req | Description |
|---|---|---|---|
| apps | array | yes | – |
No examples provided.
get_uptime Get uptime ~206
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.
| Name | Type | Req | Description |
|---|---|---|---|
| cursor | string | – | Call again with cursor set to the returned next_cursor until next_cursor is null. |
| limit | integer | – | Maximum records in this page, from 1 to 100; defaults to 50. |
| monitor | – | – | Monitor id from list_monitors, or * for all monitors. |
| window | string | – | History window ending now, capped at 30 days without history_1y. The result reports the effective window. |
| Name | Type | Req | Description |
|---|---|---|---|
| monitors | array | yes | – |
| next_cursor | string|null | yes | – |
| window | string | yes | – |
No examples provided.
list_monitors List monitors ~220
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.
| Name | Type | Req | Description |
|---|---|---|---|
| app | string | – | App id from list_monitors, get_status or provision_app. |
| cursor | string | – | Call again with cursor set to the returned next_cursor until next_cursor is null. |
| limit | integer | – | Maximum records in this page, from 1 to 100; defaults to 50. |
| status | string | – | Filter by current state; unchecked means no established state yet. |
| type | string | – | Monitor type. MCP server monitors are not available yet. |
| Name | Type | Req | Description |
|---|---|---|---|
| monitors | array | yes | – |
| next_cursor | string|null | yes | – |
No examples provided.
pause Pause ~148
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.
| Name | Type | Req | Description |
|---|---|---|---|
| app | string | – | App id from list_monitors, get_status or provision_app. |
| minutes | integer | yes | Pause length from 1 to 1440 minutes. Monitoring resumes automatically. |
| monitor | string | – | Monitor id from list_monitors or create_monitor. |
| request_id | string | yes | A new UUID for this write. Retry with the same UUID and identical inputs after a lost reply; never reuse it for another operation. |
| Name | Type | Req | Description |
|---|---|---|---|
| monitors | array | yes | – |
| paused_until | string | yes | – |
No examples provided.
provision_app Provision app ~488
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.
| Name | Type | Req | Description |
|---|---|---|---|
| crons_from | array | – | Cron definitions read by your agent from vercel.json or netlify.toml. Send definitions, never a local file path: a remote server cannot read your checkout. |
| mcp_url | string | – | MCP server address; currently reported as skipped because that monitor type is Coming soon. |
| name | string | – | App name, 1 to 60 characters and unique in the workspace ignoring case. Defaults to the hostname, shortened and suffixed as needed to be unique. |
| request_id | string | yes | A new UUID for this write. Retry with the same UUID and identical inputs after a lost reply; never reuse it for another operation. |
| status_domain | string | – | Desired status-page hostname. Domain setup is reported as skipped until the separate status-edge stage is available. |
| stripe_endpoints | array | – | Stripe webhook endpoint ids to monitor with stripe_key. |
| stripe_key | string | – | Restricted Stripe key; also supply stripe_endpoints. Never returned. |
| supabase_key | string | – | That project's publishable or legacy anon key, stored encrypted. |
| supabase_url | string | – | Supabase project URL. Supply supabase_key too to create its health monitor. |
| url | string | yes | Public HTTP(S) app address with a hostname of at most 80 characters. Repeated provisioning of its normalized URL returns the existing setup. |
| Name | Type | Req | Description |
|---|---|---|---|
| app | string | yes | – |
| cname | – | yes | – |
| created | boolean | yes | – |
| heartbeats | array | yes | – |
| monitors | array | yes | – |
| skipped | array | yes | – |
| status_page_url | string | yes | – |
No examples provided.
scan_app Scan app ~205
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.
| Name | Type | Req | Description |
|---|---|---|---|
| crons | array | – | Repository cron findings from the CLI. No file contents or local paths. |
| stripe_key | string | – | Restricted Stripe key, used once and never stored. |
| supabase_key | string | – | Project publishable or matching legacy anon key. Used once, never stored. |
| supabase_url | string | – | Supabase project URL; supply its publishable key too. |
| url | string | yes | Public app URL. No credentials or query parameters. |
| Name | Type | Req | Description |
|---|---|---|---|
| certificate | object | yes | – |
| checked_at | string | yes | – |
| crons | array | yes | – |
| crons_message | string | yes | – |
| dependencies | object | yes | – |
| domain | object | yes | – |
| mcp | string | yes | – |
| status_page | object | yes | – |
| stripe | object | yes | – |
| supabase | object | yes | – |
No examples provided.
How do I install the Staygreen MCP server?
Staygreen runs locally as an npm package, launched with npx -y staygreen. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · staygreen
claude mcp add phuryn-staygreen -- npx -y staygreen
What is the Staygreen MCP server?
Staygreen is an MCP server listed in the public MCP registry as io.github.phuryn/staygreen. Uptime monitoring and status pages for apps built with coding agents: status, incidents, setup. This page covers its npm package (staygreen).
Is the Staygreen MCP server safe to use?
Staygreen scores 74 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Staygreen MCP server expose?
Staygreen exposes 11 tools: scan_app, list_monitors, get_status, get_uptime, get_response_times, and 6 more. Their descriptions and schemas cost roughly 2,434 tokens of context every time the server is loaded.
Is the Staygreen MCP server still maintained?
Staygreen is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the Staygreen MCP server under?
Staygreen declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.