agent-runtime-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TMUX_TIMEOUT_MS | No | Timeout in milliseconds for tmux backend operations (e.g., command execution or reads). | |
| TMUX_SOCKET_NAME | No | Name of the tmux socket to connect to (e.g., 'agent-runtime'). Used to discover existing tmux servers. | |
| TMUX_SOCKET_PATH | No | Full path to the tmux socket, if not using the default socket path. | |
| TMUX_MAX_CHANNELS | No | Maximum number of channels (tmux panes) that can be exposed by the MCP server. | |
| TMUX_READ_MAX_BYTES | No | Maximum number of bytes that can be read from a channel in a single operation. | |
| TMUX_READ_MAX_LINES | No | Maximum number of lines that can be read from a channel in a single operation. | |
| TMUX_ALLOWED_SESSIONS | No | Comma-separated list of tmux session names that the MCP server is allowed to access. Enforces scope restrictions. | |
| TMUX_READ_DEFAULT_LINES | No | Default number of lines to read from a channel's output when no explicit limit is provided. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_channelsA | List existing terminal channels visible in the configured backend scope. |
| get_channelA | Inspect mechanical metadata and capabilities for one terminal channel. |
| read_channelA | Read bounded recent terminal output from one channel without waiting for semantic completion. |
| write_textA | Deliver bounded ordinary Unicode terminal text to one existing channel. LF/TAB are allowed; explicit controls use send_control. |
| send_controlA | Send one explicit reviewed terminal control to an existing channel. |
| healthA | Report mechanical backend/service health independently of Channel inventory or application state. |
| wait_channel_eventB | Wait for mechanically observed Channel snapshot activity followed by bounded quiet; never infers completion. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool targets a distinct action: listing, inspecting, reading, writing, controlling, waiting, and health checking are all separable. The only mild ambiguity is between wait_channel_event and read_channel, but the descriptions clearly separate waiting for activity from reading output.
Most tools follow a clear verb_noun pattern: get_channel, list_channels, read_channel, send_control, write_text. The exception is health, which breaks the pattern by being a bare noun rather than something like get_health or check_health.
Seven tools is a well-scoped size for a terminal-channel runtime. Each tool covers a meaningful operation without redundancy or bloat.
The surface covers the core interaction lifecycle for existing channels: inspect, list, read, write, control, and wait. Channel creation/teardown is not exposed, but that may intentionally live outside this server's scope, so it is a minor rather than critical gap.