Skip to main content
Glama

wait_for_link

Read-only

Blocks until a magic link email arrives in the inbox, then returns the link text, sender, and subject. Use it for signup or login flows that email clickable links instead of numeric codes.

Instructions

Block (bounded) until a magic link arrives in inbox_id and return it.

Use this instead of ``wait_for_otp`` when the target flow emails a
clickable magic link rather than a numeric/alphanumeric code. The link is
returned as text, NOT followed by this tool — fetch it yourself (e.g. via
a headless browser or ``curl``) however your task needs.

``timeout`` is requested in seconds but always clamped to [1, max], where
max is 120 for the local stdio server and 55 for the remote HTTP server:
this is the requested overall wait deadline the SDK aims for, not a hard
wall-clock ceiling — the underlying HTTP transport adds a small amount of
socket-level overhead on top of the clamped deadline, so the call can
return slightly after the ceiling in practice. On a timeout just call it
again.

``since`` (optional) only matches messages that arrived after this point:
an ISO8601 timestamp, unix seconds, or a message id (``msg_...``, meaning
"only messages after that one"; an unknown id falls back to the oldest
message, so prefer a timestamp if unsure). Omitted (the default), the
server matches only messages that arrive during this call — the right
choice for a fresh inbox from ``create_inbox``. When REUSING an inbox for
a second link and you want to catch one that already arrived before this
call, pass either the time just before you triggered this email, or the
``id`` of the last message you saw, so you get the NEW link instead of
missing it.

Side effects: none beyond the long-poll HTTP call(s) needed to satisfy the
wait (``openWorldHint`` — it talks to the live mailsocket API and blocks
for up to ``timeout`` seconds). Returns the magic link, the subject/from
of the matching message, and its ``id`` / ``received_at`` (chain
``since=<id>`` into the next call on this inbox). Raises a clean tool
error (``WaitTimeout``) if no link arrives before the deadline.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sinceNo
timeoutNo
inbox_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds substantial behavioral context: the call blocks on a long-poll HTTP request, `timeout` is clamped to a server-specific max (120 local, 55 remote) with possible socket overhead beyond the ceiling, no side effects beyond the poll, and a clean WaitTimeout error on deadline. This goes well beyond what annotations provide.

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?

Despite its length, every paragraph is front-loaded and earns its place: purpose and sibling routing first, then the returned value and non-following caveat, then timeout clamping details, then since semantics, then side effects/error behavior. No filler or repetition.

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?

For a blocking, long-polling tool with no output schema and no schema-level parameter descriptions, the description fills all critical gaps: return shape (link, subject/from, id, received_at), chaining pattern (since=<id>), timeout behavior, error condition, and side-effect clarity. Nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must carry parameter meaning — and it does. It explains `since` in depth (ISO8601, unix seconds, msg_... id, fallback behavior for unknown ids, and the crucial default of matching only messages arriving during this call), clarifies `timeout` semantics (requested seconds, clamped, not a hard wall-clock ceiling), and implies `inbox_id` from the first sentence.

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 specific verb (block/return) and resource (magic link in inbox_id), and immediately names the sibling it replaces (wait_for_otp) with the exact condition (clickable link vs numeric/alphanumeric code). An agent can confidently select this tool 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?

Explicitly says when to use this instead of wait_for_otp, and gives detailed when-to-use guidance for the `since` parameter (fresh inbox vs reusing an inbox). Also clarifies that the link is returned as text and must be fetched separately, and that on timeout the caller should just call again.

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