MailGlass

wait_for_code

Wait for a message with an extracted code/link in an inbox (long-poll, no client polling). Broadcast semantics: multiple concurrent waiters all match the same arriving mail — coordinate multi-agent consumption separately. Mail held while the inbox is paused is matched too. First scans mail that arrived in the last 15 minutes (WAIT_HISTORY_WINDOW) — an already-arrived code returns immediately; otherwise parks until timeoutSec. fromMatch: "any" (default) matches the display From header or the SMTP envelope sender; "envelope" matches ONLY the envelope sender (unforgeable). Note for "envelope": ESP mail (e.g. SES) often uses a bounce address as the envelope sender, so filtering by the brand display domain will not match — use "any" unless you know the envelope domain.

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": {
      "inboxId": "<inboxId>"
    },
    "name": "wait_for_code"
  }
}

Input Schema

Name	Required	Description
`filter`	No
`inboxId`	Yes
`fromMatch`	No	any (default): match display From or envelope sender; envelope: only the SMTP envelope sender (unforgeable — recommended for brand-domain automation).
`timeoutSec`	No	Default 60, max 300.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the burden, and it does disclose a lot: blocking long-poll, broadcast fan-out to all waiters, matching of mail held during pause, the 15-minute WAIT_HISTORY_WINDOW rescan, and the park-until-timeout path. However, it never states what happens on timeout (null? error? empty result) or what the returned object contains, which is the biggest behavioral gap for a wait tool with no output schema.

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?

Information is front-loaded: wait semantics first, then fan-out caveats, then matching semantics, then the fromMatch warning. It is dense but every clause carries operational meaning; the only mild redundancy is repeating the fromMatch enum semantics already present in the schema.

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

Completeness3/5

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

For a tool with no annotations and no output schema, the definition covers invocation behavior thoroughly but leaves the caller unable to predict the success response shape or the timeout return, both of which an agent needs to handle results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%. The description enriches fromMatch well beyond the enum text by explaining ESP bounce-address behavior, which is genuinely additive. But the nested filter object (from/subject — exact match, substring, or regex?) is undocumented in both schema and description, and timeoutSec's default/max are only restated from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first clause states a specific verb and resource ('Wait for a message with an extracted code/link in an inbox') and names the mechanism (long-poll). This distinguishes it from list_messages/get_message, though it never contrasts with the closely related sibling await_verification, which an agent must also choose between.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Strong selection guidance for the fromMatch parameter ('use "any" unless you know the envelope domain') and clear framing that this is a blocking long-poll rather than client polling. The broadcast-semantics warning also tells the caller how to behave with concurrent agents. Missing: no explicit statement of when to prefer await_verification.

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

All MailGlass 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.

Resources

Need Help?