# Hatch (remote · mcp.theroost.dev)

Hosting for AI agents: publish a live website in one tool call, ephemeral or forever.

- Trust score: 61/100 (medium)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-21

## Components

- remote · `mcp.theroost.dev`: 61/100 (this document), [markdown](https://verifymcp.io/servers/com-viberooster-hatch/mcp.md), [page](https://verifymcp.io/servers/com-viberooster-hatch/mcp)

## Channel facts

- Endpoint: `https://mcp.theroost.dev/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0-1`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-21.

- **Endpoint Security**: 46/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (upload).
  - HTTPS enforcement could not be verified: the plaintext port answered with HTTP 405, which proves neither a plaintext path nor enforcement.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 74/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 4097 tokens (~273/item across 15 items; 15 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 23/100
  - Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 89/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 66% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http com-viberooster-hatch https://mcp.theroost.dev/mcp
```

### Codex

```toml
[mcp_servers.com-viberooster-hatch]
url = "https://mcp.theroost.dev/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-viberooster-hatch": {
      "type": "remote",
      "url": "https://mcp.theroost.dev/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-viberooster-hatch --url https://mcp.theroost.dev/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-viberooster-hatch:
    url: "https://mcp.theroost.dev/mcp"
```

### Other

```json
{
  "mcpServers": {
    "com-viberooster-hatch": {
      "type": "http",
      "url": "https://mcp.theroost.dev/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-21 (score 61, +1)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “await_decision” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 248 → 273
- [functional] Server version: 2026-08-12+eafb90d → 2026-08-21+4adea95
- [cosmetic] “await_decision” reworded the description of “webhookUrl”
- [cosmetic] “hatch” reworded the description of “tenantId”

### 2026-08-19 (score 60, +1)

No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-17 (score 59, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-15 (score 58, +1)

- [functional improvement] Stability: unverified → 0.03

### 2026-08-14 (score 57)

First indexed and scored.

## MCP tools (15)

### `hatch` (~763 tokens)

Hatch a new site

Create a NEW site (a 'roost') and return its public URL in one call. Returns `{ tenantId, slug, url, apex, uploads? }` — show `url` to the user and remember `tenantId`. NEVER call hatch twice for the same site — use `convert` to rename or change tier, 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.

Four ways to call it:
• Omit `manifest`, `site`, and `script` → a placeholder page is published instantly (best zero-token first turn).
• 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. Files are sent in the request body, so this is expensive in tokens for anything bigger than a handful of HTML/CSS files.
• Pass `script` → advanced: full server-side code as one ES module (1.5 MiB max, text only — NEVER base64-embed binaries here).

Input parameters:

- `apex` (string): Specialty hostname apex for the live URL (`https://{slug}.{apex}`). Choose from user intent: theroost.homes (residential listing), theroost.estate (commercial/luxury), theroost.land (land/parcels), t…
- `kind` (string): Artifact kind. Use `run-report` for agent observability / compliance run reports; default `site` for consumer sites.
- `manifest` (object): PREFERRED for sites with assets. List every file you want served, with its byte size and optional MIME type. The response includes one presigned PUT URL per file; upload bytes directly via HTTP (e.g.…
- `preferredSlug` (string): Hostname label. Omit for a friendly auto-name (e.g. swift-falcon-7a).
- `script` (string): Advanced: full server-side code as one ES module. Text only, 1.5 MiB hard limit. NEVER embed images/fonts/binaries here — use `manifest` instead.
- `scriptMetadata` (object)
- `site` (object): Inline file map. Suitable ONLY for small text-only sites (a handful of HTML/CSS files). For anything with images or binaries, use `manifest` instead.
- `tenantId` (string): Optional id to reuse. Omit entirely to auto-generate. Do not send an empty string (n8n: leave this field unmapped). Lowercase letters, numbers, and hyphens only; 1–50 chars; must start and end alphan…
- `tier` (string, required): `free` auto-expires (default 48h; override with `ttlSeconds`). `forever` is persistent.
- `tosAcceptedAt` (string): ISO-8601 timestamp
- `ttlSeconds` (integer): Free-tier TTL in seconds (1h–7d). Default 172800 (48h). Ignored for `forever`.

### `upload` (~170 tokens)

Upload files to an existing site

Add or replace files on an EXISTING roost. Pass `tenantId` 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.

Input parameters:

- `expiresSeconds` (integer): URL TTL in seconds (default 3600).
- `manifest` (object, required)
- `sessionToken` (string): Optional paired session token from poll_pairing (when Authorization headers are unavailable).
- `tenantId` (string, required): Tenant id from the original hatch response.

### `lookup` (~91 tokens)

Lookup a site

Resolve a roost by `slug` or `tenantId`. Returns a compact view `{ tenantId, slug, url, apex, tier, state, expiresAt, customDomain, galleryListed }`. Use this to recover state across turns when the user mentions their site without giving you the tenantId.

Input parameters:

- `slug` (string): Hostname label (without the apex domain)
- `tenantId` (string)

### `convert` (~241 tokens)

Rename or change tier

Atomically rename a roost's URL and/or change its tier. Pass `tenantId` plus at least one of `newPreferredSlug` (rename), `newTier` (e.g. `free` → `forever`), or `galleryListed` (opt in/out of the Barnyard carousel on viberooster.com). Do NOT call `hatch` again to upgrade — that creates a second site with a new id.

Forever roosts are hidden from the carousel by default; pass `galleryListed: true` when promoting to forever to feature the site publicly.

Input parameters:

- `galleryListed` (boolean): Opt in (`true`) or out (`false`) of the public Barnyard carousel. Forever tier requires `true` to appear; free tier is listed unless set to `false`.
- `newPreferredSlug` (string): New hostname label. The old slug is released atomically.
- `newTier` (string): New tier. Clears `expiresAt` when promoting to `forever`.
- `sessionToken` (string): Optional paired session token from poll_pairing (when Authorization headers are unavailable).
- `tenantId` (string, required)

### `auth` (~302 tokens)

Protect a site with a login

Put a sign-in screen in front of a `forever` roost so visitors must authenticate. Pass `tenantId` 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 }`. Auth is only available on `forever` roosts — `convert` a free roost first. The sign-in screen lives at `/__roost/login`. Prefer `password` mode; `useraccounts` is unavailable (per-tenant databases are no longer provisioned).

Input parameters:

- `action` (string): What to do. Defaults to `status`.
- `mode` (string): `password` = one shared site password (recommended). `useraccounts` is unavailable. Required when `action` is `enable`.
- `password` (string): The shared site password (password mode only). Required for `enable` (password mode) and `setPassword`.
- `sessionToken` (string): Optional paired session token from poll_pairing (when Authorization headers are unavailable).
- `tenantId` (string, required): Tenant id from the original hatch response.

### `share` (~71 tokens)

Guest view link

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

Input parameters:

- `expiresSeconds` (integer)
- `sessionToken` (string)
- `tenantId` (string, required)

### `await_decision` (~378 tokens)

Await human 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.

Input parameters:

- `agentOutput` (string): Optional seed of the agent’s current output into the conversation transcript.
- `contextUrl` (string)
- `maxIterations` (integer): Max review rounds (default 5). Requesting changes at the last iteration fails with max_iterations_exceeded.
- `options` (array): Radio choices (default Approve, Request changes, Reject). Labels are classified into approve / reject / changes_requested.
- `sessionToken` (string)
- `tenantId` (string, required)
- `timeoutSeconds` (integer): Wall-clock timeout for this review round; omit for no timeout.
- `title` (string): Modal heading (default: Finish your review).
- `webhookUrl` (string): HTTPS URL that receives a POST on every HITL transition (decision.resolved, decision.changes_requested, timeout, etc.). Prefer this over poll_decision when wiring n8n, Temporal, or other automation —…

### `continue_decision` (~100 tokens)

Continue HITL after changes requested

After poll_decision returns status changes_requested, regenerate, then call this to reopen the same decision as pending_review for the next human round.

Input parameters:

- `agentOutput` (string): Summary of the revised output for the conversation transcript.
- `decisionId` (string, required)
- `sessionToken` (string)
- `tenantId` (string, required)
- `timeoutSeconds` (integer): Optional new timeout for this review round.
- `title` (string)

### `poll_decision` (~77 tokens)

Poll decision resolution

Long-poll (~20s) until the decision leaves pending_review. Returns changes_requested (regenerate + continue_decision), approved, rejected, timeout_exceeded, max_iterations_exceeded, or still pending_review. Includes comment, settings, conversation, iteration.

Input parameters:

- `decisionId` (string, required)
- `tenantId` (string, required)

### `whoami` (~132 tokens)

Check identity

Return the caller's current identity and tenant state. Never errors when unidentified — returns a pairing path instead. After poll_pairing completes, whoami with the same tenantId 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.

Input parameters:

- `sessionToken` (string): Optional token from poll_pairing. Pass when whoami stays unidentified after a successful pair (connectors that cannot set Authorization headers).
- `tenantId` (string): Optional tenant to check or re-pair against.

### `get_pairing_code` (~93 tokens)

Get pairing code

Issue a fresh pairing code + URL (TTL 10 minutes) for claiming a tenant or authorizing a new agent session. Render pairingUrl as a QR for the Vibe Rooster app. Prefer this over whoami when starting a pairing flow. Do not call again until poll_pairing returns expired/completed — repeated calls invalidate the previous code.

Input parameters:

- `tenantId` (string, required): Tenant id from hatch response.

### `poll_pairing` (~148 tokens)

Poll pairing completion

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 tenantId when known. Device claim ≠ forever billing upgrade.

Input parameters:

- `code` (string, required): Pairing code from get_pairing_code / whoami.
- `tenantId` (string): Optional tenant id — improves lookup after the phone has approved.

### `refresh_session` (~133 tokens)

Refresh agent 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.

Input parameters:

- `refreshToken` (string, required): Opaque refresh token from poll_pairing (vr1.{grantId}.{secret}).
- `tenantId` (string, required): Tenant id from hatch / poll_pairing.

### `poll_approval` (~47 tokens)

Poll destructive-op approval

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

Input parameters:

- `approvalId` (string, required)
- `tenantId` (string, required)

### `deploy` (~147 tokens)

Replace site code (advanced)

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

Input parameters:

- `approvalId` (string): Tier-2 phone approval id from a prior deploy attempt.
- `metadata` (object)
- `script` (string, required): Full ES module source.
- `sessionToken` (string): Optional paired session token from poll_pairing (when Authorization headers are unavailable).
- `tenantId` (string, required)
- `workerName` (string, required)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-viberooster-hatch/mcp#diagnostics

## Score history

- 2026-08-21: 61
- 2026-08-20: 60
- 2026-08-19: 60
- 2026-08-18: 59
- 2026-08-17: 59
- 2026-08-16: 58
- 2026-08-15: 58
- 2026-08-14: 57

## Links

- Remote endpoint: https://mcp.theroost.dev/mcp
- Repository: https://github.com/VibeRooster/viberooster.github.io
- Website: https://viberooster.com/install.html
- Changelog RSS feed: https://verifymcp.io/servers/com-viberooster-hatch/mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-viberooster-hatch/mcp.json
- HTML version of this page: https://verifymcp.io/servers/com-viberooster-hatch/mcp