cmuxlayer

Overview Schema Source Related Servers Discussions Admin

send_to

Instructions

Send text or a key through the shared delivery engine. send_to submits new messages. Key-Return supports pickers, menus, permission prompts, and recovery of this caller's exact typed draft on the same agent/session once the displayed unambiguous reset time passes or new harness output confirms recovery; the old refusal may stay visible. Exact /usage, /usage-credits or /rate-limit-options navigation is also guarded. Read the pane and receipt first; never retype or repeat accepted input. Every receipt includes caller_agent_id (null when unknown). Workers with collab_path cannot address their own parent or ancestor leads in any mode; append to that collab file instead. Unknown callers remain allowed. Lead-originated and engine-internal pushes remain allowed. Targets may be one agent, structured agent targeting, or a raw surface in surface/command/key mode; for shell commands use mode:command. Text success requires a verified submit or new matching queue proof. Otherwise ok=false with submit_unverified retains pending verification and ownership for retries without retyping. Verified text success returns only ok, target identity, delivery_id, delivery_state, submitted, caller_agent_id, and queued_behind_turn when applicable. Key success returns its key verification fields. Pass verbose=true for full diagnostics; failures always retain them.

Input Schema

Name	Required	Description	Default
`mode`	No		agent
`text`	No	Max 2-3 short lines. Longer payloads BREAK the receiving pane — write the payload to a file and send one line: `Read and follow <path>`. Text to send. Capped at 500 inline UTF-8 bytes by default.
`target`	No
`surface`	No
`verbose`	No	Return the full legacy success receipt, including transport and timing diagnostics. Failures always keep full detail.
`agent_id`	No
`targeting`	No
`workspace`	No
`allow_busy`	No	Deprecated no-op. Safety gates still refuse text at a picker/menu or permission prompt; use mode=key to drive those deliberately.
`background`	No
`chunk_size`	No
`press_enter`	No	Press enter after sending text
`rename_to_task`	No
`codex_busy_mode`	No	Busy Codex defaults to Return steering at the next tool call; queue opts into Tab after-turn delivery. Neither pending state is delivered.
`boot_prompt_path`	No
`allow_long_inline`	No	Bypass the inline length and multi-paragraph safety guards for a deliberate raw send. Large allowed sends keep the existing chunked delivery behavior.
`boot_prompt_timeout_ms`	No

Output Schema

Name	Required	Description	Default
`ok`	Yes
`key`	No
`model`	No
`title`	No
`typed`	No
`health`	No
`screen`	No
`status`	No
`command`	No
`surface`	No
`accepted`	No
`agent_id`	No
`delivery`	No
`receipts`	No
`terminal`	No
`delivered`	No
`agent_type`	No
`delivery_id`	No
`done_marker`	No
`report_path`	No
`retry_count`	No
`rpc_methods`	No
`duplicate_of`	No
`contract_path`	No
`delivery_state`	No
`registry_state`	No
`state_conflict`	No
`needs_attention`	No
`submit_evidence`	No
`submit_verified`	No
`attention_reason`	No
`submit_attempted`	No
`boot_prompt_bytes`	No
`submit_dispatched`	No
`boot_prompt_receipt`	No
`boot_prompt_warning`	No
`boot_prompt_delivered`	No
`coordination_footer_note`	No
`coordination_footer_bytes`	No
`boot_prompt_submit_verified`	No
`coordination_footer_delivered`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.4.106Oct 14, 2026

addedInput schema / properties / codex_busy_mode

Added value: +{
+  "description": "Busy Codex defaults to Return steering at the next tool call; queue opts into Tab after-turn delivery. Neither pending state is delivered.",
+  "enum": [
+    "steer",
+    "queue"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / delivery / enum

Previous value: -[
-  "submitted",
-  "typed",
-  "queued",
-  "queued_followup",
-  "rescued",
-  "failed",
-  "pending_verify",
-  "failed_confirmed",
-  "stalled_queue"
-]New value: +[
+  "submitted",
+  "typed",
+  "queued",
+  "steer_pending",
+  "queued_followup",
+  "rescued",
+  "failed",
+  "pending_verify",
+  "failed_confirmed",
+  "stalled_queue"
+]

changedOutput schema / properties / delivery_state / enum

Previous value: -[
-  "submitted",
-  "typed",
-  "queued",
-  "queued_followup",
-  "rescued",
-  "failed",
-  "pending_verify",
-  "failed_confirmed",
-  "stalled_queue"
-]New value: +[
+  "submitted",
+  "typed",
+  "queued",
+  "steer_pending",
+  "queued_followup",
+  "rescued",
+  "failed",
+  "pending_verify",
+  "failed_confirmed",
+  "stalled_queue"
+]

changedOutput schema / required

Previous value: -[
-  "ok",
-  "retry_count"
-]New value: +[
+  "ok"
+]

Addedv0.4.88Sep 26, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations give only the safety profile, and the description adds substantial context beyond it: permission gating (supervised callers barred from their own parent/ancestor leads, must append to the collab file), success criteria (verified submit or new queue proof), ok=false/submit_unverified retention of ownership without retyping, and guaranteed caller_agent_id in every receipt. The detail is genuinely useful, though some of it (verbose, allow_busy) duplicates the schema.

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 core action is correctly front-loaded in the first two sentences, and most clauses carry substantive content. However the remainder is a dense run-on block of semicolon-joined caveats with no structure, making it hard for an agent to extract the operative rules (e.g. the 'old refusal may stay visible' aside) at a glance.

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?

Given an output schema exists and annotations cover safety, the description does explain the pieces an agent needs: modes, target shapes, permission bars, and partial-failure/retry semantics. Remaining gaps are secondary parameter explanations and the interaction among target, agent_id, and targeting, which are not disentangled.

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 only 35% across 17 parameters, so the description carries real burden. It partially compensates by explaining the targeting space ('one agent, structured agent targeting, or a raw surface in surface/command/key mode') and mode semantics, but roughly ten parameters (chunk_size, press_enter, background, rename_to_task, boot_prompt_path, boot_prompt_timeout_ms, allow_long_inline, workspace, etc.) get no mention in either place.

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 opening two sentences state a specific verb and resource (send text or a key, submit new messages) and identify the four operational modes, so the agent knows this is the delivery tool. It is weaker on sibling differentiation: report_to_parent and spawn_agent are never named, and the only routing advice is mode-internal ('for shell commands use mode:command').

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

Usage Guidelines3/5

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

There is real conditional guidance ('Read the pane and receipt first; never retype or repeat accepted input', mode=key for pickers/menus, mode:command for shell), but it is scattered rather than framed as when-to-use-this-vs-alternatives. No sibling tool is named as the alternative for any case, so the agent must infer routing.

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

Deploy Server