Skip to main content
Glama

respond

Destructive

Send text input to a running command that is waiting for input. Works for interactive prompts, passwords, or shell inputs.

Instructions

Send text input to any running command (status="partial"). This is the
general-purpose "write to stdin" tool — works for interactive prompts
(y/n, passwords), shell commands, or any text the process expects.
Auto-appends \n if missing.

NOTE ON MULTIPLEXERS: For commands running inside zellij/tmux, prefer
the multiplexer's own CLI (e.g. `zellij action write-chars`) via
`execute` instead of `respond`. Reasons:
  1. Output quality: `respond` returns the TUI's raw screen rendering
     (borders, status bar, ANSI redraws), not clean command output.
  2. Coupling: `respond` requires the original partial command_id to
     stay alive; the CLI approach is stateless — the daemon survives
     independently.

For control keys (Ctrl+C, arrows, F-keys, ESC, etc.) use send_control
instead — AI frameworks routinely strip control characters from string
arguments before this function ever sees them.

Returns the same format as execute.

Args:
- pause_timeout: seconds of OUTPUT SILENCE before returning (default 9.0).
  Raise this (not total_timeout) when the response is expected to take
  a long time to start producing output.
- total_timeout: hard cap on call duration (default 20.0). Only binds
  while output is actively streaming.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
command_idYesThe active command_id returned in a partial status response that is waiting for input
textYesThe text input to send to the command (e.g. 'y' for prompts, passwords, etc.). Newline is auto-appended
pause_timeoutNoSeconds of output silence to wait before returning (default is 9.0)
total_timeoutNoHard cap in seconds on the maximum duration of this call (default is 20.0)
Behavior5/5

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

Discloses behavior beyond annotations: auto-appends newline, returns same format as execute, and warns about output quality in multiplexers. Aligns with destructiveHint=true (mutating input) and adds context about coupling and state.

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?

Well-structured and front-loaded with the core purpose, followed by a detailed note on multiplexers, then guidance on control keys, and parameter specifics. Every sentence is informative, but slightly verbose; could be trimmed without losing clarity.

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 no output schema, the description notes 'Returns the same format as execute', providing return value expectations. Covers behavior, exceptions (multiplexer issues, control keys), parameter semantics, and alternative tools. Complete for a tool of this complexity.

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?

Schema already has 100% property descriptions, but the description adds value: explains that pause_timeout should be raised when response takes long, total_timeout is a hard cap during streaming, and text gets newline appended. Provides context for parameter usage.

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?

Clearly states that the tool sends text input to any running command with status='partial', describing it as a general-purpose 'write to stdin' tool. Distinguishes itself from siblings like send_control (for control keys) and execute (for running commands).

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?

Provides explicit when-to-use and when-not-to-use guidance: prefers multiplexer CLI for zellij/tmux and recommends send_control for control keys. Includes detailed reasons for the multiplexer avoidance (output quality, coupling).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/QiuwenZheng/interminal'

If you have feedback or need assistance with the MCP directory API, please join our Discord server