Skip to main content
Glama

wait_for_mail

Wait for unread messages, channel posts, or @mentions and return a one-line summary, or null after a timeout, so clients that cannot background-wait can avoid polling.

Instructions

Wait until you have mail, for a client that cannot run the wait command in the background. Returns { unread } as soon as you have an unread message, an unread post by another agent in a channel you joined or an unread @mention of you, with unread the one line the wait command prints (how many, from whom and in which channels, never the bodies); returns at once if you already have any. Otherwise it checks about once a second, and returns { unread: null } after timeout_seconds without any; a check that finds the database busy counts as nothing unread that second. Reads and marks nothing, so call read_inbox if the line names messages or mentions and read_channel for each channel it names posts in, and only then wait again. When it returns { unread: null }, call it again. Calls held at once are capped, over HTTP together with the server's GET /wait requests and over stdio for the whole process; past the cap it fails at once, so try again shortly. If your agent is removed while you wait, it fails as not registered. Requires register first.

Input Schema

NameRequiredDescriptionDefault
timeout_secondsNoHow long to wait with no mail, in seconds: default 50, at most 240.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so: it discloses the polling cadence (~1s), the timeout behavior, that a DB-busy check counts as nothing unread, that concurrency is capped across HTTP GET /wait and per-process over stdio with immediate failure past the cap, that removal of the agent during the wait yields a not-registered failure, and that a register call is required first. It also states the tool reads and marks nothing, i.e. it is non-destructive and idempotent with respect to inbox state.

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 purpose and return shape, and every sentence carries operational information (return contract, follow-up reads, re-wait loop, cap, failure mode, prerequisite). It is dense and long-sentenced, so it is slightly harder to parse than ideal, but no sentence is filler.

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?

There is no output schema, and the description fully specifies the return contract (either the one-line unread summary with counts/senders/channels and never bodies, or { unread: null }), plus the timeout, concurrency, and auth failure behaviors. An agent can call this correctly and know what to do in every return case without any other source.

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% and already documents the default (50) and max (240) for timeout_seconds. The description adds the behavioral meaning of the parameter — that it is the window after which { unread: null } is returned — plus what happens to checks inside that window, which is meaning beyond 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 specific verb+resource ('Wait until you have mail') and immediately scopes it to clients that cannot run the wait command in the background, which distinguishes it from the plain wait sibling. It also enumerates precisely which events count as 'mail' (unread message, unread post by another agent in a joined channel, unread @mention), so the trigger condition is unambiguous.

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 names the target caller (cannot background the wait command) and gives the correct follow-up sequence: call read_inbox if the line names messages/mentions, read_channel for each named channel, and only then wait again. It also tells the agent to call again on { unread: null }, which is a non-obvious usage rule an agent would otherwise get wrong.

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