Which integrations are available for this server?

Allows opening interactive shells inside Docker containers and executing commands such as checking logs or running scripts. Enables GitHub Copilot in VS Code to launch and interact with terminal sessions for running development commands and REPLs. Supports running Node.js REPL sessions to test JavaScript code, debug, or perform computations interactively. Supports running Python REPL sessions for calculations, algorithm testing, and interactive scripting.

How do I use mcp-interactive-terminal?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-interactive-terminal Open python REPL and calculate 2**100" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-interactive-terminal

by amol21p

Overview Schema Related Servers Score Discussions

TypeScript

Local

mcp-interactive-terminal

npm version License: MIT Node.js >= 18

MCP server that gives AI agents (Claude Code, Cursor, Windsurf, etc.) real interactive terminal sessions. Run REPLs, SSH, database clients, and any interactive CLI — with clean text output, smart completion detection, and 7-layer security.

Why This Exists

AI coding agents can't handle interactive commands. There's no PTY, no stdin streaming. You can't run rails console, python, psql, ssh, or any REPL through them. This MCP server fixes that.

AI Agent (Claude Code, Cursor, etc.)
    ↕  MCP (JSON-RPC over stdio)
mcp-interactive-terminal
    ↕  node-pty + xterm-headless
Interactive Process (rails console, python, psql, ssh, bash...)
    ↕
Clean text output (exactly what a human would see)

Related MCP server: interactive-process-mcp

Install

Claude Code

claude mcp add terminal -- npx -y mcp-interactive-terminal

That's it. The server is now available. Ask Claude to "open a python REPL and calculate 2**100".

Cursor

Go to Settings > MCP Servers, click Add Server, and enter:

{
  "mcpServers": {
    "terminal": {
      "command": "npx",
      "args": ["-y", "mcp-interactive-terminal"]
    }
  }
}

Windsurf

Add to your MCP configuration:

{
  "mcpServers": {
    "terminal": {
      "command": "npx",
      "args": ["-y", "mcp-interactive-terminal"]
    }
  }
}

VS Code (GitHub Copilot)

Add to your .vscode/mcp.json:

{
  "servers": {
    "terminal": {
      "command": "npx",
      "args": ["-y", "mcp-interactive-terminal"]
    }
  }
}

Any MCP Client

The server communicates over stdio using the Model Context Protocol. Any MCP-compatible client can use it with the same npx -y mcp-interactive-terminal command.

Real-World Examples

Rails Console

You: "Open rails console for staging and check the user count"

Agent creates session → bash
Agent sends: cd /path/to/app && rails console -e staging
Agent sends: User.count
Agent returns: 1,847,293

Python REPL

You: "Open python and test my sorting algorithm"

Agent creates session → python3
Agent sends: def quicksort(arr): ...
Agent sends: quicksort([3, 1, 4, 1, 5, 9])
Agent returns: [1, 1, 3, 4, 5, 9]

Database Client

You: "Connect to postgres and show me the largest tables"

Agent creates session → psql -U myuser mydb
Agent sends: SELECT tablename, pg_size_pretty(pg_total_relation_size(tablename::text)) ...
Agent returns: formatted table of results

SSH

You: "SSH into the staging server and check disk usage"

Agent creates session → ssh user@staging.example.com
Agent sends: df -h
Agent returns: disk usage table

Docker

You: "Open a shell in my running container and check the logs"

Agent creates session → docker exec -it my-container bash
Agent sends: tail -100 /var/log/app.log
Agent returns: last 100 log lines

Node.js REPL

You: "Open node and test the date parsing logic"

Agent creates session → node
Agent sends: new Date('2024-02-29').toISOString()
Agent returns: 2024-02-29T00:00:00.000Z

Tools

The server exposes 7 MCP tools:

`create_session` — Spawn an interactive process

{ "command": "python3", "name": "my-python", "cwd": "/project" }
→ { "session_id": "a1b2c3d4", "name": "my-python", "pid": 12345 }

Parameter	Required	Default	Description
`command`	Yes	—	Command to run (bash, python3, psql, ssh, etc.)
`args`	No	`[]`	Command arguments
`name`	No	auto	Human-readable session name
`cwd`	No	server cwd	Working directory
`env`	No	`{}`	Additional environment variables
`cols`	No	`120`	Terminal columns
`rows`	No	`40`	Terminal rows

