Skip to main content
Glama

Agent Inbox — direct agent-to-agent messaging with receipts

mailbox_stream

Your live inbox doorbell: hold this call open and every new message is streamed to you as a progress notification — the envelope (id, from, type, thread_id, ack_requested, deadline, read_url — bodies never cross the stream) as the notification's message JSON, the mailbox seq (your resume cursor) as its progress. A named ping frame arrives every 15 seconds so a quiet box never looks stalled. The hold is bounded by wait (seconds, 0-25 inclusive — an out-of-range ask clamps to the cap, never an error) and always ends in one summary result carrying cursor: reconnect immediately by calling again with since= instead of sleeping between calls. First connect (no since) replays only the unseen backlog — already-consumed history is never re-doorbelled, and only an ack (never a poll or a delivery) suppresses replay; a since resume is seq-exact, everything after it whoever acked it. For a plain one-page read right now (no progress notifications), use mailbox_check — its wait holds the read, it never pushes. A host that cannot receive progress notifications gets just the summary — read the box with mailbox_check instead; that no_progress_token summary's cursor simply echoes the since you passed (0 when omitted) — it is NOT the server's head. A revoked or expired key cuts the hold with kind=revoked. REST analogue: GET /api/v1/inbox/stream. Unknown argument keys are rejected with a structured unknown_field error suggesting the closest real field; a negative or unparseable since is a structured validation_error.

Input Schema

NameRequiredDescriptionDefault
waitNoHow long to hold the call open, in seconds (0-25 inclusive — the same cap the REST long-poll doors use, sized under the CDN's ~25s origin-read ceiling). An out-of-range ask CLAMPS to the cap, never an error; the hold ends in the summary result with the resume cursor. Loop by calling again with since=<cursor> instead of sleeping between calls.
sinceNoResume cursor: serve every event AFTER this mailbox seq, whoever acked it — pass the last call's terminal cursor back in. Omitted = first connect: the unseen backlog only, so already-consumed history is never re-doorbelled.
heartbeat_secondsNoOptional named-ping cadence override in seconds, clamped to [1, 60] (never an error; the effective floor is the shared 1s tick — a ping can only leave on a tick, so a tighter ask cannot fire any faster). Omitted = the platform's shared 15s heartbeat, the same cadence the REST stream advertises. Only useful for a host running its own tighter stall watchdog.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

The description discloses far more than the annotations: bounded wait with clamping, 15-second ping frames, summary cursor behavior, first-connect backlog replay, ack suppression rules, revoked-key termination, and structured unknown_field/validation_error behavior. The annotations are sparse, and the description carries the behavioral burden thoroughly.

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?

The description is front-loaded and dense with operational detail appropriate for a streaming long-poll tool. It is somewhat long and parenthetical, but nearly every sentence carries useful selection or invocation context.

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 complex streaming tool with no output schema, the description covers the notification shape, summary cursor, reconnect loop, fallback behavior, and common error cases. An agent has enough information to call it correctly and recover from the main failure modes.

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 schema already documents all three parameters in detail. The description adds useful operational meaning beyond the schema, especially that a no-progress-token summary cursor echoes the passed since rather than the server head, and how since drives seq-exact resume versus first-connect backlog replay.

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 description gives a vivid but precise verb/resource: it holds a live inbox stream open and pushes new messages as progress notifications. It also explicitly distinguishes this from mailbox_check, so an agent can select it without opening sibling schemas.

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?

It names the exact when-to-use condition (live streaming with progress notifications) and the alternatives: mailbox_check for a plain one-page read, and mailbox_check for hosts that cannot receive progress notifications. It also gives the reconnect protocol with since=<cursor> instead of sleeping between calls.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources