Human queue
Built-in escalation and human queue management. Exposes the escalation API as MCP tools for AI agents and remediation workflows.
| Property | Value |
|---|---|
| Server ID | long-tail-human-queue |
| Category | Automation |
| AI required | No |
| Credential providers | None |
| Tools | 10 |
Access
Section titled “Access”These tools act with full authority. At /mcp they are listed for superadmin accounts only. Other accounts work the queue through the role-checked escalation tools on long-tail-admin.
Compile hints
Section titled “Compile hints”escalate_and_wait creates a durable pause point. The step AFTER escalate_and_wait is always a signal step (kind: “signal”) that receives the human response. Fields from the signal step output (e.g., password) must be wired via data_flow edges to ALL downstream steps that need them.
escalate_to_human
Section titled “escalate_to_human”Create a new escalation for human review. Returns the escalation ID.
Read-safe: No · Gate: superadmin
| Parameter | Type | Required | Description |
|---|---|---|---|
role |
string |
Yes | Target role for the escalation (e.g., “reviewer”) |
message |
string |
Yes | Description of what needs human review |
data |
object |
No | Contextual data for the reviewer |
type |
string |
No | Escalation type classification (default: “mcp”) |
subtype |
string |
No | Escalation subtype (default: “tool_call”) |
priority |
number |
No | Priority: 1 (highest) to 4 (lowest) (default: 2) |
schema_version |
number |
No | Pin the role schema version the resolver form renders (defaults to latest) |
check_resolution
Section titled “check_resolution”Check the status of an escalation. Returns status and resolver payload if resolved.
Read-safe: Yes · Gate: superadmin
| Parameter | Type | Required | Description |
|---|---|---|---|
escalation_id |
string |
Yes | The escalation ID to check |
get_escalation_lookups
Section titled “get_escalation_lookups”Resolve the versioned knowledge lookups pinned on an escalation (envelope.lookups). Each ref answers with its immutable edition; a ref whose snapshot does not exist answers with missing: true. The call reads at service scope, with no per-user identity.
This tool is registered on the in-process human-queue server that workflows call. The /mcp endpoint does not list it.
Read-safe: Yes · Gate: superadmin
| Parameter | Type | Required | Description |
|---|---|---|---|
escalation_id |
string |
Yes | The escalation whose pinned knowledge lookups to resolve |
get_available_work
Section titled “get_available_work”List available escalations for a role. Returns pending, unassigned escalations.
Read-safe: Yes · Gate: superadmin
| Parameter | Type | Required | Description |
|---|---|---|---|
role |
string |
Yes | Role to filter by |
limit |
number |
No | Max results to return (default: 10) |
claim_and_resolve
Section titled “claim_and_resolve”Claim an escalation and immediately resolve it with a payload. Atomic operation. A read/write service account uses this to close out work and record the outcome in one call.
Read-safe: No · Gate: superadmin
| Parameter | Type | Required | Description |
|---|---|---|---|
escalation_id |
string |
Yes | The escalation ID to claim and resolve |
resolver_id |
string |
Yes | Identifier for who/what is resolving |
payload |
object |
Yes | Resolution payload, stored as submitted. Roles with enforce_schema validate it against the form schema |
resolve_escalation
Section titled “resolve_escalation”Resolve an already-claimed escalation with a payload. Use when the claim happened externally (e.g. via API).
Read-safe: No · Gate: superadmin
| Parameter | Type | Required | Description |
|---|---|---|---|
escalation_id |
string |
Yes | The escalation ID to resolve |
payload |
object |
Yes | Resolution payload, stored as submitted. Resumes the waiting workflow |
resolve_batch_item
Section titled “resolve_batch_item”Submit one declared item of a batch escalation. Interim items return outcome accepted with the count remaining; the last item completes the escalation and wakes the waiting workflow with the full collection.
Read-safe: No · Gate: superadmin
| Parameter | Type | Required | Description |
|---|---|---|---|
escalation_id |
string |
Yes | The batch escalation ID |
item_key |
string |
Yes | The declared batch item key this submission fills |
payload |
object |
Yes | The item payload |
accumulate_item
Section titled “accumulate_item”Add one item to an open accumulator escalation. Interim adds return outcome accepted with the count held; the add that reaches max completes the escalation and wakes the waiting workflow with the ordered collection.
Read-safe: No · Gate: superadmin
| Parameter | Type | Required | Description |
|---|---|---|---|
escalation_id |
string |
Yes | The accumulator escalation ID (the container) |
item_key |
string |
Yes | The key this item is held under |
payload |
object |
No | Item payload, delivered inside $accumulated |
reciprocal |
object |
No | A second accumulator row written in the same statement, both or neither. Exactly one of id, signalKey, or key/value, plus an optional payload |
remove_item
Section titled “remove_item”Remove one held item from a pending open accumulator escalation. The row stays pending and the waiting workflow is not woken.
Read-safe: No · Gate: superadmin
| Parameter | Type | Required | Description |
|---|---|---|---|
escalation_id |
string |
Yes | The accumulator escalation ID |
item_key |
string |
Yes | The held item key to remove |
reciprocal |
object |
No | A second accumulator row written in the same statement, both or neither. Exactly one of id, signalKey, or key/value |
escalate_and_wait
Section titled “escalate_and_wait”Create an escalation and pause the workflow until a human responds. Returns a signal ID that the workflow uses to wait durably. Preferred over escalate_to_human + check_resolution polling.
Read-safe: No · Gate: superadmin
| Parameter | Type | Required | Description |
|---|---|---|---|
role |
string |
Yes | Target role for the escalation (e.g., “reviewer”) |
message |
string |
Yes | Description of what input is needed from the human |
form_schema |
object |
No | JSON Schema for the resolver form. Use format:“password” for sensitive fields. |
data |
object |
No | Contextual data for the reviewer |
assigned_to |
string |
No | Auto-assign to a specific user |
type |
string |
No | Escalation type classification (default: “mcp”) |
subtype |
string |
No | Escalation subtype (default: “wait_for_human”) |
priority |
number |
No | Priority: 1 (highest) to 4 (lowest) (default: 1) |
schema_version |
number |
No | Pin the role schema version the resolver form renders (defaults to latest; an embedded form_schema takes precedence) |
Scope and one-time users
Section titled “Scope and one-time users”Escalations created by these tools land in the target role’s queue. Each member of that role sees and acts on them according to their work-surface scope: two axes carried by the role membership alongside its type (member, admin, or superadmin):
read_scope(self|all) governs which escalations a member sees.read_allshows the whole role queue;read_selfshows only items assigned to the member (assigned_to = user).write_scope(none|self|all) governs which a member may claim and resolve.write_selfacts only on the member’s own assigned items;write_allacts on the whole queue. The constraint is write ⊆ read: a member acts only on what they can see.
An admin or superadmin member ignores scope and always acts on the whole queue. The defaults are all/all, the full-queue worker.
get_available_work lists pending, unassigned escalations for a role: the shared pool that whole-queue (write_all) workers pull from. A write_self member works the item pre-assigned to them.
The one-time-user pattern
Section titled “The one-time-user pattern”To route a single escalation to a named person, set assigned_to when creating it (the assigned_to field on escalate_and_wait pre-claims the item for that user) and provision that person as a member of the role with read_self + write_self. The result is a scoped single-item surface: they see and act on exactly that one escalation. The scoped membership is provisioned through the platform’s user and escalation APIs (see Identity); these MCP tools supply the assigned_to pre-claim.