Inbin agent email

await_trial_inbox

Read-only

Wait for the verification code or confirmation link email on a trial inbox: block (up to ttl_seconds, max 60) for the one confirmation email on a trial inbox created by create_trial_inbox. Pass the exact inbox_address that call returned. The inbox does NOT self-delete or become unusable after a match: it keeps receiving mail and can still be claimed afterward (call claim_trial_inbox any time before it expires) if the human wants to keep using the same address. Call this AFTER you have actually used the address somewhere (signed up, requested a code) -- calling it before that will just expire, since there is nothing to wait for yet. 60 seconds is a hard per-call ceiling, not the inbox's total lifetime: a sender that takes longer than that is not a failure, just call this again with the same inbox_address to keep waiting (the inbox stays valid for its full ~2-week expiry, and you can call this again later too, e.g. to catch a second, later email on the same address). Only treat expired as final once you've retried a few times.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "inbox_address": "<inbox_address>"
    },
    "name": "await_trial_inbox"
  }
}

Input Schema

Name	Required	Description
`ttl_seconds`	No	How long to block waiting for the confirmation, in seconds (max 60). Returns expired if nothing arrives in time.
`inbox_address`	Yes	The exact address create_trial_inbox returned, e.g. abc123@in.inbin.dev.
`expected_sender`	No	Glob on the sender address, e.g. *@vercel.com.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

ReadOnlyHint already covers safety, yet the description adds substantial non-obvious behavior: the inbox does NOT self-delete or become unusable after a match, it keeps receiving mail and remains claimable, the 60s limit is a per-call ceiling rather than the inbox lifetime, and the inbox lives ~2 weeks. These are exactly the facts an agent would otherwise get wrong.

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?

Front-loaded with the core verb and resource, then ordered into scope, sequencing, and retry guidance. It is wordy and restates the 60-second ceiling twice (once for the per-call limit, once for '60 seconds is a hard per-call ceiling'), which could be tightened without losing meaning.

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?

No output schema exists, and the description notes the 'expired' outcome but never says what a successful match returns (code text, link, subject?) — a real gap for the tool's primary payload. Everything else an agent needs to call it correctly, including retry and lifetime semantics, is present.

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. The description still adds value by stressing that inbox_address must be the exact value returned by create_trial_inbox and by clarifying that 60s is a hard per-call ceiling, not the inbox's lifetime. It says nothing about expected_sender, leaving that param to the schema alone.

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?

Specific verb + resource: 'block (up to ttl_seconds, max 60) for the one confirmation email on a trial inbox created by create_trial_inbox.' It also names create_trial_inbox as the producer of the address and claim_trial_inbox as the follow-on, so an agent can place it among siblings without opening schemas.

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?

Explicit when-to-use (only AFTER actually using the address somewhere), when-not ('calling it before that will just expire'), and retry policy ('call this again with the same inbox_address', 'only treat expired as final once you've retried a few times'). The only gap is that the near-twin sibling await_trial_inbox_claim is never mentioned or contrasted.

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

All Inbin agent email tools Inspect

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.