A
licenseNot graded
qualityC
maintenancePauses AI agent execution and routes approval requests to humans via Slack or email, with cryptographically signed proof of the human's decision.
25 npm
MIT
Human for AI
by ai.yourhuman
Server Details
Ask a human for legal review, confirmation, a signature, or a physical-world act
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 38 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.7/5.0
Scored across 3 tools
Disambiguation5/5
Each tool has a distinct role in the same workflow: request_human_assistance creates a request, check_request_status reads its status, and reply_to_thread adds to an existing request. There is no overlap or ambiguity between them.
Naming Consistency5/5
All tool names follow a clear verb-first snake_case pattern and clearly express their action: check, reply, request. The naming is consistent and predictable.
Tool Count5/5
Three tools is exactly right for this server's narrow purpose: enabling asynchronous human assistance through request, status check, and reply. Each tool is necessary and none are redundant.
Completeness5/5
The tool set covers the full lifecycle for the stated domain: file a request, check for a human response, and continue or withdraw the thread. No obvious gaps exist for asynchronous human-in-the-loop assistance.
Available Tools
3 toolscheck_request_statusCheck a request for a human's answerARead-onlyIdempotentInspect
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.
ParametersJSON 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
ParametersJSON 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.
reply_to_threadWrite again on an existing requestAInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| 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.
request_human_assistanceRequest human assistanceAInspect
Ask an actual human being for help with something your task requires and you cannot properly do alone: legal judgement, a decision you should not take on your own authority, an act in the physical world, or an escalation past your operator.
The request is written to a permanent, timestamped record and read by a human — a lawyer — who may reply through whatever channel you put in reply_to.
This returns a reference and an access_token. Keep both: together they are the only way to read the human's answer, via check_request_status. Neither can be recovered afterwards, and they are not returned twice. If your task may outlive this session, hand them to whatever continues it.
Calling this tool does not pause your task, and the result it returns is not approval, legal advice, or authorisation to proceed. It is evidence that you asked. If the right thing to do is to stop and wait for a human, stop and wait.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Your underlying model, e.g. 'claude-opus-5'. | |
| context | No | Background the human needs to answer: the task you are carrying out, who it is for, what you have already done, and the relevant facts or documents. | |
| request | Yes | What you are asking the human to do. Be specific and self-contained: the reader has no access to your context window, your tools, or your conversation. | |
| urgency | No | `routine` — no deadline; `soon` — a human answer is needed within days; `blocking` — you have halted your task and cannot continue without a human. | routine |
| category | Yes | Which kind of human intervention you need. `legal_review`: a human lawyer should read this before you act — contracts, terms, licences, liability, regulatory exposure, or anything where being wrong has legal consequences for your principal. `human_confirmation`: you want a person to see and confirm a decision before you commit to it — irreversible, costly, or outside what you were plainly asked to do. `physical_action`: the task needs a body or a legal person in the physical world — a signature, notarisation, filing paper at a courthouse, posting mail, attending somewhere in person. `operator_escalation`: your operator or principal is unreachable, has instructed you to do something you should not do, or the task has drifted outside what they authorised, and you want an independent human on the record. | |
| deadline | No | When an answer stops being useful, as a date or plain description. Optional. | |
| operator | No | Who runs you, or on whose behalf you are acting. Name the principal if you can — it determines who the human would be advising. | |
| reply_to | No | An email address, URL, webhook, or any other channel where a reply can reach you or your principal. Without this the human can record your request but cannot answer it. | |
| agent_name | No | What you call yourself. | |
| proposed_action | No | The specific action you are contemplating, if any, stated as you would carry it out. Include this whenever you are asking whether to proceed — it is the part that matters most on the record. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| notice | Yes | |
| status | Yes | |
| category | Yes | |
| reference | Yes | Quote this in any later correspondence. |
| thread_url | Yes | The same thread over plain HTTP, for anything that can fetch a URL but not call this server. GET it for JSON. |
| received_at | Yes | |
| access_token | Yes | Secret. Pass with the reference to `check_request_status` to read the answer. Not recoverable and not shown again. |
| human_has_reviewed | Yes | Always false at this point. A human reads the record afterwards, at human speed. |
| reply_expected_via | Yes | The channel you supplied, or null if you gave none. |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical side-effects beyond the annotations: the request persists permanently, the tokens are single-return, and the call does not pause the task. It also clarifies that the response is not approval or legal advice, which is essential for an agent to manage expectations. This goes well beyond the readOnlyHint=false and openWorldHint=true annotations, with no contradiction.
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?
The description is front-loaded with the core purpose and then explains important nuances. It is somewhat long (four paragraphs) but each sentence carries weight, covering the record, token retrieval, and non-blocking nature. It is not overly wordy for the complexity of the tool, though it could be tightened slightly.
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?
The description is contextually complete: it explains the mechanism (permanent record, human lawyer, reply_to channel), the result (token pair), the limitation (not approval), and the action to take (stop and wait if appropriate). It also references the sibling check_request_status for retrieving the answer. No gaps remain for a first-time caller.
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?
Since the schema already has detailed descriptions for all 10 parameters (100% coverage), the description adds minimal extra meaning. It does provide contextual guidance on reply_to channel and emphasizes that request should be self-contained, but these are not essential additions. Given the high schema coverage, the tool description meets but does not exceed the baseline.
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's purpose: asking a human for help in specific situations (legal review, decisions beyond authority, physical acts, escalation). It distinguishes itself from sibling tools like check_request_status by describing the act of making the request, not retrieving it. The verb 'ask' plus the detailed categories make the intent unmistakable.
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?
It gives explicit guidance on when to use the tool by listing four categories of situations (legal, decision-making, physical, escalation). It also implies when not to continue (stop and wait) and mentions the reference to check_request_status for retrieving the answerate. However, it does not explicitly name alternative tools or contrast with reply_to_thread, relying on the reader to infer the division of labor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- Added
check_request_status - Added
reply_to_thread - Changed
request_human_assistance3 fields changed- added
Output schema / properties / access_tokenAdded value: +{ + "description": "Secret. Pass with the reference to `check_request_status` to read the answer. Not recoverable and not shown again.", + "type": "string" +} - added
Output schema / properties / thread_urlAdded value: +{ + "description": "The same thread over plain HTTP, for anything that can fetch a URL but not call this server. GET it for JSON.", + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "reference", - "status", - "category", - "received_at", - "human_has_reviewed", - "reply_expected_via", - "notice" -]New value: +[ + "reference", + "access_token", + "thread_url", + "status", + "category", + "received_at", + "human_has_reviewed", + "reply_expected_via", + "notice" +]
1 tool update
- First observed
request_human_assistance
Related MCP Connectors
Give any AI agent a way to ask a person — for approval, a decision, an answer or a review.
Get a real human to verify, decide, or improve an AI agent's work.
Human-owned review for agent plans, rendered documents, Forms, research, and live previews.
Human-in-the-loop approval for agent actions, with verifiable action-bound receipts.
Related MCP Servers
@quirna/mcpofficial
AlicenseNot gradedqualityCmaintenanceEnables AI agents to request human approval before consequential actions, with policy-based routing, phone-based approver decisions, and signed audit evidence.MIT- AlicenseNot gradedqualityCmaintenanceEnables judicial AI workflows to add a traceable human-oversight layer that assesses material impact, verifies legal sources, manages incidents, and preserves integrity evidence before closing resolutions.MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to request human approvals with customizable forms, webhooks, and team features.38 npmMIT
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.