Skip to main content
Glama
KevinBuettner

docent-terminal-mcp

send

Transmit keystrokes to an interactive terminal without waiting for command results; use for Ctrl+C interrupts, answering prompts, tab completion, or driving vim/less/top.

Instructions

Send keystrokes without waiting for a command's result (that is run). ORDER: all of text is typed first (literally; a newline in it is Enter), THEN the keys are pressed in list order. To press a key before typing (escape, then an ex command), make two calls.

For: interrupting (ctrl+c; ctrl+d ends input, or gdb/python at their prompt; q leaves a pager), answering a one-character prompt, tab completion, history and arrows in a REPL, and driving full-screen programs (vim, less, top). Command lines go through run, which waits for their result; send only waits until output pauses for settle_ms (at most wait_ms) and returns what appeared -- or, while a full-screen program runs, the rendered screen with the cursor position: screen= "full" (every row), "changes" (only rows changed since the screen last returned: cheapest for editing), or "cursor" (the rows around the cursor). With nothing to send, it just reads what is new.

Keys are names such as ctrl+c, ctrl+d, enter, tab, escape, backspace, up, down, left, right, home, end, pageup, pagedown, f1-f12, alt+x, or any single character. Shell commands that finish during the call are reported with their exit status. Refuses, like run, to type over a human's unsubmitted line unless force. When nothing new appears, or a program is still in the foreground after ctrl+c, the reply names what is running there.

signal ("TERM", "KILL", "INT", "HUP", "QUIT"), instead of text and keys, sends that signal to the terminal's foreground job -- never the session's own shell or program: for a job that ignores ctrl+c and ctrl+d. TERM first; KILL if it survives. Prefer it to pkill from outside, which can hit the session's own shell.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keysNokey names pressed after the text, in order: ctrl+c, ctrl+d, enter, tab, escape, backspace, up, down, left, right, home, end, pageup, pagedown, f1-f12, alt+x, or a single character
textNotyped literally, first; a newline in it is Enter
forceNotype even over someone else's unsubmitted line at the prompt, discarding it first (only for a line you know is stale); with `signal`: send it although the foreground job is ssh, which it would end
screenNowith a full-screen program: "full" (every row), "changes" (rows changed since the last screen you saw; cheapest when editing), or "cursor" (the rows around the cursor)full
signalNoinstead of text and keys: "TERM", "KILL", "INT", "HUP" or "QUIT", sent to the foreground job (never the session's own shell or program) when ctrl+c and ctrl+d fail; TERM first
sessionYesthe session's name (from session_create or session_list)
wait_msNothe most to wait for output to settle before replying (milliseconds)
max_linesNolines of output, or rows of the screen, shown in the reply
settle_msNoreply once output has paused this long (milliseconds)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations, so the description carries the full burden and does so richly: it explains the text-then-keys ordering, that output is returned once it pauses for settle_ms (capped by wait_ms), the screen render modes, the refusal to type over a human's unsubmitted line unless `force`, and that `signal` never targets the session's own shell. It even recommends `signal` over `pkill`, covering side effects and safety.

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?

Long but front-loaded, with the core distinction (`run` vs `send`) in the first sentence and dense but non-redundant detail after. It is closer to thorough than bloated, though a few clauses could be tightened.

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?

The tool has an output schema, so return format need not be re-explained, and the description still covers timing, ordering, safety overrides, and signal behavior. 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 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the ORDER of `text` vs `keys`, the semantics of the three `screen` modes, when to prefer `signal` over pkill, and the `force` override for stale lines. Minor edge cases (e.g., max_lines interaction) remain to the 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?

States a specific verb and resource ('Send keystrokes without waiting for a command's result') and immediately distinguishes itself from the sibling `run` in parentheses. An agent can tell the two apart without opening either schema.

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?

Gives explicit use cases (interrupting, one-character prompts, tab completion, REPL history/arrows, full-screen programs) and explicitly routes command lines to `run`. The when/when-not distinction is spelled out rather than implied.

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