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.
52
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
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
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.
EU AI Act Art-14 runtime oversight: allow / flag / gate-to-human on an agent action, with receipt.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to request human approvals with customizable forms, webhooks, and team features.69MIT
- AlicenseAqualityBmaintenanceEnables AI agents to safely execute privileged commands by routing them to a human approver, who runs them outside the agent's context and returns the output to the model.5MIT
- AlicenseAqualityDmaintenanceHuman-in-the-loop approval gate for AI agents. Your agent calls submit_approval before any irreversible action; a human reviews on a branded page; a signed webhook fires back with the decision.11MIT
Try in Browser
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.