Terminal MCP
Related Servers
Alternatives to Terminal MCP
No user-submitted related servers found.
Related Servers
- FlicenseAqualityDmaintenanceA persistent, stateful MCP server that exposes a detached tmux session to clients, enabling shell command execution, terminal buffer reading, and control signal sending via JSON-RPC over stdio.3-
- FlicenseNot gradedqualityDmaintenanceMCP server for tmux operations that provides comprehensive control over tmux sessions, windows, and panes.1-
- FlicenseAqualityAmaintenanceEnables MCP-based communication with existing interactive terminal channels, such as shells or agent CLIs, by listing, reading, writing text, and sending control signals to tmux sessions without creating or managing them.7-
- AlicenseNot gradedqualityAmaintenanceExposes a Windows or Linux host terminal to remote MCP clients via Streamable HTTP, enabling command execution, tunnel management, and privileged operations with security features like OAuth and audit logging.33 npm2MIT
- AlicenseAqualityAmaintenanceMCP server for SSH and local terminal access. Supports interactive commands, long-running processes, and TUI apps like tmux/zellij63MIT
- AlicenseNot gradedqualityCmaintenanceA fail-closed policy boundary that translates local stdio MCP clients to authenticated Streamable HTTP servers, enforcing allowlists or read-only modes and redacting credentials from audit trails.Apache 2.0
TDQS
Scored across 13 tools
Tools are mostly distinct, with a clear split between direct session operations and logical binding operations. The only mild ambiguity is between terminal_tail and terminal_capture, but their descriptions differentiate recent output from larger scrollback.
All tools share a terminal_ prefix and use snake_case, with a consistent _bound suffix for binding-resolved variants. Minor inconsistencies exist, such as get_binding vs list_bindings and send_bound omitting the _text qualifier used by send_text, but the overall pattern is predictable.
Thirteen tools is well-scoped for a terminal/tmux MCP server. The surface is organized into two coherent families—session inspection/control and persistent bindings—without obvious redundancy or bloat.
The set covers core listing, reading, status, input, and binding lifecycle operations. There are minor gaps such as no bound capture variant and no explicit binding update, but most expected workflows for a restricted terminal interface are supported.