Skip to main content
Glama

agent_send

Destructive

Send text or tmux keys to a named agent's terminal. Optionally submit with Enter, wait for output, and receive the terminal tail.

Instructions

Type into an agent's terminal, addressed by name (or agent_id). text of any shape is prefixed with the sender tag, delivered as one bracketed paste and submitted with Enter unless submit=false. ONE EXCEPTION: text over 300 characters sent to a LEAD by anyone who is not that lead is stored and delivered as a one-line pointer instead, because a lead's pane is a human's own window; the receipt says so and names agent_message_get for the full text. Worker-bound text is never shortened at any length. With quiet_messaging on, a worker's submitted text to a Claude lead is stored with a message id and posted over the lead's messaging socket instead of typed (the same pointer when over 300 characters): the receipt says pending until the lead's prompt confirms it, hive types it into the pane once if no confirmation comes, and the socket post skips the pane checks below; do not resend a pending send. Alternatively pass keys (tmux key names like Escape, C-c, Enter). wait_ms (250-10000) returns the terminal tail after sending. A claude worker is already briefed by agent_spawn. A worker whose screen hive cannot classify is REFUSED on the text path entirely (its brief is at the spawn receipt's brief_path); keys still reaches it. A pane in tmux copy mode is REFUSED too, and retriably: tmux clears its bracketed-paste flag there, so the paste would lose its markers and the Enter would be eaten - leave copy mode (or agent_send(keys: ["-X", "cancel"]) to cancel it deliberately) and send again.

Input Schema

NameRequiredDescriptionDefault
keysNotmux key names, e.g. ["Escape"] or ["C-c"].
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.
textNo
submitNoAppend Enter after text. Defaults to true.
wait_msNo
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.5/5.0
Behavior5/5

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

Far exceeds what the annotations carry: sender-tag prefixing, bracketed-paste delivery, Enter-unless-submit=false, the 300-character lead-truncation exception, the quiet_messaging socket path with pending/confirmation and hive fallback, and two explicit refusal modes (unclassifiable screen, tmux copy mode) with recovery. These are exactly the mutation and failure semantics an agent needs before calling a destructive, non-idempotent tool.

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?

Front-loaded with the primary action, which is good, but the body is a single dense run-on paragraph chaining exceptions, quiet_messaging state machine, and refusal modes. Almost every clause carries necessary content, yet the absence of any list or paragraph breaks makes it hard to parse and pushes size past what is needed.

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?

With no output schema, the description correctly explains what receipts report (pointer vs full text, pending-until-confirmed), how failures behave, and how to recover from each refusal. For a 7-parameter destructive tool with complex routing, nothing an agent needs 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 71%, and the description fills the gaps: it characterizes text ('any shape', prefixed, pasted), submit=false, the keys tmux-name form, and repeats/confirms the wait_ms 250-10000 range. It adds real meaning over the schema for text and wait_ms, though it does not discuss project_id or agent_id/name precedence beyond what the schema already documents.

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?

Opens with a precise verb+resource ('Type into an agent's terminal, addressed by name (or agent_id)'), which is unambiguous and clearly distinct from siblings like agent_spawn, agent_output, and agent_message_get. The core action, addressing scheme, and the keys alternative are all stated up front without needing the schema.

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?

Gives explicit conditions and alternatives: use keys instead of text to send raw tmux keys, use agent_message_get to read the full text of a pointer, do not resend a pending send, and stay in current project scope. It does not, however, route the agent among other messaging siblings (e.g., question_ask) or state when not to use agent_send at all.

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