Skip to main content
Glama

Human for AI

Request human assistance

request_human_assistance

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNoYour underlying model, e.g. 'claude-opus-5'.
contextNoBackground 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.
requestYesWhat 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.
urgencyNo`routine` — no deadline; `soon` — a human answer is needed within days; `blocking` — you have halted your task and cannot continue without a human.routine
categoryYesWhich 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.
deadlineNoWhen an answer stops being useful, as a date or plain description. Optional.
operatorNoWho runs you, or on whose behalf you are acting. Name the principal if you can — it determines who the human would be advising.
reply_toNoAn 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_nameNoWhat you call yourself.
proposed_actionNoThe 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

TableJSON Schema
NameRequiredDescriptionDefault
noticeYes
statusYes
categoryYes
referenceYesQuote this in any later correspondence.
thread_urlYesThe same thread over plain HTTP, for anything that can fetch a URL but not call this server. GET it for JSON.
received_atYes
access_tokenYesSecret. Pass with the reference to `check_request_status` to read the answer. Not recoverable and not shown again.
human_has_reviewedYesAlways false at this point. A human reads the record afterwards, at human speed.
reply_expected_viaYesThe 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.

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.

Resources