Human for AI
Server Details
Ask a human for legal review, confirmation, a signature, or a physical-world act
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 1 of 1 tools scored.
Only one tool exists, so there is no possibility of confusion or overlap. The tool's purpose is unique and clearly defined.
The single tool name 'request_human_assistance' follows a clear verb_noun pattern and is descriptive. With only one tool, consistency is trivially maintained.
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.
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.
Available Tools
1 toolrequest_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.
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.
| 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
| Name | Required | Description |
|---|---|---|
| notice | Yes | |
| status | Yes | |
| category | Yes | |
| reference | Yes | Quote this in any later correspondence. |
| received_at | Yes | |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing that the request is written to a permanent, timestamped record, read by a human lawyer, and that calling does not pause the task. It clarifies that the returned result is evidence, not approval, legal advice, or authorization—critical behavioral context not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—three purposeful sentences—and front-loads the core purpose before important caveats. Every sentence contributes: what the tool is for, what happens when called, and what the result does and does not mean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a human-assistance escalation tool, the description covers the full lifecycle: when to use it, what the record is, how replies reach the agent, behavioral non-blocking semantics, and the limitation of the returned result. With an output schema present and rich annotations, no further detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter descriptions are already detailed, so the description does not need to compensate. It adds only modest context, such as tying reply_to to the reply channel and framing the request as self-contained, but this largely duplicates the schema's existing explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource—"Ask an actual human being for help"—then enumerates the exact scenarios (legal judgment, decisions not on own authority, physical-world acts, operator escalation). Even without sibling tools, this clearly defines the tool's scope and differentiates it from ordinary task execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states explicit when-to-use scenarios and gives a when-not caveat: call only for things you cannot properly do alone, and the result is not approval or authorization. It closes with direct guidance to stop and wait if that is the right action, which is strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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 Servers
- Alicense-qualityCmaintenancePauses AI agent execution and routes approval requests to humans via Slack or email, with cryptographically signed proof of the human's decision.197MIT
- Alicense-qualityDmaintenanceEnables AI agents to request human approvals with customizable forms, webhooks, and team features.99MIT
- 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