request_hitl
Surface a question to the human-in-the-loop queue. ALWAYS use this to ask the human a question — never just ask in chat, which is invisible to the dashboard and to an unattended/autonomous run. IMPORTANT: when the project's HITL auto-answer mode is on (1=safe, 2=aggressive) and the question is no...
This record as markdown: /tools/io-github-ajc3xc-meridian/request-hitl.md
What request_hitl does on Meridian
AI agents call request_hitl to permanently remove resources in Meridian, typically in cleanup and lifecycle workflows. It does its job in a single call, and there is no undo.
| Parameter | Type | Required | Description |
|---|---|---|---|
kind | string | — | question (default, auto-answerable) or correction (non-blocking mid-run human correction). |
context | string | — | |
options | array | — | Answer choices rendered as selectable buttons in the dashboard. |
urgency | string | — | |
question | string | Yes | |
project_id | string | — | |
session_id | string | — | |
assigned_to | string | — | |
recommended | object | — | The safe-default option — an option string or a 0-based index into options. Highlighted in the dashboard; Enter submits it; auto-answer prefers it. |
project_name | string | — | Project name — an alternative to project_id; resolved to the id internally. project_id wins if both are given. |
require_human | boolean | — | When true, the HITL can never be auto-answered — only an explicit human response unblocks it. Reserve for irreversible/destructive actions. |
Parameters from the server's own tool schema.
Why request_hitl is rated Critical
An AI agent that decides to call request_hitl doesn't hesitate, doesn't double-check, and doesn't stop at one. Whatever it removes from Meridian is gone. There is no undo for destructive operations.
Risk signalsHigh parameter count (11 properties)
Attacks that exploit this kind of access
The rule that runs request_hitl safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Meridian, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For request_hitl, this is the rule to start with:
request_hitl is removed from the agent's tool list entirely, so the agent never calls it. The rest of the server keeps working.
The button opens the PolicyLayer dashboard: create your workspace, connect Meridian, apply this rule, and every request_hitl call is checked against it from then on.
Questions about request_hitl
Surface a question to the human-in-the-loop queue. ALWAYS use this to ask the human a question — never just ask in chat, which is invisible to the dashboard and to an unattended/autonomous run. IMPORTANT: when the project's HITL auto-answer mode is on (1=safe, 2=aggressive) and the question is not destructive / not require_human, this tool RESOLVES IMMEDIATELY and returns the chosen answer inline in the response (it does NOT block) — so calling it is cheap and is the right move even when you expect a quick yes/no. The active mode is reported in the start_session orientation as hitl_auto_answer_mode. urgency='blocking' means this session pauses until answered (poll get_hitl_request). urgency='normal'/'high' lands in the dashboard but doesn't block. assigned_to routes to a specific human_id (null = broadcast). kind='correction' files a non-blocking mid-run correction: never auto-answered, never blocks — an unattended executor picks it up at the next sprint-item boundary, applies it, and continues. Pass options (answer choices, rendered as buttons) and recommended (an option string or 0-based index) to flag the safe default — the dashboard highlights it and Enter submits it, and an auto-answer picks it. Set require_human=true for genuinely irreversible/destructive actions (token rotation, data migrations, rollbacks) so auto-answer can never approve it — only an explicit human reply unblocks it. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata are sent to and stored in Meridian's service; self-hosted deployments keep them in the configured local SQLite/Postgres database. This data is visible in the dashboard/API and later project context or handoffs. Delete individual tasks, notes, or decisions where supported, or delete the project/account using the documented controls. Do not include secrets. It is categorised as a Destructive tool in the Meridian MCP Server, which means it can permanently delete or destroy data. Block by default and require explicit approval.
request_hitl accepts 11 parameters: kind, context, options, urgency, question, project_id, session_id, assigned_to, recommended, project_name, require_human. Required: question. The full parameter table on this page comes from the server's own tool schema.
Register the Meridian MCP server in PolicyLayer and add a rule for request_hitl: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Meridian. Nothing to install.
request_hitl is a Destructive tool with critical risk. Critical-risk tools should be blocked by default and only enabled with explicit human approval.
Yes. Add a rate_limit block to the request_hitl rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for request_hitl. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
request_hitl is provided by the Meridian MCP server (@meridianmcp/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Meridian, and thousands of servers like it.
Across the catalogue