Skip to main content
Glama
Sign In

AgentX

by com.agentxhq
OverviewDiscussionsAdmin

wait

Read-onlyIdempotent

Pause until one of the user's agents does something in a chat you name — sends a message or finishes what it was doing — then return that event.

Pass chat (from create_chat or list_chats). The server never invents a chat for wait.

You rarely need this: set wait on send_message when you want the reply from an agent you just messaged. Reach for wait when you are expecting something from an agent you did not just message. Coming back after 110 seconds with nothing is normal and is not an error.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "chat": "<chat>"
    },
    "name": "wait"
  }
}

Input Schema

NameRequiredDescriptionDefault
chatYesChat id to wait on (the `bubble_id` from `create_chat` or `list_chats`). Required.
tailNoSame as lines. tail wins when both are set.
linesNoHow much transcript to attach if the wait times out, counted in messages. Defaults to the last one.
jitterNoExtra random seconds on top of timeout. The total never exceeds 110.
timeoutNoHow long to wait, in seconds. Defaults to 110. Use 0 to return without blocking. Anything above 110 is treated as 110.
verboseNoInclude extra diagnostic detail. Leave off unless you are debugging.
output_formatNoLeave empty to read the agent's conversation. Set screen for its raw terminal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent, so the description focuses on what structured fields can't say: an empty return after 110 seconds is normal, not an error, and the server never fabricates a chat. It doesn't describe the shape of a successful event versus a timeout payload, which leaves a modest gap.

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?

Front-loaded with the core behavior, then use-case guidance, then the timeout caveat. Slightly repetitive about where `chat` originates, but no sentence is wasted.

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?

No output schema exists, so the description carries the burden of explaining what comes back; it says an event is returned and that timeouts yield a transcript tail, but doesn't fully characterize the response. For a 7-param tool with full schema coverage, this is close to complete.

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

Parameters3/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 chat, tail, lines, jitter, timeout, verbose, and output_format. The description only reinforces where `chat` comes from (create_chat/list_chats), adding little beyond the schema's own text.

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?

States a specific verb and resource: pause until an agent sends a message or finishes, then return that event. This clearly distinguishes it from send_message's inline `wait` parameter, which the description also names.

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?

Explicitly says when NOT to use it ('You rarely need this: set `wait` on `send_message`...') and when to reach for it ('when you are expecting something from an agent you did not just message'). That is a rare, precise routing rule.

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

All AgentX toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources