check_system_dependencies
Check if the host system has all required dependencies for mcp-tuikit to run properly.
LABSCO 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
USE CASES
01
Testing that a CLI behaves the way you expect
Launch it in a session, type the input, wait for the expected output, and capture the screen.
02
Checking a TUI actually renders correctly
Run it and take a PNG snapshot, rather than inferring from text output that it looked right.
03
Running the same interaction repeatedly without a round trip per key
Write the sequence as a YAML flow and run it in one call, with the snapshots captured along the way.
04
Letting an agent operate an interactive program
Send keys, wait for the screen to settle, read it, and decide the next move.
05
Working out why nothing renders on this machine
Run the dependency check for the configured backend before debugging further.
06
Cleaning up after an automation run
List what is still open and close the sessions you are done with.
8 tools
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
close_session
Close a terminal session and its terminal window.
create_session
Create a new terminal session and open the configured terminal window.
create_snapshot
Capture a txt and/or png snapshot from an active session.
list_sessions
List all active terminal sessions.
run_flow
Run a TUI flow and capture snapshots.
send_keys
Send keystrokes to an active terminal session.
wait_for_text
Wait for a regex pattern to appear in the terminal output.
BEFORE YOU INSTALL
What to know first
Tools you get
8 tools when we connected. Spawn, wait_for, type, send_key, sleep and snapshot are steps inside a run_flow document, not separate tools.
Requires
- npx on PATH
- tmux 3.3a or later (3.5a recommended)
Where it runs
All 4 documented clients run the server on your machine.
CONTEXT COST
Light Standing cost
Rated by the size of the 8 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
Connect your client
Server setup
TERMINAL
npx -y @dragoscirjan/mcp-tuikitMCP Clients
Claude Code
CLAUDE CODE · TERMINAL
claude mcp add mcp-tuikit -- npx -y @dragoscirjan/mcp-tuikitCursor, Windsurf
JSON
{
"mcpServers": {
"mcp-tuikit": {
"command": "npx",
"args": [
"-y",
"@dragoscirjan/mcp-tuikit"
]
}
}
}OpenCode
OPENCODE · JSON
{
"mcp": {
"mcp-tuikit": {
"type": "local",
"command": [
"npx",
"-y",
"@dragoscirjan/mcp-tuikit"
]
}
}
}
