Login

Continue with

New to AlertsDown? Give Claude Code, Codex, Cursor, Windsurf, OpenClaw, or Hermes Agent one secure instruction. It can onboard you with Free Builders or a paid plan (card checkout or x402 payment). If the email already owns an account, no key is issued—sign in or recover access, then use the MCP plan tools for upgrades. Claims are idempotent: if a credential-claim response is lost, retrying with the same valid claim token returns the same stored key.

Help me set up AlertsDown securely.
Set up AlertsDown for me.
1. Read https://api.alertsdown.com/.well-known/alertsdown-agent.json and call GET https://api.alertsdown.com/api/agent/plans to discover the live plans, billing periods, prices, and payment methods. Never hard-code plan IDs or prices.
2. Ask me once for my real email address, the URLs I want monitored, and whether I want the Free plan or a paid plan (and which billing period and payment method). Never invent an email.
3. Free choice: call POST https://api.alertsdown.com/api/agent/bootstrap with { email, urls, clientInfo: { name: "<this agent>" } }. A 201 response returns { account, apiKey: { secret, scopes, auth, authHeader }, mcp, next } with a newly issued secret. Store the API key immediately in my user-level secret environment as ALERTSDOWN_MCP_API_KEY; never print it in chat or write it to a repository. Resolve the auth header from response.authHeader ?? response.auth; treat authHeader as canonical and keep auth for legacy responses. If neither field is present, fall back to "Authorization: Bearer <API_KEY>". Never print, log, or commit a real API key; reference the secret ALERTSDOWN_MCP_API_KEY.
4. Paid choice: call POST https://api.alertsdown.com/api/agent/bootstrap with { email, urls, planId, billingPeriod, paymentMethod, clientInfo: { name: "<this agent>" } }. A 202 response returns { purchaseId, claimToken, checkout?, x402?, statusUrl, claimUrl }. Keep the valid claim token secure until the credential is stored.
   - Payment methods are discovered from the live manifest in step 1. If the manifest reports no paid billing periods, choose Free Builders instead of inventing a payment method.
   - The credential-claim response exposes the same { apiKey: { secret, scopes, auth, authHeader } } shape as the Free flow. Credential claims are idempotent: if the response is lost, retrying with the same valid claim token returns the same secret. Never use a different or invented token. Resolve the auth header from response.authHeader ?? response.auth; treat authHeader as canonical and keep auth for legacy responses. If neither field is present, fall back to "Authorization: Bearer <API_KEY>". Never print, log, or commit a real API key; reference the secret ALERTSDOWN_MCP_API_KEY. Paid and Free onboarding must produce identical canonical auth guidance.
   - No account, monitors, or key are created until payment is fulfilled.
5. Configure the returned hosted MCP endpoint (https://api.alertsdown.com/api/mcp) with the resolved auth header and the key from ALERTSDOWN_MCP_API_KEY.
6. Prefer this client's native MCP configuration or current MCP SDK over hand-rolled JSON-RPC. AlertsDown supports MCP 2026-07-28 over Streamable HTTP and the legacy 2025-11-25 revision. For 2026-07-28, do not send initialize, initialized, or Mcp-Session-Id; every request is independent. If calling the endpoint directly, include the required per-request _meta fields (io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientInfo, io.modelcontextprotocol/clientCapabilities) and HTTP headers (MCP-Protocol-Version, Mcp-Method, and Mcp-Name for tools/call, prompts/get, and resources/read). Use server/discover when capability or version discovery is needed, and retry with a mutually supported revision when the server returns UnsupportedProtocolVersionError. Do not hand-roll raw JSON-RPC when the client already supports MCP.
7. Ask me for the 6-digit email verification code and verify the primary email contact through MCP.
8. List the monitors and report the plan limits and entitlement end date.
9. No-argument MCP tools — get_account, list_plans, list_contacts, list_agent_webhooks — accept an empty {} input. Call them normally; do not invent dummy parameters or a requestId workaround.
10. Before email verification, the provisional bootstrap key includes monitors:read, so list_urls and get_url work and only return monitors belonging to the bootstrapped account. Provisional monitor access does not imply unrestricted API access; stay within the scopes returned during onboarding.
11. Respect API limits: honor the rate limits, request quotas, and payload-size limits the backend returns or documents. On HTTP 429, read Retry-After and use bounded exponential backoff; do not retry aggressively. Do not retry authentication, validation, permission, payment, or other non-transient 4xx failures. Keep requests account-scoped and within the API-key scopes returned during onboarding.
12. If bootstrap returns HTTP 409 with code "email_already_registered", stop onboarding. Explain that the account already exists and no new API key was created. Ask me to sign in or use the account recovery link sent by email. After I sign in, direct me to Account → MCP/API Keys. Tell me to create and configure the API key myself. Never ask me to paste the API key into the agent chat. Tell me to notify the agent only after configuration is complete. Only then may the agent use the MCP list_plans and purchase_plan tools for paid plan changes; an existing card subscription returns a billing portal URL instead of a duplicate checkout.

Sign In to Your Account

Set up AlertsDown from your editor