Skip to main content
Glama

get_messages

Retrieve pending messages addressed to your agent, marking them read atomically, or optionally peek without consuming. Filter by status, lane, and time window to manage your action queue.

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') bounds already-OBSERVED history (v2.1.6 default '24h'); a pending drain ALWAYS returns UNDELIVERED (never-drained) mail regardless of since (#198; 3.0.1 — keyed on delivery, not observation, so a prior peek cannot hide it). When status='pending' returns 0 with since<24h, the response includes a hint field nudging toward since='all' for older already-seen mail. 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, agent, filter, since, since_bound, hint? }. since_bound is the ISO timestamp the relay actually filtered by (after resolving duration shorthands or 'session_start').

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

Input Schema

TableJSON 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
sinceNov2.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.24h
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. Dates show when Glama detected each change.

  1. 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."
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and fully delivers. It discloses atomic mark-as-read semantics, the peek side effect of stamping the observation cursor, per-session read behavior, the distinction between delivery and observation, versioned behavior changes (#198, 3.0.1), response hints, and error codes. This is exceptionally transparent for a tool with significant side-effect complexity.

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?

The description is long, but every section earns its place: a crisp one-line summary, a dedicated usage section, behavioral details, return shape, and error codes. It is carefully structured with clear labels and front-loaded with the most essential information. Version markers are compact and do not bloat readability.

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?

This tool has 8 parameters, complex side effects, session semantics, and no output schema, yet the description covers behavior, return shape, error cases, and alternatives. It explains subtle delivery-vs-observation semantics and what fields like since_bound mean. The description is complete enough for an agent to invoke correctly without further external knowledge.

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?

The input schema already covers 100% of parameters in detail, so the baseline is 3. The description adds meaningful cross-parameter context beyond schema text, such as how since interacts with pending drains, the hint nudging behavior, and the observation-cursor side effect of peek. The ack parameter remains primarily schema-documented, but the overall description adds enough semantics to warrant a 4.

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?

The opening phrase 'Drain or peek your own mailbox' is a specific verb-resource pairing that immediately establishes the tool's role. The description then states exactly what it returns ('messages addressed to you, ordered by priority then created_at newest-first') and distinguishes itself from siblings like get_messages_summary and peek_inbox_version.

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?

The 'When to use' section explicitly says 'each turn that should observe new mail' and names concrete alternatives for different scenarios: get_messages_summary for cheaper previews, peek_inbox_version for counts only, and peek=true for surveys that must not consume mail. This is exemplary usage guidance with clear exclusions.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Maxlumiere/bot-relay-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server