Skip to main content
Glama

set_human_gate

DestructiveIdempotent

Freeze a task for human input by recording the question, who must answer, and the default action if no one responds. Requires justification and refuses when no human is needed.

Instructions

Arm the human gate on a task: freeze it and record WHO is waiting, WHAT was asked, and WHAT you will do if nobody answers. Use INSTEAD of writing a '❓ Blocking @' comment by hand — the marker still works, but this path records the whole ask on the task, so nothing has to re-read the thread. recommended_default is REQUIRED: a gate with no stated default can only ever be resolved by finding a human. You must answer four questions (credential_exists / reversible / blocked_by_other_task / customer_visible_now), each with one line of justification. The server REFUSES the arm when your own answers say nobody needs to be asked: if you hold the credential, the action is reversible, and nothing a customer sees or pays changes right now, capture a rollback anchor and just do it. If the blocker is another card, the server tells you to use add_dependency instead.

Input Schema

NameRequiredDescriptionDefault
classNo'hard' (default, never auto-released) or 'soft' (released by timeout — the release does NOT answer the question).
reasonYesThe question itself, in your own words.
task_idYesTask ID to gate.
deadlineNoRFC3339 timestamp when recommended_default applies. Omit for no deadline.
copy_tierNoOnly when this ask is about VISIBLE PRODUCT COPY (a label, a page's prose, a message users read) — otherwise omit entirely. Answer three questions: (1) is this the company's voice going OUT, or a caption inside the interface? (2) would someone who never opened this screen notice the change? (3) does the text carry a promise — legal, price, product? Any "yes" → tier "A" (external/legal/marketing copy, a promise) and the workspace owner decides. All "no" → tier "B" (a field caption, menu item, system or validation message, section name, an existing dictionary string) and the product lead ships it without asking — the workspace owner sees it after the fact. The server refuses tier "B" outright: ship it yourself, tag the task `copy:b`, quote the exact string in your closing comment. Omitting copy_tier on an ask that reads as copy-approval is refused too, naming this field — state the tier and retry.
reversibleYesIs there a rollback anchor — git revert, backup, snapshot, image tag? If you can MANUFACTURE one (take a backup first), the answer is true.
blocked_reasonYesOne line: which card, or why none.
customer_reasonYesOne line: what the customer would see, or why nothing changes for them now.
credential_existsYesDo you ALREADY hold the credential or access this needs? Check your team's credential store before answering false — a service account your team created for its agents is yours to use.
credential_reasonYesOne line: which credential, and where you checked.
reversible_reasonYesOne line: the exact rollback path, or why none exists.
recommended_defaultYesWhat you will do if nobody answers. Required — an ask with no default cannot time out.
customer_visible_nowYesDoes this change what a customer SEES or PAYS right now? A disabled gateway, an inactive flag or a reversible migration is NOT customer-visible; a rate that prints on invoices people already download is.
blocked_by_other_taskYesIs the thing you are waiting on actually ANOTHER card? If yes, the answer is add_dependency, not a gate — a blocks edge freezes the feed without adding anything to a human's queue.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructive=true / readOnly=false / idempotent=true, and the description goes well beyond them: server-side refusal when the four answers show nobody needs asking, the requirement that recommended_default be present or the gate can never time out, the hard/soft class distinction where a soft release 'does NOT answer the question', and the copy_tier refusal rules. That is exactly the kind of non-obvious behavior an agent needs before invoking.

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?

Front-loaded with the core action and the required default, then the refusal rules. It is dense and somewhat long, and the copy_tier discussion runs several sentences, but nearly every sentence carries actionable constraint information rather than filler.

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?

For a 14-parameter mutation with no output schema, the description covers the mandatory fields, the refusal semantics, the fallback path to add_dependency, and what happens on timeout. An agent has everything needed to call it correctly or to know it should not.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3; the description lifts it by explaining the cross-parameter logic (the four boolean+reason pairs jointly determine refusal) and the semantics of class, recommended_default, and copy_tier tiers. It does not, however, add field-level detail beyond what the schema already carries.

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?

Opens with a precise verb+resource+effect: 'Arm the human gate on a task: freeze it and record WHO is waiting, WHAT was asked, and WHAT you will do if nobody answers.' That is enough for an agent to distinguish it from siblings like add_comment, add_dependency, clear_human_gate, and release_task without opening any schema.

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?

Explicitly says to use this INSTEAD of hand-writing a '❓ Blocking @<person>' comment, and names the alternative path when the blocker is another card ('the server tells you to use add_dependency instead'). It also states the conditions under which the server refuses the arm, which is guidance about when NOT to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.