Labsco
MCP SERVER

MCP TUIKit

by dragoscirjan ↗

Let an agent drive a terminal application — launch nvim or btop in an isolated session, send keystrokes, wait for output, and take a text or PNG snapshot of the screen.

Editors, Terminals & Local Dev Environment✓ Verified
Summary
A real PTY the agent can type into and look at, isolated from the terminal you are using.

Sessions run inside tmux, so an agent poking at vim cannot disturb your own shell, and the screen comes back either as text or as an actual rendering — which is the difference between checking that output appeared and checking that a TUI drew correctly. The YAML flow is the practical upgrade for repeatable work: the whole spawn-wait-type-snapshot sequence executes server-side instead of costing a round trip per keystroke. Check the dependency tool first; what works headlessly depends heavily on the OS and backend.

What it is

Terminal automation over tmux. Each session runs isolated from your own shell, and the agent sees the result either as a text grid or as a screenshot of the rendered terminal.

What you get
  • A session created around a command, with the column and row size you choose, and closed again when done
  • Keystrokes sent in tmux notation, so an agent can drive vim, a menu or a prompt the way a person would
  • A wait on a regular expression appearing in the output, with a timeout — the piece that makes a scripted interaction reliable rather than racy
  • Snapshots as text, PNG, or both, so the agent can read the screen state or actually see how it rendered
  • A whole interaction run from a YAML flow — spawn, wait for a pattern, send keys, snapshot — either from a file or inline, which avoids a round trip per keystroke
  • Active sessions listed with their state, and the raw terminal buffer readable as a resource
  • A dependency check that tells you whether the host has what the configured backend needs
Requirements

Tmux, which is what holds the sessions — brew install tmux on macOS, the distribution package on Linux, and on Windows a native Win32 port rather than the MSYS2 or WSL build. Run it with npx -y @dragoscirjan/mcp-tuikit over stdio, from the npm package @dragoscirjan/mcp-tuikit. The backend decides where the terminal is actually rendered: xterm.js through a headless Playwright Chromium, or a native emulator — Alacritty, WezTerm, Kitty, Ghostty, Terminal.app, iTerm2 — picked from your OS and what is installed, and forced with MCP_TUIKIT_BACKEND. On Linux, native headless rendering needs a virtual compositor: Xvfb with imagemagick for X11, or sway or kwin with grim for Wayland. On macOS and Windows there is no true headless mode for native emulators, so spawning one pops a real window on screen — the xterm.js backend is the way to stay silent. Only static text and PNG snapshots are captured; there is no video recording.

Setup effort

One command — npx -y @dragoscirjan/mcp-tuikit