Skip to main content
Glama

Hand a workspace over to another boss

handover

Transfer tasks and meetings between managers by releasing a chat workspace for takeover or claiming a waiting one only on user request.

Instructions

Transfer all tasks/meetings of a chat only on user request; no arguments lists waiting workspaces. release=true hands off; workspace_id claims and refuses the previous boss. Claiming your own waiting workspace withdraws it. Running work finishes on the old server; continue when writable=true. Private: never send to seats. Follow the agentnave-handover Skill.

Input Schema

NameRequiredDescriptionDefault
cwdNoWith release: absolute working directory; required when this chat has no saved conversations.
noteNoWith release: next steps and references for the next boss; saved in the App, so exclude secrets and sensitive personal data.
titleNoWith release: workspace name; required only when this chat has no saved conversations.
releaseNoMark this chat workspace as waiting for takeover.
workspace_idNoClaim a waiting workspace listed by handover().
manager_session_idNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.65.0
    • changedInput schema / $defs / ManagerSessionId / description
      Previous value: -"Current manager chat/session ID, shared by all tasks and groups in that chat. Use the host's real session ID when available; otherwise generate one UUID once for this manager chat and keep reusing it. A different chat needs a different ID. Never use the CLI name, MCP connection ID, or subagent session_id. Required by start_agent and run_round, and by handover to hand over or take over, unless AGENTNAVE_HOST_SESSION_ID is injected for this chat or the host gives this server its native session ID (Claude Code: CLAUDE_CODE_SESSION_ID)."New value: +"Boss chat ID from host context; see MCP instructions."
    • addedInput schema / properties / cwd
      Added value: +{
      +  "anyOf": [
      +    {
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "With release: absolute working directory; required when this chat has no saved conversations.",
      +  "title": "Cwd"
      +}
    • changedInput schema / properties / note / description
      Previous value: -"With release: notes for the next boss, written for what it must do next. Say why you hand over (out of quota, a model better suited to the work), the goal, what is done, decisions and why, what is open, desks in use, and the Skills to load (agentnave-manager, any review gate): it may come from another host. Name the conversations to read first and any worktree or uncommitted work needed to continue. Cite what already exists by reference only (conversation ids, PR or commit links, ADR or spec paths); the next boss reads seat answers with read_conversation, so keep this shorter than the records it points to. No keys, passwords or sensitive personal data: it is saved and shown in the App."New value: +"With release: next steps and references for the next boss; saved in the App, so exclude secrets and sensitive personal data."
    • changedInput schema / properties / release / description
      Previous value: -"Mark this boss chat's whole workspace as waiting for another boss chat to take over."New value: +"Mark this chat workspace as waiting for takeover."
    • addedInput schema / properties / title
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maxLength": 200,
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "With release: workspace name; required only when this chat has no saved conversations.",
      +  "title": "Title"
      +}
    • changedInput schema / properties / workspace_id / description
      Previous value: -"Take this waiting workspace over (from a call without arguments)."New value: +"Claim a waiting workspace listed by handover()."
  2. Changed1 schema field changedv0.58.0
    • changedInput schema / properties / note / description
      Previous value: -"With release: notes for the next boss, written for what it must do next. Say why you hand over (out of quota, a model better suited to the work), the goal, what is done, decisions and why, what is open, desks in use, and the Skills to load (agentnave-manager, any review gate): it may come from another host. Cite what already exists by reference only (conversation ids, PR or commit links, ADR or spec paths); the next boss reads seat answers with read_conversation, so keep this shorter than the records it points to. No keys, passwords or sensitive personal data: it is saved and shown in the App."New value: +"With release: notes for the next boss, written for what it must do next. Say why you hand over (out of quota, a model better suited to the work), the goal, what is done, decisions and why, what is open, desks in use, and the Skills to load (agentnave-manager, any review gate): it may come from another host. Name the conversations to read first and any worktree or uncommitted work needed to continue. Cite what already exists by reference only (conversation ids, PR or commit links, ADR or spec paths); the next boss reads seat answers with read_conversation, so keep this shorter than the records it points to. No keys, passwords or sensitive personal data: it is saved and shown in the App."
  3. Addedv0.53.1

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the annotations, disclosing that claiming refuses the previous boss (an access revocation side effect), that claiming your own waiting workspace withdraws it, that running work continues on the old server, and a privacy constraint ('never send to seats'). These are real behavioral traits the agent can't otherwise know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and every clause carries information, but the description is a densely semicolon-chained block with abrupt fragments ('Private: never send to seats') that are hard to parse on a first read. It could be restructured into clear sentences without losing content.

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?

The output schema and annotations cover the safety profile and the return value (writable), and the description explains the two modes and their conditions. Missing are error cases and what exactly 'no arguments' returns, which would help for a dual-purpose tool with 6 optional parameters.

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 coverage is 83%, so the schema already documents cwd, note, title, release, and workspace_id. The description adds mode interactions (no arguments lists waiting workspaces; release vs. workspace_id semantics; claiming your own workspace withdraws it) that the field-level descriptions don't fully cover.

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?

The description states a specific verb and resource ('Transfer all tasks/meetings of a chat') and reveals the tool's dual modes (release a workspace vs. claim a waiting one). It's a bit dense and chained together, but an agent can tell what the tool does. No sibling differentiation is needed since no other tool overlaps.

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?

'only on user request' gives a clear required condition, 'release=true hands off; workspace_id claims' gives mode selection, and 'Continue when writable=true' gives a follow-up condition. It doesn't name alternatives (none exist among siblings) or exclusions, but the when-and-how is present.

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