Skip to main content
Glama

agent_handoff

Read-onlyIdempotent

Delegate a multi-step task (research, composing messages, booking, scheduling) to the full agentic planner. Use when a user ask needs more than a direct answer. The specialist runs synchronously — its response is already shown to the user in real-time. Summarize the OUTCOME in past tense (e.g. 'The Media Creator generated your video' or 'The Document Composer failed because...'). Do NOT say 'I will delegate' — the delegation already happened. If status is timeout or error, explain what went wrong and offer to retry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoExecution mode: 'sync' (wait for result, default) or 'async' (fire and forget, child runs in background). Async is only available in background/trigger context.sync
payloadNoOptional structured data for the target agent. For a rule_based (script) target this becomes the script's inputs['raw_data'] verbatim — pass the exact fields its script reads (same contract as the trigger event that script normally handles). For LLM targets it is appended to the task text as a [PAYLOAD] JSON block. VOICE callers: the voice pipeline's strict schemas seal free-form objects, so from a live call put the data in task_description instead — script targets receive it as inputs['message_text'].
agent_idNoOptional ID of another agent in the same workspace to delegate the task to. When set, this becomes cross-agent delegation; the target agent runs with ITS OWN prompt, tools, and model. Use this for specialty tasks (see agents.list to discover specialists). Prefer the in-loop variant (no `agent_id`) for one-off escalations. Spawns a new trace linked back to this trace via parent_trace_id (visible in the admin lineage card).
target_slugNoOptional stable slug of a system-template specialist to delegate to (e.g. 'doc-composer' for the Document Composer). Env-portable alternative to agent_id — resolves the workspace's fork of that template (auto-forking on first use). Used by async handoffs that target a specialist without knowing its per-workspace id.
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.
task_descriptionYesPlain-language description of what the planner should accomplish. Include everything the planner needs: the user's goal, constraints, and any context already gathered in this voice call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / in_workspace
      Added value: +{
      +  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
      +  "type": "integer"
      +}
  2. Added
  3. Removed
  4. Changed1 schema field changed
    • addedInput schema / properties / target_slug
      Added value: +{
      +  "description": "Optional stable slug of a system-template specialist to delegate to (e.g. 'doc-composer' for the Document Composer). Env-portable alternative to agent_id — resolves the workspace's fork of that template (auto-forking on first use). Used by async handoffs that target a specialist without knowing its per-workspace id.",
      +  "type": "string"
      +}
  5. Changed1 schema field changed
    • addedInput schema / properties / mode
      Added value: +{
      +  "default": "sync",
      +  "description": "Execution mode: 'sync' (wait for result, default) or 'async' (fire and forget, child runs in background). Async is only available in background/trigger context.",
      +  "enum": [
      +    "sync",
      +    "async"
      +  ],
      +  "type": "string"
      +}
  6. Changed1 schema field changed
    • removedInput schema / properties / model
      Removed value: -{
      -  "description": "Override the escalation model. Omit (recommended) to use the calling agent's configured model from settings; falls back to claude-sonnet-4-6 when no agent context. Ignored when `agent_id` is set — the target agent uses its own stored model.",
      -  "enum": [
      -    "claude-haiku-4-5-20251001",
      -    "claude-opus-4-6",
      -    "claude-sonnet-4-6",
      -    "deepseek-chat",
      -    "deepseek-reasoner",
      -    "gpt-4.1",
      -    "gpt-4.1-mini",
      -    "gpt-4.1-nano",
      -    "gpt-4o",
      -    "kimi-k2.6",
      -    "qwen-flash",
      -    "qwen-plus",
      -    "qwen3-vl-flash",
      -    "qwen3-vl-plus",
      -    "qwen3.6-flash",
      -    "qwen3.6-plus"
      -  ],
      -  "type": "string"
      -}
  7. Changed1 schema field changed
    • changedInput schema / properties / model / enum
      Previous value: -[
      -  "claude-haiku-4-5-20251001",
      -  "claude-opus-4-6",
      -  "claude-sonnet-4-6",
      -  "deepseek-chat",
      -  "deepseek-reasoner",
      -  "gpt-4.1",
      -  "gpt-4.1-mini",
      -  "gpt-4.1-nano",
      -  "gpt-4o",
      -  "kimi-k2.6"
      -]New value: +[
      +  "claude-haiku-4-5-20251001",
      +  "claude-opus-4-6",
      +  "claude-sonnet-4-6",
      +  "deepseek-chat",
      +  "deepseek-reasoner",
      +  "gpt-4.1",
      +  "gpt-4.1-mini",
      +  "gpt-4.1-nano",
      +  "gpt-4o",
      +  "kimi-k2.6",
      +  "qwen-flash",
      +  "qwen-plus",
      +  "qwen3-vl-flash",
      +  "qwen3-vl-plus",
      +  "qwen3.6-flash",
      +  "qwen3.6-plus"
      +]
  8. Changed1 schema field changed
    • changedInput schema / properties / agent_id / description
      Previous value: -"Optional ID of another agent in the same workspace to delegate the task to. When set, the target agent runs with ITS OWN prompt, tools, and model; `task_description` becomes its user query. Spawns a new trace linked back to this trace via parent_trace_id (visible in the admin lineage card). Omit to run a sub-loop on the calling agent (default behaviour)."New value: +"Optional ID of another agent in the same workspace to delegate the task to. When set, this becomes cross-agent delegation; the target agent runs with ITS OWN prompt, tools, and model. Use this for specialty tasks (see agents.list to discover specialists). Prefer the in-loop variant (no `agent_id`) for one-off escalations. Spawns a new trace linked back to this trace via parent_trace_id (visible in the admin lineage card)."
  9. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing that the specialist 'runs synchronously' and that its response is 'already shown to the user in real-time,' plus the existence of `timeout`/`error` statuses and the expected post-call behavior. It adds no information on auth requirements, rate limits, recursion/depth limits, or what a failed delegation returns, which keeps it out of the top score.

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?

Purpose and trigger are front-loaded in the first two sentences, and the remaining sentences each address a distinct failure mode (past-tense summary, not saying 'I will delegate', error handling). Slightly dense with imperative post-call instructions, but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter, side-effect-bearing delegation tool with no output schema, the description covers the odd sync semantics, the fact that output is already user-visible, and error states — the highest-risk gaps. It omits guidance on choosing between agent_id and target_slug in description text, though the schema covers that.

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?

Schema description coverage is 100%, so every parameter (mode, payload, agent_id, target_slug, in_workspace, task_description) is already documented in the schema with more detail than the description offers. The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema carries the full burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Delegate a multi-step task ... to the full agentic planner' — with concrete examples (research, composing messages, booking, scheduling) and a clear scope ('more than a direct answer'). It does not, however, distinguish itself from closely related siblings such as calls_dispatch_agent, agents_ask, background_run, or job_escalate, leaving the agent to infer the boundary.

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?

Gives an explicit trigger condition ('Use when a user ask needs more than a direct answer') and rich guidance on what to do after the call, including how to phrase the result and how to handle `timeout`/`error` statuses. It stops short of naming when NOT to use it or which sibling (e.g. calls_dispatch_agent, agents_ask) to prefer instead.

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.