Skip to main content
Glama

check_messages

Read messages other agents sent you. Optionally wait up to a specified time for a new message, returning immediately if none are pending.

Instructions

Read messages other agents have sent you, optionally waiting for one to arrive. The receive half of plumb's mailbox; leave_note is the send half.

With wait_seconds omitted or 0 it returns immediately with whatever is waiting. With a positive wait_seconds it BLOCKS until a message arrives or the wait expires — this is how you hand your turn to a peer after asking something, instead of polling. The wait is capped by [collab] max_wait_seconds, which is kept below the client's own call timeout.

Each message is delivered exactly ONCE, to whichever path sees it first — this tool, the block appended to an ordinary tool result, or session_start. Re-calling will not redeliver it, so act on a message when you read it.

Every message carries a conversation_id; quote it in leave_note to reply in thread. A THREAD is capped at [collab] max_exchanges. Note what that does and does not do: it bounds one conversation, and opening a new one starts a fresh budget. It is a speed bump that forces a deliberate act, not an enforced limit on how long two agents may talk — when a thread is spent, surface it to your human rather than routing around the cap.

Requires [collab] mailbox = true. Messages from a session in another workspace are shown only when this project sets [collab] cross_project = true, and are labelled with the sending project.

Parameters: wait_seconds — block up to this long for a message (default 0, no wait).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
wait_secondsNoBlock up to this many seconds waiting for a message. 0 (default) returns immediately. Capped by [collab] max_wait_seconds.
Behavior5/5

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

No annotations are present, so the description carries the full burden. It discloses blocking semantics with wait_seconds, exactly-once delivery, the per-conversation thread cap, configuration requirements ([collab] mailbox = true, cross_project), and the behavior across workspaces. This is comprehensive and goes far beyond what structured fields could convey.

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 sentence earns its place. It uses clear paragraph breaks and front-loads the primary purpose before diving into edge cases. There is no filler or repetition; all content is directly actionable for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is impressively complete: it covers delivery guarantees, thread semantics, config prerequisites, and cross-project behavior. The only gap is that it doesn't explicitly describe the return message structure (beyond conversation_id), but the description is otherwise rich enough for an agent to use the tool safely and effectively.

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 describes wait_seconds with 100% coverage, so the baseline is 3. The description adds meaningful context on top: the default of 0 (immediate return), the blocking behavior, and the cap by [collab] max_wait_seconds. This extra detail justifies a 4, though the schema already carries the core meaning.

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 opens with a clear, specific verb+resource: 'Read messages other agents have sent you, optionally waiting for one to arrive.' It explicitly distinguishes itself from leave_note by calling itself 'the receive half of plumb's mailbox' and naming leave_note as the send half, which disambiguates it from sibling tools.

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 description provides explicit when-to-use guidance: 'this is how you hand your turn to a peer after asking something, instead of polling.' It also gives a when-not-to-use warning ('Re-calling will not redeliver it, so act on a message when you read it') and behavioral advice about thread caps ('surface it to your human rather than routing around the cap'). Alternatives are named (leave_note).

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

Install Server

Other Tools

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/plumbkit/plumb'

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