Ask a human expert

Read my reply

get_reply

Read-only

My reply to a request you submitted, by the request_id submit_request returned (ask- followed by 24 letters, digits, - or _). status is 'waiting' until I've replied, with a note saying when to expect it, then 'replied' with the text, oldest first; later replies in the same thread are included. Check every few minutes, not in a tight loop: at most 120 checks per hour from one address. A malformed request_id is an error; a well-formed one I haven't answered yet is just 'waiting'. If you lost the request_id, use find_request; to reply to my answer, use send_followup. The same reply is also emailed to reply_email.

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": {
      "request_id": "<request_id>"
    },
    "name": "get_reply"
  }
}

Input Schema

Name	Required	Description	Default
`request_id`	Yes	The request_id submit_request (or find_request) returned, like ask-alWy4XCpgAW3eZUgwnRTCmQ2

Output Schema

Name	Required	Description	Default
`note`	No
`error`	No
`status`	No
`replies`	No
`request_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 26, 2026

changedInput schema / properties / request_id / description

Previous value: -"The request_id submit_request returned"New value: +"The request_id submit_request (or find_request) returned, like ask-alWy4XCpgAW3eZUgwnRTCmQ2"

addedInput schema / properties / request_id / pattern
```
Added value: +"^ask-[A-Za-z0-9_-]{24}$"
```

AddedOct 26, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: discloses the status lifecycle ('waiting' with an ETA note, then 'replied' with text, oldest first), thread behavior for later replies, a hard rate limit of 120 checks/hour per address, and that the same reply is also emailed to reply_email.

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 purpose and packed with useful detail, but the middle segment is a semicolon-chained run-on covering status, threading, rate limits, and error semantics in one block. Dense rather than wasteful, but could be split for scannability.

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?

An output schema exists, so return values needn't be spelled out, yet the description still conveys the two status states and pagination ordering ('oldest first'). Nothing an agent needs to call this correctly, including polling cadence, is missing.

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 pattern and example already document request_id. The description still adds value by explaining what a violation means operationally ('a malformed request_id is an error; a well-formed one I haven't answered yet is just waiting') and where the id comes 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?

States a specific verb and resource ('my reply to a request you submitted, by the request_id'), and names the exact origin of the identifier. It is clearly distinct from find_request (locating a lost id) and send_followup (replying back), both of which are named.

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?

Gives explicit routing: use find_request if the request_id is lost, send_followup to answer back, and poll 'every few minutes, not in a tight loop'. It also pre-empts the common failure mode by distinguishing malformed (error) from unanswered-but-valid ('waiting').

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

All Ask a human expert tools Inspect

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

Need Help?