`send_command` — Send input and get output

{ "session_id": "a1b2c3d4", "input": "1 + 1" }
→ { "output": "2", "is_complete": true, "is_alive": true }

Parameter	Required	Default	Description
`session_id`	Yes	—	Target session
`input`	Yes	—	Command/input to send (newline appended automatically)
`timeout_ms`	No	`5000`	Max wait time for output
`max_output_chars`	No	`20000`	Truncate output beyond this

Dangerous commands (rm -rf, DROP TABLE, curl|bash, etc.) are blocked — the agent must use confirm_dangerous_command first.

`read_output` — Read terminal screen (read-only)

{ "session_id": "a1b2c3d4" }
→ { "output": ">>> ", "is_alive": true }

Safe to auto-approve — this only reads, never sends input.

`list_sessions` — List active sessions (read-only)

→ [{ "session_id": "a1b2c3d4", "name": "my-python", "command": "python3", "pid": 12345, "is_alive": true }]

Safe to auto-approve.

`close_session` — Kill a session

{ "session_id": "a1b2c3d4" }
→ { "success": true }

`send_control` — Send control characters

{ "session_id": "a1b2c3d4", "control": "ctrl+c" }
→ { "output": "^C\n>>>" }

Supported: ctrl+c, ctrl+d, ctrl+z, ctrl+l, ctrl+r, tab, escape, up, down, left, right, enter, backspace, delete, home, end, and more.

`confirm_dangerous_command` — Two-step safety confirmation

{ "session_id": "a1b2c3d4", "input": "rm -rf /tmp/old", "justification": "Cleaning up stale temp files from failed build" }
→ { "output": "...", "is_complete": true, "is_alive": true }

Required when send_command detects a dangerous pattern. The agent must explain why the command is necessary. This is a separate tool — even if send_command is auto-approved, this requires its own permission.

How It Works

Two Terminal Modes

PTY mode (default) — uses node-pty + @xterm/headless (the same terminal emulator as VS Code):

Clean output — the AI sees exactly what a human would see on screen
Cursor positioning, progress bars, \r overwrites all render correctly
Full keyboard: arrow keys, tab completion, ctrl+c/d/z, home/end
Terminal resize, TUI apps (vim, htop, top), 256-color, 1000-line scrollback

Pipe mode (automatic fallback) — activates when node-pty can't load (e.g., in sandboxed environments):

Interactive sessions still work via child_process.spawn with auto-injected flags (python -u -i, bash -i, etc.)
ANSI codes stripped, control keys still work
No terminal emulation, but covers the basics

The mode is selected automatically — PTY is tried first, pipe mode kicks in if it fails.

What the AI sees: PTY vs Pipe

Scenario	PTY mode	Pipe mode
`printf "\rProgress: 3/3"`	`Progress: 3/3`	`Progress: 1/3Progress: 2/3Progress: 3/3`
ANSI colors	Stripped cleanly	Stripped via regex
vim, htop, top	Readable screen	Garbled
Arrow keys, tab completion	Works	Works
Terminal resize	Works	No-op

Smart "Command Done" Detection

Instead of blindly waiting a fixed time, the server uses a layered strategy:

Process exit — if the process died, command is done
Prompt detection — auto-detects the session's prompt at startup (bash $, python >>>, psql #, etc.), watches for it to reappear
Output settling — no new output for 300ms = probably done
Timeout — always returns after timeout_ms with is_complete: false

Security

Seven-layer defense-in-depth:

Layer	What It Does	Default
MCP Tool Annotations	`readOnlyHint`/`destructiveHint` on each tool	Always on
Confirmation Flow	Dangerous patterns require `confirm_dangerous_command`	Always on
Input Pattern Detection	Detect rm -rf, DROP TABLE, curl\|bash, etc.	Always on
Command Blocklist/Allowlist	Block/allow specific commands	Configurable
OS-Level Sandbox	Kernel-level process sandboxing via `@anthropic-ai/sandbox-runtime`	Off (opt-in)
Secret Redaction	Redact AWS keys, tokens, private keys in output	Off (opt-in)
Resource Limits	Max sessions, output cap, idle timeout, audit logging	Always on

