Hatch

Reviewed Jan 1, 2000.

• tools: 21 tools scanned
• metadata: scanned

No findings.

Tools (21)

• hatch

  Create a NEW site (a 'roost') and return its public URL in one call. Returns `{ hatchId, slug, url, apex, promo, uploads? }` — show `url` to the user and remember `hatchId`. NEVER call hatch twice for the same site — use `convert` to rename, change tier, or set Promo, and `upload`/`deploy` for content updates. Pick `apex` from the user's intent (homes / estate / land / wedding / events / agency / site / omit for theroost.dev). Do NOT invent other apexes. Ways to call it: • `html` (PREFERRED for n8n / a single review page) → one self-contained HTML string published at /. Do not also pass site/manifest/script. • Omit `html`, `manifest`, `site`, and `script` → a placeholder page is published instantly. • Pass `manifest` (file list with sizes) → returns presigned `uploads[]`; you PUT each file's bytes directly to its URL. PREFER this for any project with images, fonts, video, or more than a few KB of HTML. • Pass `site` (inline files map) → small text-only sites only. File keys must be p

• upload

  Add or replace files on an EXISTING roost. Pass `hatchId` plus a `manifest` listing each file's path, size, and optional content type. Returns one presigned PUT URL per file — upload bytes directly via HTTP (e.g. `curl -T file.png -H 'Content-Type: image/png' "$url"`). Files go live immediately as each PUT completes; no separate publish call is needed. Use after regenerating a dashboard locally; Hatch does not schedule regenerations.

• lookup

  Resolve a roost by `slug` or `hatchId`. Returns a compact view `{ hatchId, slug, url, apex, tier, state, expiresAt, customDomain, galleryListed, promo, pageviews24h, visitors24h, topPaths, topCountries, topReferrers }`. `promo` is true when the hatch is marked Promo (listed on the public carousel even when its tier would hide it, if active, with a public slug, and not expired; Powered By chip forced on). A password still keeps a Promo hatch off the carousel. Use this to recover state across turns when the user mentions their site without giving you the hatchId. To see every hatch in a workspace, use `list` instead.

• list

  List every hatch in a workspace. Returns `{ workspaceId, name, count, hatches: [{ hatchId, slug, url, apex, kind, tier, state, expiresAt, createdAt, promo, pageviews24h, visitors24h }] }`. `promo` is true when that hatch is marked Promo. Use this when you lost hatchIds, before hatching (so you do not create a duplicate), or when the user asks what is live in the workspace. `workspaceId` is optional when this connector is already paired to a workspace. Requires a workspace-paired session — call `whoami`, then `get_pairing_code` with workspaceId if unidentified.

• rename_org

  Rename the organization and/or workspace after Roost or Roost Audit has been paid. Pass `orgName`, `workspaceName`, or both. Requires a workspace-paired session. Fails on free Hatch workspaces — call `checkout` with grant `workspace_subscription` (Roost) or `agentic_pro` (Roost Audit) first, then `poll_checkout`. Does not rename a hatch URL; use `convert` for that. Returns `{ workspaceId, workspaceName, orgId, orgName, plan }`.

• convert

  Atomically rename a roost's URL, change gallery listing, mark or unmark Promo, or bind a custom domain (Roost / Roost Audit after checkout grant custom_domain). Pass `hatchId` plus at least one of `newPreferredSlug`, `galleryListed`, `promo`, or `customDomain`. Do NOT call `hatch` again to rename or to change Promo — that creates a second site. Optional `promo` (boolean). `true` lists this hatch on the public carousel even when its tier would hide it, if the hatch is active, has a public slug, and is not expired, and forces the Powered By chip on. A password still keeps it off the carousel. `false` unmarks Promo and returns the normal carousel and chip rules. Omit `promo` to leave the flag unchanged. `promo` alone is enough. Roost and Roost Audit include 10 subscription Pins. `convert` with `newTier: forever` is allowed while those slots remain. After that, call `checkout` with grant `publish` (Pin, $4.99/yr). Do not use convert to collect payment. Pins are hidden from the carousel

• catalog

  List VibeRooster features the user can pay for (Pin $4.99/yr, Pack $4.99/yr/GB, Roost $259/mo, Roost Audit $459/mo, custom domain +$29/mo) with Stripe Price ids, amounts, and feature lists. Call this before `checkout` if you don't already know the grant. Returns `{ items: [{ grant, title, description, features, priceId, amountCents, scope }] }`.

