Skip to main content
Glama
Sign In

Hatch

by com.viberooster
OverviewDiscussionsAdmin

Get pairing code

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.

Input Schema

NameRequiredDescriptionDefault
hatchIdNoHatch id from hatch response (consumer path).
forceNewNoWhen true, invalidate any outstanding QR and mint a new code. Default false — reuse the live pending code from whoami or a prior get_pairing_code.
tenantIdNoLegacy alias for `hatchId`.
workspaceIdNoWorkspace id for B2B agent pairing (partner path).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / forceNew
      Added value: +{
+  "description": "When true, invalidate any outstanding QR and mint a new code. Default false — reuse the live pending code from whoami or a prior get_pairing_code.",
+  "type": "boolean"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / hatchId
      Added value: +{
+  "description": "Hatch id from hatch response (consumer path).",
+  "type": "string"
+}
    • changedInput schema / properties / tenantId / description
      Previous value: -"Hatch id from hatch response (consumer path)."New value: +"Legacy alias for `hatchId`."
  3. Changed3 schema fields changed
    • changedInput schema / properties / tenantId / description
      Previous value: -"Tenant id from hatch response."New value: +"Hatch id from hatch response (consumer path)."
    • addedInput schema / properties / workspaceId
      Added value: +{
+  "description": "Workspace id for B2B agent pairing (partner path).",
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "tenantId"
-]
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the safety profile (readOnly=false, idempotent=false, destructive=false); the description adds the 10-minute TTL, the code-reuse semantics behind idempotentHint, and the critical rendering constraint about which URL to show the user in a desktop chat vs. in-app QR.

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

Conciseness4/5

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

Purpose and TTL are front-loaded, and the URL-display guidance is operationally necessary. It is slightly dense and repeats the reuse rule that schema descriptions also carry, but almost every sentence earns its place.

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

Completeness5/5

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

With no output schema, the description compensates by naming the returned fields (pairingUrl, appUrl), explaining their difference, and giving the polling follow-up. Nothing an agent needs to call and present the result correctly is missing.

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 baseline is 3, but the description adds genuine meaning: it distinguishes the consumer path (hatchId) from the partner path (workspaceId) and clarifies forceNew's rotation behavior. Only tenantId's legacy-alias role is left solely to the schema.

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?

States a concrete verb+resource (issue a pairing code + URL) with a TTL and both distinct use cases (claiming a hatch via hatchId, authorizing an agent session via workspaceId), making it clearly distinguishable from siblings like whoami or poll_pairing.

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?

Explicitly specifies when to reuse the active pending code, when to rotate with forceNew=true, and when not to call again (until poll_pairing returns expired/completed). It also routes the agent on which sibling to use next, leaving nothing to inference.

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
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources