Staygreen MCP Server

Create monitor

create_monitor

Idempotent

Create a monitor for an existing app to check HTTP, TCP, SSL, DNS, heartbeat, Stripe, or Supabase targets; use provision_app first for a new app.

Instructions

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.

Input Schema

Name	Required	Description
`app`	Yes	App id from list_monitors, get_status or provision_app.
`name`	No	Monitor name. Without one, Staygreen picks a default (a heartbeat's is "Scheduled job"), which this tool does not return; list_monitors shows it.
`type`	Yes	Monitor type. MCP server monitors are not available yet.
`config`	No	Settings for the chosen type only. Unknown keys and settings for other types are refused.
`target`	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.
`request_id`	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.

Output Schema

Name	Required	Description	Default
`monitor`	Yes
`first_check`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.1Oct 26, 2026

changedInput schema / properties / name / description

Previous value: -"Monitor name; defaults to a name derived from the target."New value: +"Monitor name. Without one, Staygreen picks a default (a heartbeat's is \"Scheduled job\"), which this tool does not return; list_monitors shows it."

changedInput schema / properties / target / description

Previous value: -"HTTP or Supabase URL, SSL/TCP hostname, DNS record name, or job name for a heartbeat. HTTP(S) URL hostnames may be at most 80 characters. Stripe uses https://api.stripe.com."New value: +"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."

First observedv0.1.0Oct 26, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare non-read-only, idempotent and non-destructive, so the safety profile is baseline. The description adds real context beyond that: cross-type key rejection, validation/public-address checks and plan quotas matching the dashboard, verify-before-save for Stripe/Supabase, a first test result in the response but never a heartbeat URL, and retry guidance. That is above-average disclosure, but return-shape caveats are partly covered by the output schema, keeping it at a solid 3 (leaning 4).

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?

Front-loaded with the action and the sibling alternative, then a dense per-type map where every clause carries information. It is a single long paragraph, though — a per-type list would parse faster — which keeps it from a 5.

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 6-parameter write tool with nested config, an output schema, and full annotations, the description covers the remaining gaps: per-type conditional requirements, validation and quota behavior, verify-before-save, retry semantics via request_id, and permission needs. Nothing an agent needs to call it correctly is absent.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema cannot express: 'type decides what target is and which config keys apply', with each type's required config keys enumerated, and 'a key belonging to another type is refused'. That is genuinely additive, though it restates fields the schema already documents individually rather than adding formats or examples.

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?

States a specific verb and resource ('Create one monitor in an existing app') and immediately scopes it away from the sibling that handles a different case ('for a new app use provision_app instead'). An agent can pick between create_monitor and provision_app without inspecting either schema.

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

Usage Guidelines5/5

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

Gives an explicit routing rule to the sibling provision_app, plus a precondition ('Needs write access') and the constraint that Stripe/Supabase checks must verify before saving. The only mild gap is no guidance on avoiding duplicates against an existing monitor, which is minor.

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

Deploy Server