Skip to main content
Glama

submit_handoff

Submit a structured handoff with status, completed items, and issues when finishing a delegated task, enabling the orchestrator to parse and decide next steps.

Instructions

Submit a structured handoff to an orchestrator or other recipient peer. Use this when finishing a delegated task (worker -> orchestrator, validator -> orchestrator, etc.) instead of free-form route_to_peer text. The hub persists the full structured payload as a Handoff tail event for audit AND routes a serialized JSON version to the recipient peer so their CC sees it as a turn input. Pairs with the missions-orchestrator pattern: orchestrator spawns ephemeral worker, worker implements feature, worker calls submit_handoff with status + completed[] + issues[] etc., orchestrator parses the JSON and decides next step. Returns the JSON string the recipient will see so you can confirm shape.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNoOptional free-form prose for context that doesn't fit the structured fields.
issuesNoProblems the orchestrator should know about: pre-existing breakages you noticed, ambiguous requirements, security concerns, etc.
statusYescompleted = every assertion / procedure satisfied. partial = work done but some items skipped (must populate skipped[]). failed = unrecoverable, requires orchestrator intervention.
toPeerYesRecipient peer routing name (e.g. "@orchestrator-passwordreset"). The recipient receives a serialized JSON string as their turn input.
skippedNoList of {item, reason} for anything deferred.
fromRoleYesWhich role you played while doing the work.
completedNoBullet list of what got implemented / verified / shipped.
featureIdYesWhich feature this handoff covers (from the orchestrator's features.json).
missionIdYesFree-form mission correlation id. Pass the same value the orchestrator gave you when it spawned you.
commandsRunNoEach significant shell command you ran, its exit code, optional last ~20 lines of stdout/stderr for diagnostics.
proceduresHonoredNoWhich of the orchestrator-defined procedures (numbered steps in your prompt) you actually followed.
Behavior5/5

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

Discloses that the hub persists the payload as Handoff tail event, routes serialized JSON to recipient, and returns the JSON string. No annotations provided, so description carries full burden; it adequately covers behavioral aspects.

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?

Description is informative but not overly long. Front-loaded with main purpose. Could potentially be more concise, but it's well-structured and includes necessary pattern explanation.

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?

Tool is complex (11 params, nested objects), but schema covers parameter details. Description provides pattern context and return value info. No output schema, but return value is explained. Sufficient for agent understanding.

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 coverage is 100% with detailed descriptions per parameter, so baseline is 3. Tool description adds overall pattern context (e.g., missionId should match orchestrator) but does not substantially enhance individual parameter meaning beyond schema.

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?

Description clearly states the tool submits a structured handoff to an orchestrator or recipient peer, specifies use case (finishing delegated task), and distinguishes from free-form route_to_peer.

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?

Explicitly says when to use (finishing delegated task) and contrasts with route_to_peer. Mentions missions-orchestrator pattern context. Lacks explicit 'when not to use' but guidance is clear enough.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/clawborrator/channel_v1'

If you have feedback or need assistance with the MCP directory API, please join our Discord server