Recommended Permissions

Only auto-approve the read-only tools:

{
  "permissions": {
    "allow": [
      "mcp__terminal__list_sessions",
      "mcp__terminal__read_output"
    ]
  }
}

This way send_command, create_session, and especially confirm_dangerous_command always require human approval.

Configuration

All settings via environment variables. Pass them in your MCP config:

{
  "mcpServers": {
    "terminal": {
      "command": "npx",
      "args": ["-y", "mcp-interactive-terminal"],
      "env": {
        "MCP_TERMINAL_ALLOWED_COMMANDS": "bash,python3,node,psql",
        "MCP_TERMINAL_REDACT_SECRETS": "true",
        "MCP_TERMINAL_IDLE_TIMEOUT": "300000"
      }
    }
  }
}

Variable	Default	Description
`MCP_TERMINAL_MAX_SESSIONS`	`10`	Max concurrent sessions
`MCP_TERMINAL_MAX_OUTPUT`	`20000`	Max output chars per read
`MCP_TERMINAL_DEFAULT_TIMEOUT`	`5000`	Default wait timeout (ms)
`MCP_TERMINAL_BLOCKED_COMMANDS`	—	Comma-separated blocklist
`MCP_TERMINAL_ALLOWED_COMMANDS`	—	Comma-separated allowlist (if set, only these are allowed)
`MCP_TERMINAL_ALLOWED_PATHS`	—	Comma-separated paths sessions can access
`MCP_TERMINAL_REDACT_SECRETS`	`false`	Redact AWS keys, tokens, private keys in output
`MCP_TERMINAL_LOG_INPUTS`	`false`	Log all inputs to stderr (for debugging)
`MCP_TERMINAL_IDLE_TIMEOUT`	`1800000`	Auto-close idle sessions (ms, default 30min, 0 = disabled)
`MCP_TERMINAL_DANGER_DETECTION`	`true`	Enable dangerous command confirmation flow
`MCP_TERMINAL_AUDIT_LOG`	—	Path to JSON audit log file
`MCP_TERMINAL_SANDBOX`	`false`	Enable OS-level kernel sandboxing
`MCP_TERMINAL_SANDBOX_ALLOW_WRITE`	`/tmp`	Writable paths in sandbox mode
`MCP_TERMINAL_SANDBOX_ALLOW_NETWORK`	`*`	Allowed network domains in sandbox

Troubleshooting

"Tools not showing up" / Server fails silently

MCP servers that fail to start often show no error in the client. Check:

# Test the server directly:
npx -y mcp-interactive-terminal

# You should see "[mcp-terminal] Starting MCP Interactive Terminal Server" on stderr.
# If you see an error, that's what's failing.

Node.js version too old

The server requires Node.js >= 18. If you see errors about unsupported syntax or missing APIs:

node --version  # Must be >= 18

# If using nvm:
nvm install 18 && nvm use 18

# If using volta:
volta install node@18

For nvm/volta/fnm users: npx may use a different Node version than your shell. Use an absolute path:

{
  "mcpServers": {
    "terminal": {
      "command": "/Users/you/.nvm/versions/node/v22.0.0/bin/npx",
      "args": ["-y", "mcp-interactive-terminal"]
    }
  }
}

Find your path with: which npx

node-pty compilation errors

node-pty is a native module that requires build tools. If it fails to compile, the server automatically falls back to pipe mode — interactive sessions still work, just without terminal emulation.

If you want full PTY support:

# macOS:
xcode-select --install

# Ubuntu/Debian:
sudo apt-get install -y make python3 build-essential

# RHEL/Fedora:
sudo yum install -y make python3 gcc gcc-c++

Session dies immediately

Some commands need to be run inside a shell rather than directly:

# Instead of:  create_session({ command: "rails console -e staging" })
# Do this:     create_session({ command: "bash" })
#              send_command({ input: "rails console -e staging" })

This is because create_session runs the command directly (like exec), not through a shell. Spawning bash first gives you a full shell environment.

