Skip to main content
Glama

agent_resume

Resume a closed Claude or Codex worker from its recorded session ID to restore the same actor and full prior context, then send its next instruction separately.

Instructions

Resume a CLOSED claude or codex worker from its recorded session id (claude --resume / codex resume): a fresh pane, the same actor_id, and the worker's full prior context. A same-project worker or lead on that harness's active usage limit makes this resume retryable until its reset or bounded deadline; hive does not queue resumes. Addressed by name or agent_id among closed agents (agent_list(include_closed: true)). Send it its next instruction with agent_send once resumed - this tool does not.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "agent_resume"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoThe worker's name, e.g. "impl" or "DEVX-123". Prefer passing this rather than agent_id, but pass only one: if both arrive, agent_id wins and this is ignored. A partial name works when it matches exactly one running worker, so "123" finds DEVX-123.
agent_idNoNumeric agent id. Use name instead unless you have the id to hand.
project_idNoDifferent project override. Use ONLY when the user explicitly asks for another project by name; otherwise stay in the current scope, even when results are empty.

Output Schema

NameRequiredDescriptionDefault
nameYes
actor_idYes
agent_idYes
hive_noticeNo
tmux_targetYes
branch_driftNo
was_parked_atNo
landed_in_projectNo
resumed_session_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.2
    • addedOutput schema / properties / hive_notice
      Added value: +{
      +  "type": "string"
      +}
  2. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say non-readonly, non-idempotent, non-destructive; the description goes further by describing side effects (fresh pane, actor_id preservation, restoration of prior context) and failure semantics (retryable under a same-project worker/lead hitting a harness usage limit, no queueing). That is meaningful behavioral context an agent could not infer from the structured fields.

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?

Front-loaded with the core action and effect, then constraints, then the follow-up pointer; no filler sentences. It is dense and slightly dash-chained, but each clause carries information relevant to calling it correctly.

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

Completeness5/5

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

An output schema exists so return values need no explanation, and the description covers what an agent needs to decide and act: eligibility (closed only), addressing, retry behavior under usage limits, and the required follow-up via agent_send.

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 100%, so the baseline is 3; the description adds value by narrowing the addressing semantics — name or agent_id resolved among closed agents — which constrains how the identifiers are interpreted. It does not add format or precedence detail beyond the schema, which already explains name/agent_id conflict resolution.

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?

States a specific verb+resource: 'Resume a CLOSED claude or codex worker from its recorded session id', naming the underlying mechanism (claude --resume / codex resume) and the effect (fresh pane, same actor_id, prior context). This clearly separates it from agent_spawn, agent_fork, and agent_send without needing to open a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly scopes the target to closed agents reachable via agent_list(include_closed: true), and routes the follow-up action to agent_send with the caveat that this tool will not send instructions. It also states the when-not condition (hive does not queue resumes; the call is retryable until the usage-limit reset or a bounded deadline).

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