Ask a human expert

Follow up on a request

send_followup

Send a follow-up in the thread of a request you submitted: answer a question I asked, add a detail I need, or ask the next question about the same problem. No new payment. Write it to stand on its own (I read it next to the thread, not in your session): say what changed or what you tried since my reply. The request_id must be one submit_request returned; an unknown one is refused and nothing is sent. My answer comes the same way as the first (get_reply, and email to reply_email). 300 words at most; at most 10 follow-ups per hour from one address. A new problem is a new request (submit_request).

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>",
      "message": "<message>"
    },
    "name": "send_followup"
  }
}

Input Schema

Name	Required	Description	Default
`message`	Yes	Your follow-up, as plain text: an answer to my question, a clarification or a next question, written to stand on its own, 300 words or fewer
`request_id`	Yes	The request_id submit_request (or find_request) returned, like ask-alWy4XCpgAW3eZUgwnRTCmQ2

Output Schema

Name	Required	Description	Default
`note`	No
`sent`	Yes
`error`	No
`request_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 26, 2026

changedInput schema / properties / message / description

Previous value: -"Your follow-up: an answer to my question, a clarification or a next question, 300 words or fewer"New value: +"Your follow-up, as plain text: an answer to my question, a clarification or a next question, written to stand on its own, 300 words or fewer"

addedInput schema / properties / message / minLength
```
Added value: +1
```

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.4/5.0

Behavior3/5

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

Annotations already declare the operation non-read-only, non-idempotent, non-destructive and open-world; the description adds genuinely new context on top: no new payment is triggered, an unknown request_id is refused with nothing sent, a 300-word cap, and a rate limit of 10 follow-ups per hour per address. Those are real extras, though the refusal path and rate-limit behavior are stated only in passing rather than as structured constraints.

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 action and closed with the routing rule, and nearly every clause carries information (payment, word cap, rate limit). It is dense and parenthetical-heavy in the middle, which makes it slightly harder to scan than it needs to be.

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?

Output schema exists, so return shape needn't be explained, and the description still covers the reply channel. For a 2-parameter write tool it covers scope, constraints, failure mode, and the alternative path — nothing an agent needs to call it correctly 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 baseline is 3; the description earns extra by constraining request_id provenance ('must be one submit_request returned; an unknown one is refused') and by stating why message must be self-contained — the reader sees it beside the thread, not inside the agent session. It does not restate the pattern or length syntax, but that is already in the schema.

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 (send a follow-up in the thread of a submitted request) and enumerates the three legitimate intents: answer a question, add a detail, ask the next question. It explicitly distinguishes itself from submit_request ('A new problem is a new request'), so an agent can route without opening a sibling 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?

Gives explicit when-to-use conditions plus the exclusion and the named alternative: new problem → submit_request. It also names where the answer will arrive (get_reply, reply_email), which tells the agent what not to poll for.

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?