Output looks garbled

If output contains escape codes or looks wrong, you're likely in pipe mode (node-pty failed to load). Check the server logs for "falling back to pipe mode". Install build tools (see above) to enable PTY mode.

Timeout too short for long-running commands

Increase the timeout per-command:

{ "session_id": "...", "input": "bundle install", "timeout_ms": 60000 }

Or globally via environment variable:

{ "env": { "MCP_TERMINAL_DEFAULT_TIMEOUT": "30000" } }

Comparison with Alternatives

Feature	mcp-interactive-terminal	App-specific terminal servers	Generic shell MCP servers
Cross-platform	Yes	Often single-app only	Varies
Clean output (xterm-headless)	Yes	No (screen scrape)	No (raw PTY dump)
Smart completion detection	4-layer algorithm	No	Basic timeout
Security layers	7 (confirmation flow, sandbox, redaction, etc.)	None	Basic
Dangerous command confirmation	Yes (separate tool)	No	No
MCP tool annotations	Yes	No	No
Background sessions	Yes	No (uses active tab)	Yes
Focused API	7 tools	2-3 tools	15-20+ tools (scope creep)
Install	`npx -y` (zero-config)	Requires specific app	Varies

Development

git clone https://github.com/amol21p/mcp-interactive-terminal.git
cd mcp-interactive-terminal
npm install
npm run build
npm test

Test with MCP Inspector:

npx @modelcontextprotocol/inspector dist/index.js

License

MIT

Available Tools

7 tools

close_sessionB

DestructiveIdempotent

Close/kill an interactive terminal session.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes	The session ID to close
`signal`	No	Signal to send (e.g., SIGTERM, SIGKILL)	SIGTERM

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide destructiveHint=true and idempotentHint=true. The description adds 'close/kill' but no further behavioral details beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with a single phrase, containing no unnecessary words. However, it could be structured better with separate purpose and action guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple destructive tool with annotations, the description is adequate but lacks information about irreversibility or side effects. No output schema is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters described. The description does not add any additional meaning beyond the schema's definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses clear action verbs ('Close/kill') and specifies the resource ('interactive terminal session'), effectively distinguishing it from sibling tools like create_session or list_sessions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, such as confirm_dangerous_command for destructive actions. The description lacks any context about prerequisites or scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

confirm_dangerous_commandA

Destructive

Execute a command that was flagged as dangerous by send_command. Requires a justification explaining WHY the command is necessary. This is a separate confirmation step for safety.

ParametersJSON Schema

Name	Required	Description
`session_id`	Yes	The session ID
`input`	Yes	The exact dangerous command to confirm and execute
`justification`	Yes	Explanation of WHY this dangerous command is necessary (min 10 chars)

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true, so the description adds value by explaining the safety confirmation step and the need for justification, which is not redundant. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three short sentences, front-loading the main action and purpose without any unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the schema covering all parameters with descriptions, the description is complete enough. It could mention what happens after execution (e.g., output), but no output schema exists, so the current level is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with descriptions for all parameters. The description does not add significant extra meaning beyond what the schema already provides, such as the 'justification' parameter's minLength constraint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool executes a dangerous command after confirmation, distinguishing it from sibling 'send_command' by emphasizing the confirmation step. It uses specific verb 'execute' and resource 'command flagged as dangerous'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that the tool is used after a command is flagged as dangerous and requires a justification, but it doesn't explicitly state when not to use it or provide alternative tools, which would be helpful for an AI agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_sessionA

Spawn an interactive terminal session (REPL, shell, database client, SSH, etc.). Returns a session_id for subsequent commands.

ParametersJSON Schema

Name	Required	Description
`command`	Yes	The command to spawn (e.g., 'python3', 'bash', 'psql')
`args`	No	Arguments to pass to the command
`name`	No	Human-readable session name
`cwd`	No	Working directory for the session
`env`	No	Additional environment variables
`cols`	No	Terminal width in columns
`rows`	No	Terminal height in rows

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate openWorldHint=true and non-idempotent. The description adds no extra behavioral context (e.g., resource lifecycle, cleanup needs). Given annotations, the description provides adequate but minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and output. Efficient and clear, though could benefit from a slightly more structured breakdown of use cases.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but the description mentions returning a session_id. With 7 parameters including nested objects, the description could provide more context on session lifecycle or error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool spawns an interactive terminal session with examples (REPL, shell, database client, SSH). It mentions returning a session_id, which differentiates it from sibling tools like close_session or send_command that operate on existing sessions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for subsequent commands, providing clear context. It could explicitly state when not to use or mention prerequisites, but the sibling tool names (e.g., send_command) help infer the workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_sessionsA

