Allows AI agents to read, type, and send messages to any tmux pane, enabling cross-pane communication and multi-agent coordination.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tmux-bridge-mcp Read the last 10 lines from pane 1"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English | 简体中文
A standalone MCP server that lets AI agents (Claude Code, Gemini CLI, Codex, Kimi CLI) communicate with each other through tmux panes. It talks directly to tmux -- no external dependencies beyond tmux itself.
tmux is a terminal multiplexer -- it lets you split one terminal window into multiple panes, each running its own process independently. Think of it as "tabs on steroids" for your terminal.
+-------------------------------+
| Pane 1 | Pane 2 |
| Claude Code | Codex |
| writing code | reviewing |
| | |
+---------------+---------------+
| Pane 3 | Pane 4 |
| Gemini CLI | tail -f logs |
| researching | monitoring |
+-------------------------------+Each pane is a full terminal. You can have Claude Code running in one, Codex in another, Gemini in a third -- all visible at the same time, all on the same machine.
The problem: these panes can't talk to each other. An agent in Pane 1 has no idea what's happening in Pane 2.
tmux-bridge fixes this. It gives every agent the ability to read, type, and send messages into any other pane.
Related MCP server: Terminal MCP Server
Once installed, your AI agents can:
Action | How | Example |
See what another agent is doing |
| Read the last 20 lines of Codex's pane |
Send a task to another agent |
| Tell Claude to review a file |
Coordinate multi-agent workflows | Chain tool calls | Gemini researches -> Claude implements -> Codex reviews |
Monitor processes |
| Watch build logs, test output, server status |
Label panes by role |
| Name panes "claude", "codex", "gemini" for easy targeting |
All of this happens through standard MCP tool calls -- your agent doesn't need to learn any new syntax. If it supports MCP, it already knows how.
Agent | Connection | Setup path |
Native MCP (stdio) |
| |
Native MCP (stdio) |
| |
Native MCP (stdio) |
| |
Native MCP (stdio) |
| |
Native MCP (stdio) |
| |
Native MCP (stdio) |
| |
Native MCP (stdio) |
| |
Kimi CLI v1.26+ | Native MCP ( |
|
Kimi CLI older | Legacy wrapper ( | wrapper binary |
Agent | Notes |
Supports MCP servers in settings | |
MCP server support | |
Community MCP support | |
MCP server support | |
VS Code extension with MCP | |
Fork of Cline with MCP | |
Any shell script or process | Read pane output with |
tmux-bridge works with any agent that supports MCP over stdio. If your agent isn't listed, try adding the MCP config -- it will likely just work.
When you run multiple AI agents in separate terminals, they work in isolation. You end up copy-pasting context between them, manually relaying questions and answers, or losing track of what each agent is doing.
tmux-bridge solves this by giving every agent the ability to read, type, and send messages into any other terminal pane -- programmatically, through standard MCP tool calls.
Use cases:
Code review pipeline -- Claude Code writes code in one pane, Codex reviews it in another, results flow back automatically
Multi-model reasoning -- ask Gemini for research, feed the findings to Claude, let Codex verify the implementation
Parallel workflows -- multiple Claude Code instances each handling a different part of a large task, coordinating through pane messages
Monitoring -- an agent reads log output from a tail -f pane and reacts to errors in real time
What you need:
Requirement | Why |
tmux | The terminal multiplexer that hosts your panes -- this is the communication channel |
Node.js 18+ | Runs the MCP server |
At least one MCP-compatible agent | Claude Code, Codex, OpenCode, CodeBuddy, Copilot CLI, Grok Build, Gemini CLI, or Kimi CLI v1.26+ |
If you already use tmux to run multiple agents side by side, tmux-bridge just makes them aware of each other.
You're running Claude Code in one pane, Codex in another. Claude finishes writing a function and you want Codex to review it. Here's what actually happens:
You read Claude's output. Scroll up. Copy the relevant part.
Switch to Codex's pane. Paste it in. Type "review this code."
Codex gives feedback. You copy that.
Switch back to Claude. Paste Codex's feedback. "Fix these issues."
Repeat for every round of review.
You are the message bus. Every interaction flows through your clipboard. You're not writing code anymore -- you're routing context between agents. With 3+ agents running, this becomes unmanageable within minutes.
Approach | What it asks you to do | tmux-bridge difference |
LangChain / CrewAI / AutoGen | Rewrite your workflow inside their framework. Your agents must be Python objects in their orchestration layer. | You keep using Claude Code, Codex, Gemini CLI as-is. No framework, no SDK, no rewrite. |
Google A2A Protocol | Wait for agents to adopt a new protocol spec. Designed for distributed, networked agents. | Works today with any MCP agent. No protocol adoption needed. |
Custom WebSocket / HTTP glue | Build and maintain your own IPC layer. Handle serialization, discovery, error handling. | Zero infrastructure. tmux is the transport -- it's already running. |
Shared files / pipes | Roll your own convention. Each agent needs custom tooling to read/write. | Standard MCP tools. Any agent that speaks MCP gets cross-pane superpowers instantly. |
The key insight: you don't need a multi-agent framework. You need your existing agents to see each other. tmux-bridge adds exactly that -- a thin MCP layer over tmux -- and nothing more.
Prerequisites: tmux 3.2+ and Node.js 18+ must be installed.
One command to configure all your agents:
npx tmux-bridge-mcp setupThis auto-detects Claude Code, Codex, OpenCode, CodeBuddy, Copilot CLI, Grok Build, Gemini CLI, and Kimi CLI on your machine, then writes the correct MCP config for each one. Done in seconds.
Verify it works:
npx tmux-bridge-mcp --helpYou should see the version and available commands. Restart your AI agent to activate the new tools.
See it in action:
npx tmux-bridge-mcp demoOpens a 3-pane tmux session and runs a live cross-pane communication demo.
1. Install tmux
brew install tmux # macOS
apt install tmux # Linux2. Add to your agent's MCP config
{
"mcpServers": {
"tmux-bridge": {
"command": "npx",
"args": ["-y", "tmux-bridge-mcp"]
}
}
}Restart your agent. It now has 9 MCP tools for cross-pane communication.
# If installed globally
npm update -g tmux-bridge-mcp
# If using npx (auto-updates, but to force latest)
npx tmux-bridge-mcp@latest
# Check your current version
npx tmux-bridge-mcp --versionAfter updating, restart your agents to pick up the new version. If you use npx in your MCP config, it caches the package — run npx --yes tmux-bridge-mcp@latest once to pull the latest, then your agents will use it on next startup.
tmux-bridge runs as an MCP server over stdio. It calls tmux directly (capture-pane, send-keys, list-panes, etc.) -- no intermediate CLI layer.
MCP path (Gemini, Claude Code, Codex, any MCP client):
+--------------+ MCP/stdio +---------------+ tmux API +--------------+
| MCP Agent |<----------->| tmux-bridge |<---------->| tmux panes |
+--------------+ | MCP server | +--------------+
+---------------+
CLI path (Kimi):
+--------------+ --print +---------------+ tmux API +--------------+
| Kimi CLI |<----------->| kimi-tmux |<---------->| tmux panes |
+--------------+ tool parse | adapter | +--------------+
+---------------+
All cross-pane interactions follow the read-act-read workflow:
Step | Action | Purpose |
1 |
| Read target pane (satisfies read guard) |
2 |
| Type your message or command |
3 |
| Verify text landed correctly |
4 |
| Press Enter to submit |
-- | STOP | Don't poll. The other agent replies directly into your pane. |
The read guard is enforced at the MCP layer: tmux_type, tmux_message, and tmux_keys will fail unless you call tmux_read on the target pane first.
Add to ~/.gemini/settings.json:
{
"mcpServers": {
"tmux-bridge": {
"command": "npx",
"args": ["tmux-bridge-mcp"]
}
}
}Add to your project's .mcp.json or global MCP config:
{
"mcpServers": {
"tmux-bridge": {
"command": "npx",
"args": ["tmux-bridge-mcp"]
}
}
}Add to your MCP config following the Codex MCP setup docs:
{
"mcpServers": {
"tmux-bridge": {
"command": "npx",
"args": ["tmux-bridge-mcp"]
}
}
}opencode mcp add is interactive. tmux-bridge-mcp setup writes directly to
~/.config/opencode/opencode.json (or .jsonc):
{
"mcp": {
"tmux-bridge": {
"type": "local",
"command": ["npx", "-y", "tmux-bridge-mcp"],
"enabled": true
}
}
}codebuddy mcp add -s user tmux-bridge -- npx -y tmux-bridge-mcpFallback config path: ~/.codebuddy/.mcp.json (standard mcpServers JSON).
copilot mcp add tmux-bridge -- npx -y tmux-bridge-mcpFallback config path: ~/.copilot/mcp-config.json:
{
"mcpServers": {
"tmux-bridge": {
"type": "local",
"command": "npx",
"args": ["-y", "tmux-bridge-mcp"],
"tools": ["*"]
}
}
}grok mcp add -s user tmux-bridge -- npx -y tmux-bridge-mcpFallback TOML in ~/.grok/config.toml:
[mcp_servers.tmux-bridge]
command = "npx"
args = [
"-y",
"tmux-bridge-mcp",
]
enabled = true# Check your Kimi version
kimi --version
# v1.26+ → use native MCP (recommended)
# older → use kimi-tmux wrapperNative MCP (recommended, v1.26+):
kimi mcp add tmux-bridge -- npx tmux-bridge-mcpOnce added, Kimi uses all tmux-bridge tools directly -- no adapter needed.
Legacy wrapper (older versions):
For Kimi CLI versions without native MCP, kimi-tmux bridges the gap by injecting the system instruction as a prompt, running Kimi in --print mode, parsing tool-call blocks from output, and executing them via tmux.
kimi-tmux "list all tmux panes"
kimi-tmux "ask the agent in codex pane to review src/auth.ts"
kimi-tmux "read what claude is working on"
kimi-tmux --rounds 3 "send a message to gemini and wait for the result"
Tool | Description |
| List all panes with target ID, process, label, and working directory |
| Read last N lines from a pane (satisfies read guard) |
| Type text into a pane without pressing Enter (requires prior read) |
| Send message with auto-prepended sender info (requires prior read) |
| Send special keys -- Enter, Escape, C-c, etc. (requires prior read) |
| Label a pane for easy targeting (e.g., "claude", "gemini") |
| Look up pane ID by label |
| Print current pane's tmux ID |
| Diagnose tmux connectivity issues |
Targets can be a pane ID (%0), session:window.pane (main:0.1), or a label (claude).
tmux_list()
tmux_read(target="claude", lines=20)
tmux_message(target="claude", text="Please review src/auth.ts for security issues")
tmux_read(target="claude", lines=5)
tmux_keys(target="claude", keys=["Enter"])kimi-tmux "tell the claude pane to run the test suite"
kimi-tmux "ask gemini to summarize the test results in claude's pane"+-----------------------------------------------------------+
| tmux session |
| |
| +------------+ +------------+ +----------+ +-----------+ |
| | Claude Code | | Codex | | Gemini | | Kimi | |
| | (MCP) | | (MCP) | | (MCP) | |(kimi-tmux)| |
| | | | | | | | | |
| | label: | | label: | | label: | | label: | |
| | claude | | codex | | gemini | | kimi | |
| +-----+------+ +-----+------+ +----+-----+ +-----+-----+ |
| +---------------+-----------+--------------+ |
| tmux-bridge (direct tmux IPC, no deps) |
+-----------------------------------------------------------+Variable | Description | Default |
| Override tmux server socket path | Auto-detected from |
| Path to |
|
tmux-bridge is designed for local development on a single machine. It assumes all connected MCP agents are trusted:
Any agent can read from or write to any pane in the tmux server — there is no per-pane access control.
The read guard (must tmux_read before tmux_type/tmux_keys) is a sequencing aid to prevent blind typing. It is not a security boundary.
Pane labels set via tmux_name are not authenticated — any agent can label or relabel any pane.
There is no encryption or authentication between agents. Communication happens through tmux's own IPC (Unix socket).
Do not use tmux-bridge in multi-tenant environments or expose the tmux socket over a network. It is built for the common case: one developer running multiple AI agents side by side on their own machine.
For agents that support custom system prompts, use system-instruction/smux-skill.md. It teaches the read-act-read workflow and documents all available MCP tools.
Project | Approach | Focus |
tmux skill + bash CLI | Agent-agnostic tmux setup | |
WebSocket daemon + MCP plugin | Claude Code <-> Codex | |
tmux-bridge-mcp (this) | Standalone MCP server + direct tmux | Any agent, zero deps beyond tmux |
Dimension | smux | tmux-bridge-mcp (this) |
🔌 How agents connect | Agent runs bash commands ( | Agent uses MCP tool calls ( |
🚀 Agent onboarding | Install skill or inject system prompt to teach bash commands | Add MCP config JSON -- agent auto-discovers 9 tools |
📦 Prerequisites |
| Just tmux + Node.js, |
⚙️ tmux configuration | Ships full tmux.conf (keybindings, mouse, status bar) | Doesn't touch tmux.conf -- no config conflicts |
🛡️ Read guard | Bash CLI layer ( | MCP server layer ( |
💻 Language | Bash (~300 LOC) | TypeScript (~600 LOC) |
📥 Install |
|
|
🤝 Agent compatibility | Any agent that can run bash (needs skill/prompt) | Any agent with MCP support (standard protocol) |
👉 When to use smux: You want a complete tmux setup (keybindings, mouse support, status bar) and your agents support the skills system or you're comfortable injecting system prompts.
👉 When to use tmux-bridge-mcp: You want a drop-in MCP server that works with any MCP-compatible agent out of the box, without touching your tmux configuration.
/tmb) vs Claude Code Native (subagent + /codex + /gemini)Dimension | tmux-bridge | Claude Code Native |
Context isolation | Each pane has its own full conversation context, persists across interactions | subagent spawns fresh each time, gone when it finishes |
Persistence | Pane stays alive, accumulates conversation history | Fire-and-forget, must re-provide context next time |
Parallelism | Truly independent processes, no interference | Agent tool can parallelize, but shares billing/rate limits |
Model diversity | Each pane can run a different CLI (Codex, Gemini, Kimi) |
|
Communication overhead | Goes through tmux read/send, has latency, messages may get truncated | Native tool calls, structured returns, high reliability |
Result integration | You must read pane output, parse, and synthesize manually | subagent returns structured results directly, ready to use |
Operational complexity | Extra layer of tmux management (labels, pane IDs) | One tool call, done |
Cost | Each pane consumes its own token budget independently | subagent shares the same session's token pool |
Verdict
tmux-bridge's real advantage comes down to one thing: persistent context. If you need an agent that remembers the last 30 turns of conversation and keeps following up on the same task, a tmux pane can do that -- a subagent cannot.
But for most tasks, native is better:
Communication is more reliable (no tmux buffer truncation)
Results are structured -- no need to parse terminal output
Simpler to operate, one less layer of abstraction
Practical guidance:
Short-lived, one-off tasks → native subagent / /codex / /gemini
Long-running sessions that need accumulated context (e.g., a reviewer continuously following the same PR) → tmux-bridge adds real value
A multi-pane multi-role layout only pays off if each role genuinely needs cross-conversation state -- otherwise the overhead outweighs the benefit
MIT
Diagnose tmux connectivity issues — checks socket, env vars, and pane visibility
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses exactly what it checks (socket, env vars, pane visibility). As a diagnostic tool, it implicitly indicates read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is highly concise and front-loaded with the primary action ('Diagnose tmux connectivity issues'). Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description adequately conveys the tool's purpose. It could hint at expected output, but not strictly necessary for a diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist. Schema coverage is 100% (empty). Description adds context about the checks performed, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it diagnoses tmux connectivity issues, checking socket, env vars, and pane visibility. It distinguishes well from sibling tools that focus on other tmux actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for connectivity issues but does not explicitly state when to use or not use. No alternatives mentioned despite sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Print the current pane's tmux ID ($TMUX_PANE). Useful for self-identification when labeling.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately describes the tool as printing an ID—a simple read operation with no side effects. The behavior is transparent for the simplicity of the tool, though no additional context (e.g., permissions, edge cases) is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the core action. Every sentence adds value: the first states what it does, the second gives a use case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a trivial action, the description is complete. It explains the tool's purpose and provides a typical use case. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and schema description coverage is 100% (empty). With zero parameters, the description need not add parameter info. The baseline score of 4 is appropriate as the description adds no param details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it prints the tmux ID of the current pane, using a specific verb ('Print') and resource ('tmux ID'). It distinguishes from sibling tools like tmux_name (which likely prints the name) by specifying the output is the ID from $TMUX_PANE.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions 'useful for self-identification when labeling', giving implied context. However, it does not explicitly state when to use this over alternatives (e.g., tmux_name for session name, tmux_resolve for resolving IDs), nor does it provide exclusion criteria. Usage is implied but not fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send special keys to a tmux pane (Enter, Escape, C-c, etc.). Must tmux_read first.
| Name | Required | Description | Default |
|---|---|---|---|
| keys | Yes | Keys to send, e.g. ["Enter"], ["Escape"], ["C-c"] | |
| target | Yes | Pane target: ID (%0), session:win.pane, or label |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool sends keys (mutative) and the prerequisite, but lacks details on side effects, error states, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose with examples, second states prerequisite. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description is fairly complete. It covers action, target, key types, and a prerequisite. Lacks mention of return value or error handling, but acceptable for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions for 'target' and 'keys'. The description adds value by explaining 'special keys' and giving examples (e.g., C-c), which clarifies beyond the schema's generic array type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: sending special keys to a tmux pane. It provides examples (Enter, Escape, C-c) and distinguishes from sibling tools like tmux_type and tmux_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear prerequisite: 'Must tmux_read first.' This guides the agent on proper sequencing. However, it does not mention when not to use this tool or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tmux panes with target ID, process, label, and working directory
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('List'), but with no annotations, it should explicitly state no side effects, authentication needs, or rate limits. The output fields are mentioned, but behavioral traits beyond listing are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no wasted words. Every piece of information (verb, scope, output fields) is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is complete: it explains what the tool returns (4 fields) and the scope ('all tmux panes'), which suffices given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (input schema is empty, coverage 100%). The description adds value by detailing the output fields, which is appropriate when schema offers no param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all tmux panes' with specific output fields (target ID, process, label, working directory). This is a specific verb+resource combination that distinguishes it from sibling tools like tmux_read which likely focuses on a single pane.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives (e.g., tmux_read for individual panes). The description simply states what it does without any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to another agent's pane with auto-prepended sender info, reply target, and correlation ID. Cannot message your own pane (loop prevention). Must tmux_read first.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Message to send | |
| target | Yes | Pane target: ID (%0), session:win.pane, or label |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It reveals that the tool auto-prepends sender info, reply target, and correlation ID, and implements loop prevention. However, it does not mention potential errors, message length limits, or whether the message is persisted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding essential information: action/details, loop prevention, prerequisite. No redundant or extraneous text. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, so the description should compensate by explaining return behavior. It does not mention what the tool returns (e.g., success indicator, error message). For a messaging tool, this is a notable omission that could affect an agent's decision to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have schema descriptions (coverage 100%). The tool description adds context about auto-prepended info, but does not further clarify parameter constraints or format beyond the schema. The schema descriptions for 'text' and 'target' are basic, so the description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send a message to another agent's pane'. It specifies key features (auto-prepended sender info, reply target, correlation ID) and includes restrictions (cannot message own pane). This distinguishes it from sibling tools like tmux_read, tmux_list, etc., which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a prerequisite ('Must tmux_read first') and a constraint ('Cannot message your own pane'). This provides clear guidance on when and how to use the tool, though it does not elaborate on alternative tools for messaging since none exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Label a tmux pane for easy addressing (e.g., 'gemini', 'claude'). The label appears in the tmux border.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Label to assign | |
| target | Yes | Pane target: ID (%0) or session:win.pane |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states that the label appears in the border, omitting details such as whether labels can be overwritten, length limits, or persistence across sessions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, efficient, and includes a concrete example. Every word serves a purpose, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers the basic purpose. However, given the lack of output schema and context from sibling tools, more detail about the effect's permanence or interaction with other tools would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it does not elaborate on parameter formats, constraints, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (label) and resource (tmux pane) with examples, making its purpose evident. However, it does not explicitly distinguish from sibling tools, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a hint for use ('easy addressing') but lacks explicit guidance on when to choose this tool over siblings like tmux_id or tmux_resolve. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the last N lines from a tmux pane. Must be called before type/keys (read guard). Target can be a pane ID (%N), session:window.pane, or a label.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Number of lines to read (default 50) | |
| target | Yes | Pane target: ID (%0), session:win.pane, or label |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the read guard (ordering requirement) but does not mention that the tool is read-only, or any permissions needed. For a simple read tool, this is adequate but could note non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Every sentence earns its place: purpose, read guard, target formats. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 params, no output schema, no nested objects), the description is complete. It covers purpose, usage order, target specification, and default line count. No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both params have descriptions). The description adds value by explaining 'last N lines' (reads from end) and clarifying target formats beyond schema, e.g., 'pane ID (%N), session:window.pane, or a label'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the last N lines from a tmux pane' (specific verb+resource) and distinguishes from siblings like tmux_type (typing) and tmux_list (listing). The target formats and read guard further clarify its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the ordering constraint 'Must be called before type/keys (read guard)' and enumerates valid target formats. Does not provide explicit when-not-to-use advice, but the constraint is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a pane's target ID by its label
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Label to resolve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action without revealing whether it is read-only, what happens on failure, or any side effects. The tool's behavior is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. However, it could be slightly more structured to include key behavioral details while remaining brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is underspecified. It does not explain what a 'target ID' is, what the output format looks like, or any error handling. Given the tool has one parameter and no output schema, more context is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for 'label' is 'Label to resolve', and the tool description adds no additional meaning beyond 'by its label'. Since schema coverage is 100%, baseline is 3, and no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Look up a pane's target ID by its label'. It uses a specific verb ('look up') and specifies the resource ('pane's target ID'), effectively distinguishing it from siblings like tmux_name or tmux_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives like tmux_name or tmux_id. The description lacks any context about prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into a tmux pane WITHOUT pressing Enter. You must tmux_read the pane first (read guard enforced). After typing, use tmux_read to verify, then tmux_keys to press Enter.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to type into the pane | |
| target | Yes | Pane target: ID (%0), session:win.pane, or label |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool types without pressing Enter and mentions a read guard. While edge cases (e.g., special characters) are not covered, the core behavioral trait is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct purpose: (1) what the tool does, (2) prerequisite read guard, (3) follow-up actions. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple type tool with no output schema, the description covers the essential workflow and purpose. It lacks details on character limits or error behavior, but is largely complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described in the schema. The description adds no extra detail beyond schema examples, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Type text into a tmux pane WITHOUT pressing Enter.' It specifies the verb (type) and resource (tmux pane), and distinguishes itself from sibling tools like tmux_keys by emphasizing the lack of Enter key press.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit workflow: read first, then type, then read again, then use tmux_keys to press Enter. It also implies when not to use (if you want to press Enter, use tmux_keys).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0tmux_doctortmux_idtmux_keystmux_listtmux_messagetmux_nametmux_readtmux_resolvetmux_typeScored across 9 tools
Each tool targets a distinct action on tmux panes: labeling, resolving, listing, reading, typing, sending keys, messaging, diagnostics. No two tools overlap in purpose, and the read guard enforces a clear workflow without ambiguity.
All tools follow the 'tmux_' prefix with a concise verb: tmux_name, tmux_resolve, tmux_id, tmux_doctor, tmux_list, tmux_read, tmux_type, tmux_message, tmux_keys. The pattern is uniform and predictable.
With 9 tools, the server covers all core interactions with tmux panes (label, identify, list, read, type, key, message) plus diagnostics. This is a well-scoped set—neither too few nor too many.
The tools cover the essential CRUD-like operations for tmux panes: reading, writing (type/keys), labeling, and listing. Missing would be creating new panes or advanced flush/wait operations, but these are outside the server's stated scope as a bridge.
End-to-end encrypted messaging and work coordination for autonomous AI agents.
Coordination hub for AI coding agents: message teammates, ask humans, audit every event.
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
Let your AI sessions talk to each other — messaging, tasks, sessions, and alerts
