AI Team OS

Overview Schema Source Related Servers Discussions Admin

fleet_dispatch

Send an operational instruction to an idle fleet session, resuming it to advance a task or report status without interrupting live users.

Instructions

Dispatch an operational instruction to another ship (CC session) in the fleet.

The fleet down-channel drives an EXISTING idle session to run one turn via headless claude -p --resume (fleet-layer design §4). Use it to nudge an idle ship to advance a task or report its status - NOT to make strategic decisions on the user's behalf (the dispatched turn is constrained to operational work).

Safety gate (enforced server-side, no subprocess spawns until it passes):

The target must be RESUMABLE: its transcript file still exists.
The target must NOT be user-live: its file must be idle beyond a conservative guard (FLEET_DISPATCH_MIN_IDLE_SECONDS, > the 15min live window) so a dispatch never competes with someone typing in that session. A too-fresh target is refused with availability="live".
Dispatches are deduped per-session, share the global wake concurrency limit and circuit breaker, and every one is ledgered in wake_sessions.
The dispatched turn runs under that session's own tool permission settings; the OS grants no tools of its own.

Get target_session_id from the fleet view / project summary (each ship's session_id).

Input Schema

TableJSON Schema

Name	Required	Description
`max_turns`	No	Max turns for the dispatched run (0 = server default)
`project_id`	No	Project scope (optional; inferred from the session's agents if empty)
`instruction`	Yes	The operational instruction (advance task X / report status / etc.)
`target_session_id`	Yes	The ship's CC session id to resume and dispatch to

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.15.0Sep 30, 2026

removedInput schema / properties / tools_level

Removed value: -{
-  "default": "safe",
-  "description": "Tool preset for the dispatched turn - \"safe\" (default) or\n\"with_bash\" (adds Bash). Never exceeds the requested preset.",
-  "type": "string"
-}

Addedv1.11.2Aug 3, 2026

TDQS

A4.8/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full behavioral burden and does so richly: preconditions for the safety gate, that a too-fresh target returns availability="live", deduplication per session, sharing of the global wake concurrency limit and circuit breaker, ledgering in wake_sessions, and that the dispatched turn inherits the target's own tool permissions. This goes well beyond what a typical definition discloses.

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 purpose and the usage exclusion before the denser safety-gate detail. It is on the long side, and the parenthetical (fleet-layer design §4) is an internal reference of limited use to an agent, but nearly every sentence contributes operational information.

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 not be explained, and the description still covers preconditions, failure modes, resource contention, permissions, and instructions for sourcing the required id. For a mutation tool with no annotations, nothing an agent needs in order to call it correctly is missing.

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, but the description adds real value: it explains how to obtain target_session_id ('from the fleet view / project summary') and constrains the instruction to operational work (advance task X / report status). max_turns and project_id semantics are left to the schema, which is acceptable at full coverage.

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 (dispatch) plus resource (operational instruction to another ship/CC session) and clarifies the mechanism (headless `claude -p --resume` of an existing idle session). This is a distinct action no sibling tool performs, so an agent can separate it from channel_send, meeting_send_message, or task_run without opening any 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 usage ('nudge an idle ship to advance a task or report its status') and states the exclusion ('NOT to make strategic decisions on the user's behalf'). It also documents where to source the target id and the server-side safety gate (resumable, not user-live, dedupe, concurrency, circuit breaker), which tells the agent exactly when a call will be refused.

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

Deploy Server