Staygreen MCP Server

Provision app

provision_app

Idempotent

Provisions a monitored app in one transaction with website, SSL/domain, status page, and cron heartbeat checks, plus optional Supabase and Stripe monitors.

Instructions

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.

Input Schema

Name	Required	Description
`url`	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`	No	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.
`mcp_url`	No	MCP server address; currently reported as skipped because that monitor type is Coming soon.
`crons_from`	No	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.
`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.
`stripe_key`	No	Restricted Stripe key; also supply stripe_endpoints. Never returned.
`supabase_key`	No	That project's publishable or legacy anon key, stored encrypted.
`supabase_url`	No	Supabase project URL. Supply supabase_key too to create its health monitor.
`status_domain`	No	Desired status-page hostname. Domain setup is reported as skipped until the separate status-edge stage is available.
`stripe_endpoints`	No	Stripe webhook endpoint ids to monitor with stripe_key.

Output Schema

Name	Required	Description	Default
`app`	Yes
`cname`	Yes
`created`	Yes
`skipped`	Yes
`monitors`	Yes
`heartbeats`	Yes
`status_page_url`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 26, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds substantial behavior beyond annotations: all-or-nothing transactionality, whole-call refusal on failed pair verification, plan_limit creating nothing, needs write access, and heartbeat URLs being returned only to this request and retries with the same request_id. It doesn't restate the idempotentHint annotation but gives its practical shape via URL normalization.

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 what gets created, then conditional rules, then error/idempotency behavior; nearly every clause carries a distinct fact. It is dense and long for a description, though none of it is clearly wasted.

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 10-parameter, multi-effect write tool with an output schema, the description still covers the failure modes (pair verification failure, plan_limit), idempotency, retry semantics, and skipped reporting. An agent can decide whether and how to call this without further inference.

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 baseline is 3; the description still contributes pairing semantics for supabase_url/supabase_key and stripe_key/stripe_endpoints (half-pair reported in skipped, failed full pair refuses), plus name uniqueness and hostname fallback rules that complement 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?

Opens with a specific verb + resource and enumerates exactly what gets created atomically (website check, conditional SSL/domain check, status page, heartbeats per crons_from entry). It also distinguishes itself from the create_monitor sibling by directing users there for added checks.

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 explicit when-to-use guidance and alternatives: re-provisioning an existing URL returns the existing setup, and additional checks should go through create_monitor. It also states the conditions under which mcp_url and status_domain merely report as skipped.

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

Deploy Server