Skip to main content
Glama
cmgmyr

hive

by cmgmyr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

agent_send

Send text or tmux key presses to a named agent's terminal, optionally returning the terminal tail after a wait. Long messages to leads become retrievable pointers via agent_message_get.

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. 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

TableJSON 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.9/5.0
Behavior5/5

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

With no annotations present, the description carries full behavioral burden and it does extremely well. It discloses the sender-tag prefix, bracketed paste, Enter submission default, the exact 300-char lead threshold and pointer behavior, worker text non-truncation, keys mode, wait_ms returning the terminal tail, and both refusal cases (hive unclassifiable and tmux copy mode) with the copy-mode cancel command. No edge case is left undeclared.

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?

The description is long, but each sentence earns its place by detailing a distinct behavior or exception. It front-loads the primary function, then layers exceptions and constraints (lead limit, worker refusal, copy mode). The only minor deduction is for length—it could potentially be tightened by linking to annotations (which are absent) or splitting into structured notes, but given the complexity, the verbosity is justified.

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?

Given 7 parameters, no annotations, and no output schema, this description is exceptionally complete. It covers all invocation paths (text, keys), all failure modes (lead, hive, copy mode), retry instructions, related tools (agent_message_get), and parameter semantics (wait_ms tail, name vs agent_id precedence). An agent can call it correctly in every scenario without additional info.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite schema coverage being 71% (text lacks a schema description), the tool description adds substantial meaning: it explains that 'text' can be any shape, is prefixed with sender tag, delivered as bracketed paste, and hits the 300-char lead exception; it explains 'keys' are tmux names and how they bypass refusal; it clarifies 'wait_ms' behavior (returns terminal tail) and the precedence rules for name vs agent_id. This goes far beyond the raw schema.

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?

The description states a specific verb ('Type into an agent's terminal') and resource (agent by name or agent_id), and clarifies the delivery mechanism (bracketed paste, Enter submit). It distinguishes itself from sibling tools like agent_spawn, agent_resume, agent_message_get, and agent_close by describing its core function unmistakably. The lead exception and refusal conditions further pin down exactly what it does, so an agent can tell it apart from all siblings.

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?

The description gives explicit when-to-use guidance: text for normal input, keys for tmux key events, and warns against using text to a lead beyond 300 chars (with pointer fallback and pointer to agent_message_get). It states when text path is refused (unclassifiable hive, copy mode) and provides a retry path. It also implies the relationship to agent_spawn by noting a claude worker is already briefed, giving clear context without listing alternatives.

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

Deploy Server

Other Tools