Skip to main content
Glama
Sign In
tmux-mcp

tmux-mcp

by vn-lazyming
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Type into terminal

tmux_send
Destructive

Type text and keystrokes into a live tmux pane and return the resulting output, enabling interactive or stateful terminal sessions to be driven and observed.

Instructions

Type into the live pane like a human, then return the output that appeared. Prefer this over a one-shot shell for anything interactive or stateful.

Returns once it is finished (shell prompt back, or a REPL/gdb/ssh showing the same prompt line as before), or the screen has been quiet idle seconds, or timeout passes. The last line says the state: [at shell prompt] = done; [foreground: X] = X still running or a REPL waiting for input. If it is still running, call tmux_read(wait_done=True) to wait for it to finish.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "tmux_send"
  }
}

Input Schema

NameRequiredDescriptionDefault
idleNoReturn once the screen is quiet this long (s) even if not finished. Raise for silent slow commands.
keysNotmux key names pressed after text: C-c, C-d, C-z, C-], Up, Down, Left, Right, Tab, BTab, Escape, BSpace, Enter, Home, End, PageUp, PageDown, F1-F12, single chars like "q", with C-/M-/S- modifiers
textNoTyped literally, e.g. 'ls -la' or 'SELECT 1;'. Empty to send only keys.
enterNoPress Enter at the end. False for keys like C-c.
pasteNoPaste `text` through a tmux buffer (bracketed paste) instead of typing it key by key. Use for multi-line or long text, e.g. a code block into python or vim, so auto-indent can't mangle it.
timeoutNoHard cap on waiting (s).
target_paneNotmux target such as "0:1.0" (session:window.pane, from tmux_list_panes); empty = the agent session "agent"

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations (destructive/openWorld/non-idempotent), the description discloses the three return conditions (prompt back, idle quiet period, timeout) and decodes the trailing state line ('[at shell prompt]' vs '[foreground: X]'), which is exactly the behavioral context an agent needs to interpret results.

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?

Front-loaded with purpose and preference, then return semantics. Slightly dense with parenthetical examples (REPL/gdb/ssh) and some redundancy around the state line, but nearly every sentence carries actionable information.

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?

For a stateful, destructive, interactive tool with 7 optional params and an output schema, the definition supplies enough: return timing, state interpretation, and the escalation path to tmux_read. Safety profile is covered by annotations.

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 coverage is already 100%, but the description adds meaning beyond it by explaining how idle and timeout interact with the return condition (screen quiet for idle seconds vs hard timeout), which the schema alone presents only as isolated field descriptions.

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 ('Type into the live pane ... then return the output') and scopes it to interactive/stateful terminals, immediately distinguishing it from a one-shot shell and from the sibling tmux_read. An agent can tell what this does without opening 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 Guidelines5/5

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

Explicitly routes usage: 'Prefer this over a one-shot shell for anything interactive or stateful,' and names the follow-up path when output indicates incompleteness ('call tmux_read(wait_done=True)'). Both when-to-use and the alternative/handoff are stated.

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