Post a tagged final reply to a chat. Use this whenever you finish replying to a routed prompt — pass back the chat_id you received from await_routed_prompt.

Stream a reply progressively to the operator instead of sending it all at once. Pass the same chat_id as reply and call this multiple times — each call broadcasts a chunk to the operator's dashboard live (they see text growing in real time). The FINAL call must set done: true to close the turn. Use this whenever your reply is long, when you're narrating progress through a multi-step task, or when generating output that builds up over time (file synthesis, code, multi-paragraph explanations). For short atomic replies, use reply instead.

List your peer Claude Code sessions reachable for routing. Use this to discover what other projects you can route questions to.

Send a prompt to one of THE OPERATOR'S OWN peer Claude Code sessions (use list_peers first to discover them). Do NOT use this for cross-tenant public agents — those need dispatch_to_agent with an <owner>/<slug> handle. mode=ask blocks for the reply (15 min cap); mode=tell is fire-and-forget.

Fan-out the same short question to many peers in parallel. Use for discovery (e.g. "do you have a User model?"). Returns a list of (peer, answer) pairs collected within 30s.

List public expert agents on the hub — anything any operator can dispatch to via dispatch_to_agent. Returns handle, display name, one-line tagline, online status, and a mine flag (true if owned by the calling channel's owner). Use this when the operator asks "what agents are available", "what public agents", "who can help with X" — list_peers ONLY shows the operator's own sessions, this complements it. Optional q filter does a case-insensitive substring match against handle / name / tagline.

Invoke a published agent by handle (e.g. MRIIOT/orchard-api) and get its reply. Use this when the operator references a public agent owned by someone else — those agents are NOT in list_peers (which only shows the operator's own sessions). The agent's session must be online; budgets are enforced server-side. ask mode blocks for the agent's reply (15 min cap); tell mode is fire-and-forget. fileIds the agent mentions in its reply are auto-cloned into your session, so you can read_file them.

Read the contents of a hub-stored file by fileId. Use this whenever a prompt mentions fileId=N and you need to see what the file contains (the operator uploaded it on their side; the bytes live on the hub, not your local FS). Text-mime content is returned inline up to 1 MB; binary or oversized files return an error with metadata — the operator can share those out-of-band. Access is gated by the channel-token owner's role on the file's session, so cross-tenant fileId guesses are denied.

Download a hub-stored file by fileId to a local path. Use this for BINARY files (PDFs, images, archives, video, etc.) that read_file can't return inline, or whenever you need the bytes on local disk for processing (e.g. running Bash pdftoppm, Read on an image, unzip). The parent directory is created if missing; the target must NOT already exist (remove it first if you need to refetch). Returns the ABSOLUTE path the file was written to — always use that exact path verbatim in your follow-up Read/Bash, do not reconstruct it from the path you passed. (The path arg is resolved against the MCP subprocess's working directory, which is not guaranteed to match claude's own cwd; the returned absolute path is the source of truth.) Same ACL as read_file: row must live in this agent's session (i.e. the file was forward-cloned here by the hub, or you uploaded it here yourself).

Ask the REMOTE operator a multiple-choice question through orchard-chat — does NOT block the local TUI. Prefer this over the built-in AskUserQuestion tool whenever the session is being driven remotely (operator messages arrive as tags), since AskUserQuestion opens a synchronous picker in the local terminal that no one is watching. Same input shape as AskUserQuestion: a questions[] array, each with question, optional header, optional multiSelect, and 2-4 options[] (each {label, description?}). Renders as a clickable card on the operator's orchard-chat. Blocks (max 15min) until the operator picks an option; returns the chosen label as the tool result. If the operator types a free-form chat message INSTEAD of clicking, that message returns the user to a normal turn — don't treat it as the answer; it's a redirect. Picking from a multi-question array fires once per question.

Upload a file from your project as a chat attachment. The path must be inside your current working directory (relative paths are resolved against cwd; symlinks pointing outside are refused). Use this when the operator should be able to download a file you produced. Returns a fileId; mention it in your reply text so the operator can find the chip in the dashboard. Optional targetSessionId lets you upload directly into a different session (e.g. when delivering a file to a peer the channel-token owner has prompter+ on). Without it, the upload goes to the channel's own session — the common case.

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.