smart-terminal-mcp 1.2.3 → 1.2.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +44 -16
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -4,24 +4,52 @@ A PTY-based MCP server with strong Windows support that gives AI agents (Claude,
|
|
|
4
4
|
|
|
5
5
|
Unlike simple `exec`-based approaches, this provides full PTY sessions with bidirectional communication, enabling interactive CLI tools, incremental terminal reads, and PTY-backed terminal behavior.
|
|
6
6
|
|
|
7
|
+
## Why use this instead of your AI client's built-in terminal?
|
|
8
|
+
|
|
9
|
+
Install this if you want a more consistent terminal workflow across different AI clients, not just whatever built-in terminal behavior one client happens to provide.
|
|
10
|
+
|
|
11
|
+
This MCP is most useful when you want:
|
|
12
|
+
|
|
13
|
+
- **The same workflow across multiple agent platforms** -- If you move between Claude Code, Cursor, Trae, Antigravity, or other MCP-capable clients, the terminal tools stay the same.
|
|
14
|
+
- **Less client-specific behavior** -- Prompts, instructions, and habits do not need to depend as much on one client's terminal UI or quirks.
|
|
15
|
+
- **Reusable prompts, playbooks, and instructions** -- A workflow built around tools like `terminal_wait`, `terminal_retry`, `terminal_run_paged`, or `terminal_get_history` is easier to reuse across teams and clients.
|
|
16
|
+
- **Reusable tooling with less lock-in** -- The terminal layer lives in MCP tools rather than in one client's built-in terminal behavior.
|
|
17
|
+
- **Persistent terminal state** -- Keep the same shell session alive across steps, including the current folder, environment, and running processes.
|
|
18
|
+
- **Better interactive behavior** -- Handle prompts, REPLs, dev servers, Ctrl+C, arrow keys, and other real terminal interactions.
|
|
19
|
+
- **More control over large output** -- Truncate, page, diff, retry, wait for patterns, or fetch history instead of dumping everything at once.
|
|
20
|
+
- **More predictable automation** -- Use deterministic completion markers instead of guessing when a command is done.
|
|
21
|
+
|
|
22
|
+
If your AI client already gives you a stable, stateful, interactive terminal with good output handling, you may not need this MCP for basic command execution. The main reason to add it is to make terminal-driven workflows more explicit, reusable, and portable across clients.
|
|
23
|
+
|
|
7
24
|
## Features
|
|
8
25
|
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
- **
|
|
14
|
-
- **
|
|
15
|
-
- **
|
|
16
|
-
- **
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
- **
|
|
21
|
-
- **
|
|
22
|
-
- **
|
|
23
|
-
- **Best-effort progress notifications** --
|
|
24
|
-
- **
|
|
26
|
+
Think of this as a **controlled keyboard + screen for AI**. It can open a real terminal, type commands, read the results, and keep working in the same session.
|
|
27
|
+
|
|
28
|
+
### Core terminal features
|
|
29
|
+
|
|
30
|
+
- **Interactive terminal sessions** -- Keeps a real terminal open so the AI can type, read output, and continue where it left off.
|
|
31
|
+
- **Deterministic command completion** -- `terminal_exec` uses unique markers so it can tell when a command has finished.
|
|
32
|
+
- **Clean output** -- Pre-command markers help keep returned output readable, even when shells echo commands or expand aliases.
|
|
33
|
+
- **Working directory tracking** -- `terminal_exec` reports the current folder after each command.
|
|
34
|
+
|
|
35
|
+
### Long output and long-running commands
|
|
36
|
+
|
|
37
|
+
- **Interactive reads and writes** -- `terminal_write` + `terminal_read` support prompts, REPLs, and other interactive programs.
|
|
38
|
+
- **Pattern waiting** -- `terminal_wait` can pause until specific text appears, such as `server listening on port`.
|
|
39
|
+
- **Retry helper** -- `terminal_retry` can re-run flaky commands with bounded backoff and optional output matching.
|
|
40
|
+
- **Best-effort progress notifications** -- Long `terminal_exec` / `terminal_wait` calls can emit `notifications/progress` when the client provides a progress token.
|
|
41
|
+
- **Output truncation** -- `terminal_exec` and `terminal_read` shorten very large output by showing the beginning and the end.
|
|
42
|
+
- **Paged read-only output** -- `terminal_run_paged` lets clients fetch large read-only output one page at a time.
|
|
43
|
+
- **Output diffing** -- `terminal_diff` compares two command results and returns a unified diff.
|
|
44
|
+
|
|
45
|
+
### Safety and usability
|
|
46
|
+
|
|
47
|
+
- **Safer one-shot commands** -- `terminal_run` executes real binaries with `cmd + args` and `shell=false`.
|
|
48
|
+
- **Structured parsers** -- Some supported read-only commands can return both raw text and parsed output.
|
|
49
|
+
- **Blocking mitigations** -- Disables pagers (`GIT_PAGER=cat`, `PAGER=cat`), suppresses PowerShell progress output, and sets UTF-8 for `cmd.exe` on Windows.
|
|
50
|
+
- **Special key support** -- Can send Ctrl+C, Tab, arrow keys, and similar keys without manually building escape codes.
|
|
51
|
+
- **Session management** -- Supports named sessions, idle cleanup, and up to 10 concurrent sessions.
|
|
52
|
+
- **Shell auto-detection** -- Windows: `pwsh.exe` > `powershell.exe` > `cmd.exe`. Linux/macOS: `$SHELL` > `bash` > `sh`.
|
|
25
53
|
|
|
26
54
|
Progress notifications are not the same as full stdout streaming: they currently send periodic status updates for `terminal_exec` and `terminal_wait`, typically based on elapsed time and the latest output line. Whether you actually see them depends on your MCP client.
|
|
27
55
|
|