Skip to main content
Glama
Sign In
Postbuild MCP

Postbuild MCP

Official
by xdlabs-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Read @postbuild.dev Verification Inbox & Confirm Directory Links

postbuild_inbox
Idempotent

Retrieve inbound verification emails and 6-digit OTP codes from a licensed domain inbox, optionally visiting allowlisted confirmation links, to complete directory email verification after form submissions.

Instructions

Retrieve inbound directory verification emails and 6-digit OTP codes from a domain-bound <slug>@postbuild.dev inbox, and optionally follow allowlisted confirmation links. Requires a valid Launch Pass license (pb_live_...) whose verified domain owns inbox (when inbox is omitted, defaults to the licensed domain's inbox; mismatched domains fail with FORBIDDEN_INBOX); when auto_verify: false (default), the call is strictly read-only and wraps untrusted email text in <<<UNTRUSTED_CONTENT_DATA_ONLY>>> guards, whereas auto_verify: true sends SSRF-guarded HTTP GET requests across at most 2 ESP redirect hops to allowlisted directory confirmation paths. Use this tool after submitting directory forms to complete email/OTP verification; do not use it to generate submission links (postbuild_dispatch) or to inspect initial domain readiness (postbuild_scan).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "postbuild_inbox"
  }
}

Input Schema

NameRequiredDescriptionDefault
inboxNoTarget `<slug>@postbuild.dev` address (defaults to the inbox bound to the active Launch Pass license).
auto_verifyNoWhen false (default), performs a side-effect-free read; when true, visits allowlisted confirmation URLs via HTTP GET.

Output Schema

NameRequiredDescriptionDefault
mcpNoStateful session delta compaction metadata.
messagesYesCompacted verification email records with spotlighted untrusted fields.
inboxAddressYesResolved `<slug>@postbuild.dev` inbox address.
extractedOtpsYes6-digit OTP verification codes extracted from inbound messages.
verifiedCountYesNumber of confirmation links verified across messages.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.1.24
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / auto_verify / default
      Added value: +false
    • changedInput schema / properties / auto_verify / description
      Previous value: -"Opt-in: follow allowlisted confirmation links (default: false)"New value: +"When false (default), performs a side-effect-free read; when true, visits allowlisted confirmation URLs via HTTP GET."
    • changedInput schema / properties / inbox / description
      Previous value: -"Bot inbox address"New value: +"Target `<slug>@postbuild.dev` address (defaults to the inbox bound to the active Launch Pass license)."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "extractedOtps": {
+      "description": "6-digit OTP verification codes extracted from inbound messages.",
+      "items": {
+        "properties": {
+          "from": {
+            "description": "Sender address.",
+            "type": "string"
+          },
+          "messageId": {
+            "description": "Message identifier.",
+            "type": "string"
+          },
+          "otpCode": {
+            "description": "Extracted OTP code.",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "inboxAddress": {
+      "description": "Resolved `<slug>@postbuild.dev` inbox address.",
+      "type": "string"
+    },
+    "mcp": {
+      "description": "Stateful session delta compaction metadata.",
+      "type": "object"
+    },
+    "messages": {
+      "description": "Compacted verification email records with spotlighted untrusted fields.",
+      "items": {
+        "properties": {
+          "autoVerified": {
+            "description": "True if the confirmation link was visited and verified.",
+            "type": "boolean"
+          },
+          "from": {
+            "description": "Sender email address.",
+            "type": "string"
+          },
+          "id": {
+            "description": "Unique message ID.",
+            "type": "string"
+          },
+          "otpCode": {
+            "description": "Extracted verification code if present.",
+            "type": "string"
+          },
+          "primaryLink": {
+            "description": "Primary confirmation URL wrapped in untrusted content delimiters.",
+            "type": "string"
+          },
+          "receivedAt": {
+            "description": "ISO 8601 timestamp when the email arrived.",
+            "type": "string"
+          },
+          "status": {
+            "description": "Verification status ('pending' or 'verified').",
+            "type": "string"
+          },
+          "subject": {
+            "description": "Email subject line.",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "verifiedCount": {
+      "description": "Number of confirmation links verified across messages.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "inboxAddress",
+    "verifiedCount",
+    "extractedOtps",
+    "messages"
+  ],
+  "type": "object"
+}
  2. First observedv2.1.23

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses what the annotations cannot: the Launch Pass license requirement, the FORBIDDEN_INBOX failure on domain mismatch, untrusted-content wrapping with `<<<UNTRUSTED_CONTENT_DATA_ONLY>>>` guards in read mode, and SSRF-guarded GETs capped at 2 ESP redirect hops over allowlisted paths. That is genuinely useful behavioral context, though it does not cover rate limits or what the OTP/email payload looks like (the output schema carries that).

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?

The core action is front-loaded in the first clause and every sentence carries distinct information; nothing is redundant padding. The tradeoff is density — long nested parentheticals in a single sentence make it slower to parse than it needs to be, but no content is wasted.

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 an output schema present, return values need no explanation, and the description covers the remaining unknowns for a credentialed, network-touching tool: license requirement, inbox defaulting and mismatch failure, read vs. mutating modes, and network guardrails. An agent has everything needed to call it safely.

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 already defines both parameters; the description still adds meaning the schema does not carry, notably the domain-ownership precondition, the FORBIDDEN_INBOX error, and the redirect-hop/SSRF limits on `auto_verify: true`. It does not add syntax detail for the `<slug>` format, which is the only real gap.

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 names a specific verb+resource ('Retrieve inbound directory verification emails and 6-digit OTP codes from a domain-bound `<slug>@postbuild.dev` inbox') and immediately scopes the optional side effect ('optionally follow allowlisted confirmation links'). It also explicitly separates itself from postbuild_dispatch and postbuild_scan, so an agent can route correctly without opening any schema.

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?

Usage is stated positively ('Use this tool after submitting directory forms to complete email/OTP verification') and negatively with named alternatives ('do not use it to generate submission links (`postbuild_dispatch`) or to inspect initial domain readiness (`postbuild_scan`)'). The mode switch is also given a trigger: `auto_verify: false` for plain reads, `true` when confirmation links must be followed.

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

Deploy Server

Other Tools