Read-onlyIdempotent

List all active interactive terminal sessions. Safe read-only operation.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds 'Safe read-only operation' which reinforces but does not add new behavioral context. With thorough annotations, this is adequate but not enhancing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two short phrases that fully describe purpose and safety. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema or parameters, description covers the core what and safety. However, it does not specify what details about sessions are returned (e.g., IDs, timestamps), which would help an agent. Missing a minor detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema; schema coverage is 100% by default. Baseline for 0 params is 4, but with high schema coverage baseline is 3. Description adds no parameter info, but none is needed since there are none.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'List all active interactive terminal sessions', specifying the verb (List) and resource (active interactive terminal sessions). This distinguishes from sibling tools like close_session or send_command.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use vs alternatives. The description implies usage for viewing active sessions, but lacks exclusions or comparison to siblings. Context signals show sibling tools exist but are not referenced.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_outputA

Read-onlyIdempotent

Read the current terminal screen without sending any input. Safe read-only operation.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes	The session ID to read output from
`full_screen`	No	Read full scrollback history instead of just the visible screen

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds only 'safe read-only operation' which repeats annotations without new behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise single sentence plus tagline, no unnecessary words, front-loaded with key action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate given rich annotations and full schema coverage; could briefly mention that full_screen retrieves scrollback history, but not essential.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters. Description adds no extra meaning beyond the schema, so baseline score applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Read the current terminal screen' with specific verb and resource, and distinguishes from sibling tools like send_command by emphasizing 'without sending any input'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implicitly tells when to use (reading output) and not to use (sending input), but lacks explicit comparison to alternatives like confirm_dangerous_command.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_commandA

Destructive

Send a command/input to an interactive session and wait for output. Appends newline automatically. Returns clean text output (no ANSI codes). If a dangerous command is detected, you must use confirm_dangerous_command first.

ParametersJSON Schema

Name	Required	Description
`session_id`	Yes	The session ID to send input to
`input`	Yes	The command/input to send (newline appended automatically)
`timeout_ms`	No	Max time to wait for output (ms)
`max_output_chars`	No	Override max output characters for this call

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds behavioral context beyond annotations: automatically appending newline, returning clean text without ANSI codes, and requiring confirmation for dangerous commands. Annotations already indicate destructive potential, and the description reinforces safe usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long with no filler. It front-loads the core action, then adds key behaviors. Every sentence provides value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so the description should explain return format. It says 'Returns clean text output (no ANSI codes),' but does not specify output structure, length limits, or error handling. Given the tool's complexity, more detail would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are already well-documented. The description adds minimal extra meaning beyond the schema, such as the automatic newline and clean output, which are not parameter-specific.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Send a command/input to an interactive session and wait for output.' It uses a specific verb and resource, and distinguishes from siblings by mentioning the dangerous command workflow and output characteristics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on when to use this tool (sending commands) and explicitly notes that for dangerous commands, confirm_dangerous_command must be used first. However, it does not contrast with sibling tools like read_output or send_control.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_controlA

Idempotent

