Skip to content
Vibe Rooster logo

Vibe Rooster MCP server

Which MCP servers are Vibe Rooster's own, from the official registry and from asking its own domain, whether they answer, and what they offer. A program checked each of these, nobody copied them from a product page.

read 2026-10-25

← Back to Vibe Rooster

Whose server it is
  • Registry namecom.viberooster/hatchverified in the MCP registry

The registry name sits under viberooster.com. The registry only lets a publisher use that namespace after proving control of the domain through DNS or HTTP.

When we asked itchecked 2026-10-25
  • Stateanswerschecked 2026-10-25
  • Tools24
  • Server calls itselfviberooster-hatch
  • Server version2026-10-19+9be9a68
  • Protocol version2025-06-18

On 2026-10-25 the server answered initialize and tools/list without a sign-in. First answer in 758 ms.

Should an agent connect itNot proven either way yet
  • Whether its tools do the product's job has not been judged yet.
  • Checked on 2 of the 7 days it takes to judge reliability.

Once connected

  • For "publish an agent-built app at a live URL", the likely first call is hatch.
  • upload change data without a sign-in: anyone with the address can call them.
  • Parameters are untyped or undescribed in 8 of 24 tools: check arguments before calling.

Said by rules from the measurements above. The likely first call is a model's pick from the tool list; read its description before relying on it.

Measured dailydaily checks: 2, the first on 2026-10-25
  • INITE MCP scoreafter a weeka score needs 7 daily checks: 2 so far
  • Use1 GitHub stars
  • Answeredmeasuring2 of the 7 daily checks it takes to print a share
  • Median first answer98 ms
  • Space in an agent's context≈ 8,552 tokensthe definitions of all its tools (24), which an agent carries on every turn
  • Tool definitionsA · 94 of 100
  • Typed results0 of 24 toolsdeclared outputSchema: results come typed, read once
  • Parameters without a description: in 8 of 24

What an agent can do with it

  • can do · publish an agent-built app at a live URL
  • not sure · host a single-event site that expires afterward
  • not sure · share an interactive explanation for a board meeting

Each of the product's use cases, put to Jev against this server's tool list: can an agent do it with these tools?

Worth a look

  • Tools that change data, on a server that answers without a sign-in: upload

A program checks the server once a day: initialize and tools/list, no model. Tokens are the definitions' length at about four characters a token. The grade averages six checks of every tool's name, description, schema and annotations; it says how well the tools are described, not whether they work. The score weighs what was measured and nothing else: answering (25%), doing the product's job (25%), definitions (20%), context (10%), use (10%) and how readily a client connects (10%). A part that was not measured is left out, and a hidden instruction caps the score at 40. The state of vendors' MCP servers: method and numbers →

Tools it offers24 tools · read 2026-10-25
  • 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…

  • 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…

  • 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…

  • 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…

  • 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…

  • 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`…

  • 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…

  • 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, prompt, referenceUrl? }]…

  • 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

    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…

  • 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…

  • 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…

  • 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…

  • 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…

  • 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…

  • 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…

  • 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…

  • poll_approval

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

  • alarm

    Sound a loud alarm on the phones paired to this roost. Pass `hatchId` and a short `message` — the phone shows that message and repeats the alarm until the person acknowledges it. Recipients are only phones paired to this roost or its…

  • squawk_request_access

    Ask the roost owner to admit this agent to Squawk. Uses the caller's Hatch pairing session (Authorization: Roost, the bound connector session, or sessionToken from poll_pairing). Returns `{ requestId, status: "pending", expiresAt }`. The…

  • squawk_poll_access

    Poll an admit request opened by squawk_request_access. Uses the same Hatch pairing session. While pending, returns `{ status: "pending", expiresAt }`. After the owner approves, returns the member, the rin_ token once, roostId, and…

  • 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).

How to connect

Add the server to your MCP client config. Claude Desktop, Cursor and most other clients read this shape:

{
  "mcpServers": {
    "hatch": {
      "type": "http",
      "url": "https://mcp.theroost.dev/mcp"
    }
  }
}

Add it

Claude Code, in a terminal

claude mcp add --transport http viberooster https://mcp.theroost.dev/mcp

Add to CursorAdd to VS Code

claude.ai, ChatGPT and other clients: add https://mcp.theroost.dev/mcp as a custom connector in the settings.

Each line is something a program found when it went looking: the registry entry, the server's own answer, a spec that parses. A missing line means we did not find it, not that it does not exist.