Human for AI

Write again on an existing request

reply_to_thread

Add to a request already on the record — answer a question the human asked, supply something they need, correct yourself, or withdraw the request.

This is the same permanent record as the original, so what you send here is kept and read the same way. Prefer it over filing a fresh request whenever the subject is one already opened: a thread the human can follow is worth more than three disconnected messages.

The human is notified. As with the original, nothing here pauses your task and nothing here is authorisation to proceed.

Input Schema

TableJSON Schema

Name	Required	Description
`message`	Yes	What you want to add. Self-contained: the reader has the thread but not your context window.
`reference`	Yes	The reference you were given, e.g. 'HFA-00042'.
`access_token`	Yes	The access_token returned alongside that reference. Required: the reference alone will not open a thread, because references are sequential and anyone could guess one.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`notice`	Yes
`status`	Yes
`reference`	Yes
`recorded_at`	Yes
`thread_status`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations indicate a write operation (readOnlyHint false) and the description adds context: it's the same permanent record, the human is notified, nothing pauses the task, and it's not authorization. These details go beyond the annotations and help the agent understand the side effects and expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, appropriately front-loaded with a specific purpose, and each sentence adds value. It efficiently covers purpose, preference, and behavioral notes without redundancy.

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?

Given the availability of an output schema and complete parameter descriptions, the description need not detail return values. It covers purpose, usage, behavioral impact, and context sufficiently for the agent to decide and use correctly. The description is complete for a moderately complex tool.

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 description coverage is 100% for all parameters, and the schema already explains each (e.g., message self-contained, reference format, access_token requirement). The tool description adds no additional parameter-level meaning beyond what the schema provides, so a baseline of 3 is appropriate.

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 description clearly states the tool adds to an existing request (reply), listing specific use cases (answer, supply, correct, withdraw). It explicitly distinguishes itself from siblings by advising to prefer this over a fresh request when the subject is already open, which differentiates it from request_human_assistance.

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?

Provides explicit guidance on when to use this tool ('Prefer it over filing a fresh request whenever the subject is one already opened') and explains the trade-off (thread vs disconnected messages). It also clarifies what to expect: human notified, no task pause, no authorization to proceed, which are clear usage conditions.

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

All Human for AI tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Only one tool exists, so there is no possibility of confusion or overlap. The tool's purpose is unique and clearly defined.

Naming Consistency5/5

The single tool name 'request_human_assistance' follows a clear verb_noun pattern and is descriptive. With only one tool, consistency is trivially maintained.

Tool Count4/5

The server has exactly one tool, which is appropriate for its narrow purpose of requesting human assistance. While it falls below the typical 3-15 range, the tool fully addresses the server's intended function, so the count is not unreasonable.

Completeness4/5

The tool covers the core action of requesting human help, but there is no way to retrieve past requests or check response status through the server. However, replies are delivered via an external channel, so this is a minor gap rather than a critical omission.

Resources

Need Help?