• list_templates

  List HTML templates and explorable archetypes from the public template catalog (https://github.com/VibeRooster/hatch-mcp/tree/main/templates). Returns `{ repo, browse, templates: [{ name, title, description, url }] }`. Descriptions come from each file's frontmatter. Open `url` for the HTML and hatch notes — this tool does not return the file body. Add a template by opening a pull request that adds `templates/<name>.md` on that repo. No arguments.

• checkout

  Create a Stripe Checkout Session so the user can pay for a VibeRooster feature in this chat. Returns `{ checkoutUrl, sessionId, grant, amountCents }` — ALWAYS show checkoutUrl to the user (open it / paste it). After they pay, call `poll_checkout` with sessionId until status is `complete`. The webhook applies the grant (Pin, Pack, Roost, Roost Audit, custom domain). Required ids by grant: `publish` / `record` / `credit_topup` / `workspace_coin_pack` (Pack) → hatchId; `workspace_subscription` (Roost) / `custom_domain` → workspaceId (or hatchId in that workspace); `agentic_pro` (Roost Audit) → orgId or workspaceId/hatchId attached to the org. Do not use Stripe MCP (mcp.stripe.com) for VibeRooster features — that would charge a different Stripe account. Hatch `checkout` stamps hatch/workspace/org metadata the webhook expects.

• poll_checkout

  Long-poll a Checkout Session from `checkout` (~18s). Returns `{ status: open|complete|expired, grantApplied, roostUrl, tier }`. If still `open`, tell the user to finish paying at checkoutUrl and call poll_checkout again. When `grantApplied` is true, the webhook has (or is about to) apply the grant — call `lookup` to confirm forever/tier.

• auth

  Put a sign-in screen in front of any roost so visitors must authenticate. Works on free, workspace, and forever hatches. Pass `hatchId` plus an `action`: • `enable` with `mode: "password"` and a `password` → ONE shared site password (everyone uses the same one). Best for a private demo or staging link. • `setPassword` with a new `password` → rotate the shared password. • `disable` → remove the login and serve the site publicly again. • `status` → report whether auth is on and which mode. Returns `{ enabled, mode, loginUrl }`. The sign-in screen lives at `/__roost/login`. Prefer `password` mode; `useraccounts` is unavailable (per-hatch databases are no longer provisioned).

• share

  Issue a signed, expiring guest view URL for any tier (`?vt=…`). Use for private run reports without the shared site password. Returns `{ url, viewToken, expiresAt }`.

• await_decision

  Create a human-in-the-loop review on the live artifact. Default options: Approve / Request changes / Reject. Reviewers see a Review required chip → modal. Request changes is non-terminal: webhook or poll returns changes_requested, then call continue_decision after regenerating. Optional timeoutSeconds and maxIterations (default 5). If the page has interactive controls (sliders/forms), the hatch HTML MUST expose window.__VR_HITL_GET_SETTINGS__ so the review can attach those assumptions as JSON. When the user integrates n8n, Temporal, CI, or any external workflow, pass webhookUrl (MCP opens the review; the platform POSTs each transition to that URL — prefer webhook over poll_decision for automation). See PARTNER-WEBHOOKS.md for event payloads.

• continue_decision

  After poll_decision returns status changes_requested, regenerate, then call this to reopen the same decision as pending_review for the next human round. Only decisionId is required (hatchId is read from the decision).

• poll_decision

  Long-poll (~20s) until the decision leaves pending_review. Only decisionId is required (hatchId is read from the decision). Returns changes_requested (regenerate + continue_decision), approved, rejected, timeout_exceeded, max_iterations_exceeded, not_found, or still pending_review (call again). Includes comment, settings, conversation, iteration. Polling never writes: timeout_exceeded only ever means the await_decision timeoutSeconds deadline passed before the human submitted.

• whoami

  Return the caller's current identity and hatch state. Never errors when unidentified — returns a pairing path instead. After poll_pairing completes, whoami with the same hatchId should show identified:true via server-side session binding. Returns sessionExpiresAt (~1h) and grantExpiresAt (~7d). If sessionExpired:true, call refresh_session with your stored refreshToken.

• get_pairing_code

  Issue a pairing code + URL (TTL 10 minutes) for claiming a hatch (`hatchId`) or authorizing an agent session in a workspace (workspaceId). Reuses the active pending code for this connector session unless `forceNew: true`. For workspace pairing, show `pairingUrl` (https://mcp.theroost.dev/open/workspace-pair) as the link the user taps — it opens the Vibe Rooster app on the phone, and on a computer it opens a page that forwards into the app when the same link is opened on the phone. Do not show only `appUrl`; that viberooster:// link does nothing in a desktop chat. `appUrl` is only for an in-app QR. Do not call again until poll_pairing returns expired/completed or you intentionally rotate with forceNew.

• poll_pairing

  Poll for pairing completion (Device-Grant style). Waits up to ~20s for phone approval before returning. Statuses: pending / completed / expired / not_found. On completed, store sessionToken, refreshToken, and grantId — refreshToken renews access for up to 7 days without re-pairing. When sessionToken expires (~1h), call refresh_session. The server also binds tokens to this connector session. Pass hatchId when known. Device claim ≠ forever billing upgrade.

• refresh_session

  Renew a short-lived access token (~1h) using the refreshToken from poll_pairing. The grant (and refresh capability) lasts up to 7 days — after that, re-pair via get_pairing_code. Each refresh rotates the refreshToken; store the new one. Requires the same connector session (MCP-Session-Id) as when you paired — if fingerprint mismatches, re-pair.

• poll_approval

  Poll a pending Tier-2 phone approval. Returns the result once the owner approves or denies on their phone.

• deploy

  Replace the server-side code of an existing roost. Advanced — most agents should use `upload` (for static files) or `convert` (for renames) instead. Pass `hatchId`, `workerName`, and a full ES module `script` (text only, 1.5 MiB max).