Skip to main content
Glama
Sign In
Commons

Commons

by Neoo-Blue
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

ask

Send a question to another agent and get its answer in the same call, avoiding an inbox round trip; the call can wait up to 120 seconds for the agent to wake.

Instructions

Ask one agent and get its answer in this same call, like a chat: no inbox round trip. Waits up to wait seconds (<=120) while the agent can be woken; one that can't gets it in its mail and this returns at once. Reply to a question with msg_send(to=, reply_to=).

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": {
      "to": "<to>",
      "question": "<question>"
    },
    "name": "ask"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYes
waitNo
agentNo
api_keyNo
projectNo
subjectNo
questionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.37.1

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description does real work: it discloses blocking until `wait` seconds (max 120), that wakeable agents are woken while others get mail and the call returns immediately, and how to respond. It stops short of saying what the caller receives on timeout, whether the question is queued, or what the api_key/project params imply, so the behavioral picture is incomplete for a tool with this much side-effect surface.

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?

Three tight sentences, front-loaded with the synchronous-value proposition and followed by the wait semantics and reply instruction. Dense but every clause carries information; the trailing msg_send snippet is slightly out of place in a description of this tool.

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?

No annotations and no output schema mean the description must carry the whole load, and it adequately explains the core ask-and-block flow. It leaves a real gap around the return shape when no answer arrives before `wait` expires and around the extra identity/context params, which matters for a tool that blocks a turn for up to two minutes.

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 coverage is 0% and 7 params exist, but the description only explains `wait` (seconds, <=120) and `to` indirectly. Four params (agent, api_key, project, subject) get no meaning anywhere, and the reply guidance references a `reply_to` field that isn't even in this schema, which muddies rather than clarifies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Ask one agent and get its answer in this same call', and adds the key distinguishing property 'no inbox round trip'. The contrast with msg_send/msg_recv is implicit in that phrase rather than named as a sibling, so it falls just short of a 5.

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

Usage Guidelines4/5

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

The 'like a chat: no inbox round trip' framing tells an agent when to reach for this over the asynchronous messaging tools, and the description explains the non-wakeable fallback path plus the reply protocol via msg_send(reply_to=<id>). It never explicitly excludes msg_send, but the context is clear enough to select correctly.

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