Skip to main content
Glama

get_messages

Retrieve messages from your agent mailbox, optionally peeking without marking them read. Filter by status, time window, and lane to review pending work or message history.

Instructions

Drain or peek your own mailbox.

When to use: each turn that should observe new mail; orchestrators that batch-poll many agents may prefer get_messages_summary (cheaper preview) or peek_inbox_version (counts only). For surveys that must NOT consume mail, set peek=true.

Behavior: returns messages addressed to you, ordered by priority then created_at newest-first. By default status='pending' returns un-read messages and atomically marks them read for THIS session (sessions are per-session_id; a fresh terminal re-sees previously-read messages, v2.0 final fix). Optional since ('1h' | '24h' | '7d' | ISO | 'all'); its DEFAULT DEPENDS ON STATUS: status='pending' defaults to 'all' (the action queue is never windowed unless you ask), history reads (all/history/read/resolved) default to '24h'. A pending read ALWAYS returns UNDELIVERED (never-drained) mail regardless of since (#198; 3.0.1). For a pending read total_pending is always the full, unwindowed queue, and when your since hid pending mail the response carries hidden_by_since: N. peek=true (v2.2.2) suppresses the read-MARK — the returned messages are not marked read for your session — but it is NOT side-effect-free: like any first view it stamps the observation cursor (seq). (Post-3.0.1 that observation no longer changes what a later drain returns.)

Returns: { messages: MessageRecord[], count, has_more, total_pending | total, hidden_by_since?, agent, filter, since, since_bound, acked?, resolved_count?, warning? }. since is the window actually applied (the status default when you gave none); since_bound is the ISO timestamp the relay filtered by (after resolving duration shorthands or 'session_start'). With ack=true on a pending drain, acked and resolved_count report what the database actually changed, never what was asked. If your agent has no current session (session_id NULL, e.g. after a token rotation), the drain still delivers and records the agent-level receipts (read_at, last_drain_at, resolves) and returns warning: { code: 'session_unbound', message }: unresolved mail comes back on the next drain until you re-register or resolve it.

Errors: AUTH_FAILED, VALIDATION (bad since format), RATE_LIMITED.

Input Schema

NameRequiredDescriptionDefault
ackNov2.12.0: when true, permanently resolve the returned messages (atomic with the read-mark) so a fresh session won't re-surface them. Only applies to status='pending'. Default false = unchanged behavior.
laneNoFilter by message lane: 'all' (default), 'direct' (point-to-point only), or 'capability' (capability-routed FYI only).all
peekNoWhen true, skip the mark-as-read side effect so repeated status='pending' polls return the same messages. Default false (consume-once).
limitNoMax messages to return
sinceNoTime-window filter. Accepts duration ('15m'|'1h'|'24h'|'3d'), ISO8601 timestamp, 'session_start' sentinel, or 'all'/null for no bound. DEFAULT DEPENDS ON STATUS: status='pending' defaults to 'all' (the action queue is never windowed unless you ask); history reads (all/history/read/resolved) default to '24h'. On a pending read the bound applies only to mail this recipient has already seen: never-drained mail is always returned. When a window hides pending mail, the response says so in `hidden_by_since`.
statusNoFilter by status. 'pending' (default) = unresolved + not-read-by-this-session (the action queue). 'read' = read by this session. 'all'/'history' = the full durable record incl. resolved. 'resolved' = only messages you've acked (v2.12.0).pending
agent_nameYesYour agent name
agent_tokenNoYour agent token (from register_agent response). Optional here — also resolvable from RELAY_AGENT_TOKEN env or X-Agent-Token header.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / properties / since / default
      Removed value: -"24h"
    • changedInput schema / properties / since / description
      Previous value: -"v2.1.6: time-window filter over ALREADY-OBSERVED history. Accepts duration ('15m'|'1h'|'24h'|'3d'), ISO8601 timestamp, 'session_start' sentinel, or 'all'/null to disable. Default '24h' trims stale backlog when an agent name is reused. #198: this bound applies ONLY to mail this recipient has already seen — a PENDING drain ALWAYS returns never-observed (undelivered) mail regardless of `since`, so undelivered mail can never age out of reach."New value: +"Time-window filter. Accepts duration ('15m'|'1h'|'24h'|'3d'), ISO8601 timestamp, 'session_start' sentinel, or 'all'/null for no bound. DEFAULT DEPENDS ON STATUS: status='pending' defaults to 'all' (the action queue is never windowed unless you ask); history reads (all/history/read/resolved) default to '24h'. On a pending read the bound applies only to mail this recipient has already seen: never-drained mail is always returned. When a window hides pending mail, the response says so in `hidden_by_since`."
  2. Changed1 schema field changedv3.0.1
    • changedInput schema / properties / since / description
      Previous value: -"v2.1.6: time-window filter. Accepts duration ('15m'|'1h'|'24h'|'3d'), ISO8601 timestamp, 'session_start' sentinel, or 'all'/null to disable. Default '24h' trims stale backlog when an agent name is reused."New value: +"v2.1.6: time-window filter over ALREADY-OBSERVED history. Accepts duration ('15m'|'1h'|'24h'|'3d'), ISO8601 timestamp, 'session_start' sentinel, or 'all'/null to disable. Default '24h' trims stale backlog when an agent name is reused. #198: this bound applies ONLY to mail this recipient has already seen — a PENDING drain ALWAYS returns never-observed (undelivered) mail regardless of `since`, so undelivered mail can never age out of reach."
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does: read-mark semantics per session, ordering by priority then recency, status-dependent `since` defaults, the guarantee that pending reads always return undeivered mail, and the non-obvious caveat that `peek` still stamps an observation cursor. It even discloses the unbound-session failure mode and its warning payload.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and organized under When to use / Behavior / Returns / Errors, but bloated with version tags and issue references ('v2.0 final fix', '#198; 3.0.1', '(v2.2.2)', 'Post-3.0.1') that add no decision-relevant value. Several sentences restate schema descriptions verbatim.

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 an 8-parameter tool with no output schema, the description supplies the response shape explicitly, names the error codes, and covers the awkward edge cases (session unbound after token rotation, window hiding pending mail). An agent has everything needed to call it correctly.

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 parameter bar is already met; the description nonetheless adds cross-parameter meaning the schema only partly states — e.g. that `ack` on a pending drain reports what the database actually changed, and why `total_pending` is unwindowed. Some of this (since defaults, hidden_by_since) duplicates schema text, keeping it below a 5.

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?

Opens with a specific verb+resource ('Drain or peek your own mailbox') and immediately distinguishes the two operating modes. The agent can tell this apart from get_messages_summary and peek_inbox_version without reading 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?

Gives an explicit trigger ('each turn that should observe new mail') and names two alternatives with the condition that selects them (cheaper preview vs counts only). It also states a when-not rule: 'For surveys that must NOT consume mail, set peek=true.'

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