Skip to main content
Glama
colinhallett

message-cp

by colinhallett
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

ask

Sends a question to another agent and waits for its reply in one call, returning the response or null on timeout. Use it to get a direct answer without polling.

Instructions

Ask one agent a question and wait for its answer in one call: sends body to the agent to, as send_message does, and holds the call until that agent answers it with send_message and in_reply_to set to the question's id. Returns id (the question's message id) and reply: the earliest such reply, shaped as read_inbox returns a message and marked read, or null if none came within timeout_seconds or the call was cancelled. With reply null, a later answer arrives as an ordinary message: find it with read_inbox or read_conversation by its inReplyTo, the question's id; message_status with the id says only whether the question was read. It checks about once a second; a check that finds the database busy counts as no reply that time. To answer a question someone asks you, call send_message with in_reply_to set to the question's id, so that their ask sees it. 'all' and a person are refused, and nothing is sent. Calls held at once are capped together with wait_for_mail, over HTTP also with the server's GET /wait requests and over stdio for the whole process; past the cap it fails at once and sends nothing, so try again shortly. If your agent is removed while you wait, it fails as not registered. Requires register first.

Input Schema

NameRequiredDescriptionDefault
toYesThe agent to ask, by name. Not 'all' or a person.
bodyYesThe question, at most 4000 characters.
timeout_secondsNoHow long to wait for the reply, in seconds: default 50, at most 240.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: polling about once a second, a busy database counting as no reply, a concurrency cap shared with wait_for_mail and HTTP GET /wait requests, immediate failure past the cap with nothing sent, and failure as not registered if the agent is removed. It also discloses that the returned reply is marked read and that null means the call timed out or was cancelled.

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 core purpose and return value are front-loaded, and every paragraph addresses a distinct concern: sending, return shape, late replies, answering others, refusals, concurrency cap, and registration. Some sentences are dense run-ons, but little could be removed without losing behavioral detail that annotations would otherwise carry.

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?

There is no output schema, so the description correctly explains the return shape: id, reply shaped as read_inbox returns a message and marked read, or null. It also covers timeout, late-reply recovery, refusal, concurrency, and registration edge cases, leaving nothing an agent needs to call it correctly.

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 baseline is 3, but the description adds real meaning beyond the schema: timeout_seconds determines when reply comes back null, and 'to' is constrained to an agent name rather than 'all' or a person. The body's 4000-character limit is already in the schema, so some parameter detail is redundant.

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 first sentence states a specific verb and resource: ask one agent a question and wait for its answer in one call. It explicitly relates the send behavior to send_message and the reply to in_reply_to, so the agent can distinguish it from send_message and wait_for_mail without opening another schema.

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 gives explicit routing: answer someone else's question with send_message and in_reply_to set, and if reply is null, find the late answer with read_inbox or read_conversation by inReplyTo. It also states when the tool is refused ('all' or a person), the registration prerequisite, and retry behavior when the concurrency cap is hit.

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