Send a control character or special key to a session (e.g., ctrl+c to interrupt, ctrl+d to send EOF, arrow keys, tab for completion).

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes	The session ID
`control`	Yes	Control sequence to send. Supported: ctrl+a, ctrl+b, ctrl+c, ctrl+d, ctrl+e, ctrl+f, ctrl+k, ctrl+l, ctrl+n, ctrl+p, ctrl+r, ctrl+u, ctrl+w, ctrl+z, ctrl+\, ctrl+], enter, tab, escape, up, down, right, left, home, end, backspace, delete

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate idempotentHint=true and destructiveHint=false. The description does not add behavioral context beyond listing supported controls; it does not disclose side effects, such as process termination or state changes, nor does it contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, front-loaded sentence that efficiently communicates purpose and examples. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and 100% schema coverage, the description adequately covers the tool's purpose and typical use cases. Minor gaps: no mention of behavior on invalid session or control sequence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters with descriptions. The tool description adds value by giving functional examples (e.g., ctrl+c to interrupt) that explain the effect of certain controls, enhancing understanding beyond the schema's enumeration.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly specifies the tool sends control characters or special keys to a session, with concrete examples like ctrl+c and ctrl+d. It distinguishes itself from sibling tools like send_command (which sends typed commands) and read_output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for sending control sequences (e.g., to interrupt or send EOF), but does not explicitly state when to use this tool versus alternatives like send_command or confirm_dangerous_command. No exclusions or context are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: create_session spawns a session, list_sessions shows active ones, send_command sends input, send_control handles special keys, read_output reads the screen, confirm_dangerous_command is a safety step, and close_session terminates. No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., create_session, send_command, read_output). Verbs are imperative and nouns are session-related, with no mixing of conventions.

Tool Count5/5

Seven tools cover the full lifecycle of interactive terminal sessions—creation, listing, input/output, control, safety confirmation, and closure—without unnecessary extras or missing essentials.

Completeness5/5

The set provides a complete CRUD-like cycle: create, list, interact (send command/control), read output, and close. The inclusion of confirm_dangerous_command adds safety without leaving gaps.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
Apuchat A
io.github.opcastil11
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
Communication Agent Orchestration
181
supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1
mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

mcp-server-terminal
App Automation Shell Access
aybelatchane
A
license
Not graded
quality
B
maintenance
MCP server enabling AI agents to interact with terminal applications through structured Terminal State Tree representation. Works with any AI assistant that supports the Model Context Protocol.
Updated 8 months ago (2026-01-02 11:04 UTC)
86
19
MIT
interactive-process-mcp
Shell Access Command Line
UserB1ank
A
license
A
quality
C
maintenance
MCP server for managing interactive processes, enabling AI agents to start, interact with, and terminate long-running programs like SSH sessions, REPLs, and installers via read/write operations.
Updated 4 months ago (2026-05-06 02:14 UTC)
8
8
MIT
can-see
Command Line Shell Access Testing & QA Tools
HurleySk
A
license
Not graded
quality
C
maintenance
MCP server that lets AI agents see and interact with terminal/CLI applications through virtual terminals and PNG screenshots.
Updated 3 months ago (2026-05-22 17:42 UTC)
153
MIT
mcp-remote-ssh
Command Line Shell Access
faizbawa
A
license
A
quality
A
maintenance
MCP server giving AI agents full SSH access with persistent sessions, structured command output, SFTP file transfer, and port forwarding.
Updated 18 days ago (2026-08-17 06:29 UTC)
18
9
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/amol21p/mcp-interactive-terminal'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

mcp-interactive-terminal

Why This Exists

Install

Claude Code

Cursor

Windsurf

VS Code (GitHub Copilot)

Any MCP Client

Real-World Examples

Rails Console

Python REPL

Database Client

SSH

Docker

Node.js REPL

Tools

create_session — Spawn an interactive process

send_command — Send input and get output

read_output — Read terminal screen (read-only)

list_sessions — List active sessions (read-only)

close_session — Kill a session

send_control — Send control characters

confirm_dangerous_command — Two-step safety confirmation

How It Works

Two Terminal Modes

What the AI sees: PTY vs Pipe

Smart "Command Done" Detection

Security

Recommended Permissions

Configuration

Troubleshooting

"Tools not showing up" / Server fails silently

Node.js version too old

node-pty compilation errors

Session dies immediately

Output looks garbled

Timeout too short for long-running commands

Comparison with Alternatives

Development

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`create_session` — Spawn an interactive process

`send_command` — Send input and get output

`read_output` — Read terminal screen (read-only)

`list_sessions` — List active sessions (read-only)

`close_session` — Kill a session

`send_control` — Send control characters

`confirm_dangerous_command` — Two-step safety confirmation