Skip to main content
Glama

Hatch

by com.viberooster
OverviewDiscussionsAdmin

Rename or change tier

convert
DestructiveIdempotent

Atomically rename a roost's URL and/or change gallery listing. Pass hatchId plus at least one of newPreferredSlug (rename) or galleryListed (opt in/out of the Barnyard carousel on viberooster.com). Do NOT call hatch again to rename — that creates a second site.

Do NOT pass newTier: forever to collect payment — that is rejected on the public connector. To make a roost permanent, call checkout with grant publish, show checkoutUrl, then poll_checkout. The Stripe webhook promotes the roost after payment.

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hatchIdNoHatch id from the original hatch response.
newTierNoOperator/webhook only on the public connector. Agents must use `checkout` (grant: publish) for forever — do not pass newTier: forever.
tenantIdNoLegacy alias for `hatchId`.
sessionTokenNoOptional paired session token from poll_pairing (when Authorization headers are unavailable).
galleryListedNoOpt in (`true`) or out (`false`) of the public Barnyard carousel. Forever requires `true` to appear; free is listed unless `false`. Paid Workspace hatches (`tier: workspace`) are never listed.
newPreferredSlugNoNew hostname label. The old slug is released atomically.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / galleryListed / description
      Previous value: -"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`."New value: +"Opt in (`true`) or out (`false`) of the public Barnyard carousel. Forever requires `true` to appear; free is listed unless `false`. Paid Workspace hatches (`tier: workspace`) are never listed."
  2. Changed3 schema fields changed
    • addedInput schema / properties / hatchId
      Added value: +{
+  "description": "Hatch id from the original hatch response.",
+  "type": "string"
+}
    • addedInput schema / properties / tenantId / description
      Added value: +"Legacy alias for `hatchId`."
    • removedInput schema / required
      Removed value: -[
-  "tenantId"
-]
  3. Changed1 schema field changed
    • changedInput schema / properties / newTier / description
      Previous value: -"New tier. Clears `expiresAt` when promoting to `forever`."New value: +"Operator/webhook only on the public connector. Agents must use `checkout` (grant: publish) for forever — do not pass newTier: forever."
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint, readOnlyHint, etc.), the description discloses atomicity ('Atomically rename'), the effect of galleryListed on forever roosts ('Forever roosts are hidden from the carousel by default'), and the rejection behavior of newTier: forever. These details materially impact how an agent invokes the tool and what outcomes to expect, and they do not contradict any annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, front-loaded with the core action and requirement, then the most critical warning (newTier: forever), then the default behavior detail. Every sentence carries necessary information with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 6 parameters and no required fields, the description covers the primary use cases (rename, gallery toggle), the key exclusions, and the correct alternative for permanent tier. It does not explicitly explain how 'change tier' (to free) works via newTier, but the schema covers that and the description already tells agents to avoid forever. This is complete enough for correct invocation.

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 the schema documents each parameter fully. However, the description adds a key semantic constraint not present in the schema: 'Pass hatchId plus at least one of newPreferredSlug or galleryListed.' It also clarifies the newTier parameter by reiterating the checkout requirement. Since the schema already does most of the work, this is a 4 rather than 5.

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?

The description clearly states the tool's purpose: 'Atomically rename a roost's URL and/or change gallery listing.' It specifies the resource (roost) and the actions (rename/change gallery), and explicitly distinguishes from 'hatch' by warning 'Do NOT call hatch again to rename — that creates a second site.' This gives agents crisp scope and differentiates it from related tools.

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?

The description provides explicit when-to-use and when-not-to-use guidance: it states the condition ('Pass hatchId plus at least one of newPreferredSlug or galleryListed') and gives clear exclusions: 'Do NOT call hatch again to rename' and 'Do NOT pass newTier: forever to collect payment.' It also names the correct alternative workflow ('To make a roost permanent, call checkout...') making the routing unambiguous.

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

All Hatch toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources