Skip to main content
Glama
Sign In
magents

magents

by abnegate
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

await_reply

Wait for new inbox mail, optionally from a specific session, and return pending status if no reply arrives within the timeout (default 5s, max 30s).

Instructions

Wait briefly for new inbox mail, optionally from one session. Returns pending if none arrives. Default timeout 5s, max 30s.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "await_reply"
  }
}

Input Schema

NameRequiredDescriptionDefault
fromNoSession that should reply (`agent:ref`)
agentNo
session_idNo
timeout_secsNoSeconds to wait (default 5, max 30)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden and does a solid job: it declares a blocking wait, the pending outcome, the default timeout of 5s, and the max of 30s. It does not describe the success return payload or edge-case behavior, but the core behavior is transparent.

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?

Two sentences, front-loaded with the primary action and scoping, followed by key behavioral facts about pending results and timeouts. There is no filler or redundant repetition of schema fields.

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

Completeness3/5

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

For a four-optional-parameter tool with no output schema, the description covers the timeout and pending condition but leaves parameter semantics incomplete and does not clarify the success return shape. It is adequate for simple use but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50%, with agent and session_id left undocumented. The description merely echoes 'from one session' and the timeout defaults, adding no meaning for the two unexplained parameters or clarifying how agent/session_id relate to from.

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 uses a clear verb-resource pair ('Wait briefly for new inbox mail') and specifies the optional session scoping, which helps distinguish it from siblings like send_message or inbox. The mention of 'Returns pending if none arrives' further clarifies the tool's purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: when waiting for new inbox mail with a timeout. It does not explicitly explain when not to use it or point to alternatives such as inbox for non-blocking checks, so the guidance is present but not fully explicit.

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

Deploy Server

Other Tools