Human for AI

Check a request for a human's answer

check_request_status

Read-onlyIdempotent

Read the thread on a request you or your principal filed earlier: whether a human has looked at it, and what they said.

Use the reference and access_token from request_human_assistance. Answers arrive at human speed — hours or days, not seconds — so poll this occasionally rather than in a loop, and treat an empty thread as "not yet", never as "no".

A reply is one human's view, recorded on request. It is not approval, not a retainer, and not authorisation to proceed.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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
`turns`	Yes	The whole thread, oldest first.
`notice`	Yes
`status`	Yes	`recorded` — filed, nobody has read it yet; `reviewed` — a human has read it but not answered; `answered` — there is a reply below; `declined` — the human will not take it on; `closed` — ended without an answer.
`reference`	Yes
`received_at`	Yes
`human_has_replied`	Yes

TDQS

A5/5.0

Behavior5/5

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

Annotations declare readOnly, openWorld, idempotent, non-destructive. The description adds critical behavioral nuance: polling frequency ('hours or days'), empty-thread semantics ('not yet' not 'no'), and the meaning of a reply (one human's view, not approval/authorization). This goes well beyond the annotations and provides essential operational context.

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 tight, three paragraphs each carrying distinct value: purpose, usage, and semantic caveat. No fluff, all sentences earn their place, and it is appropriately front-loaded with the primary function.

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 tool has an output schema, it need not describe return values. The description fully covers usage context, parameter sourcing, temporal behavior, edge cases (empty thread), and semantic meaning of replies. This is complete for a non‑destructive read tool with 2 parameters and strong annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for both parameters. The description adds cross-tool semantics by explicitly telling the agent to obtain these values from request_human_assistance and explaining why the access_token is necessary (references are guessable). This reinforces and extends the schema, making parameter selection unambiguous.

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 reads a thread to see if a human has responded and what they said. It distinguishes itself from siblings by focusing on status checking rather than replying (reply_to_thread) or creating a request (request_human_assistance), with a specific verb+resource+scope combination.

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: use the reference/access_token from request_human_assistance, poll occasionally rather than in a loop, and treat empty thread as 'not yet'. It establishes when to use this tool (after filing a request) and clarifies ambiguous outcomes, effectively differentiating from alternatives.

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?