What can you do with this server?

The interactive-process-mcp server enables AI agents to start, control, and interact with long-running terminal processes via SSE over HTTP transport (allowing agents and server to run on different machines). * Start processes (start_process): Launch any command in PTY (full terminal emulation) or pipe mode, with configurable working directory, environment variables, terminal size, and startup timeout. * Send input (send_input): Write text to a running process's stdin, optionally appending a newline. * Read output (read_output): Retrieve new output since the last read, with configurable timeout, line limits, and optional ANSI escape code stripping. * Atomic send & read (send_and_read): Combine sending input and reading the response in a single operation — ideal for SSH sessions or REPLs. * List & inspect sessions (list_sessions, get_session_info): View all active/past sessions and retrieve metadata (status, PID, exit code, command, timestamps). * Terminate processes (terminate_process): Stop a process gracefully (SIGTERM) or forcefully (SIGKILL) with a configurable grace period. * Resize terminal (resize_pty): Dynamically adjust PTY dimensions (rows/columns) for terminal-aware programs like top or htop. * Multi-agent collaboration (register_reader, unregister_reader): Multiple agents can independently read output from the same session, each maintaining its own output cursor. * Session persistence (list_messages, get_message): Sessions and I/O are stored to local JSON files, enabling message history retrieval for auditing or debugging. * Cleanup: Delete exited sessions to free resources.

How do I use interactive-process-mcp?

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., "@interactive-process-mcp start an SSH session to user@host" 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.

de en es ja ko ru zh

interactive-process-mcp

by UserB1ank

Overview Schema Related Servers Score Discussions

Local

interactive-process-mcp

Introduction

interactive-process-mcp is an MCP (Model Context Protocol) server that enables AI Agents (like Claude Code) to start, control, and manage long-running interactive processes.

Why Do You Need It?

AI Agents can natively only execute one-shot commands — they run and immediately return results. But many real-world scenarios require multi-turn interaction:

SSH into a remote server, enter a password first, then run commands
Debug code line by line in a Python REPL
Answer [Y/n] prompts in interactive installers
Use terminal-dependent commands like top, htop
Run security tools (e.g., impacket) for multi-step operations

In these scenarios, the process keeps running, and the AI Agent needs to repeatedly read and write the process's I/O across multiple conversation turns. interactive-process-mcp is the bridge designed precisely for this purpose.

Key Features

Feature	Description
Multi-agent session sharing	Multiple AI agents read from the same session simultaneously, each with an independent cursor — no output stealing
PTY and Pipe dual mode	PTY mode emulates a real terminal; Pipe mode for simple stdin/stdout interaction
Remote deployment	SSE over HTTP transport — Agent and Server can run on different machines
Multi-session management	Manage multiple independent processes simultaneously without interference
Message persistence	Session records and I/O messages persisted to local JSON files
ANSI escape code stripping	Optional automatic removal of terminal control sequences for clean text output
Blocking reads with timeout	Agents wait for new output up to a configurable timeout; returns promptly via sync.Cond
Atomic send-and-read	`send_and_read` combines sending + reading in one step
Graceful termination	SIGTERM first, then SIGKILL after a configurable grace period
PTY resize	Dynamically adjust terminal rows and columns at runtime
Session cleanup	Delete exited sessions to prevent resource accumulation

Related MCP server: MCP Shell Server

Architecture

┌──────┐  SSE/HTTP  ┌──────────────┐  Internal SSH  ┌──────────┐
│Agent │ ──────────> │ Go Server    │ ──────────────> │ PTY/     │
│(MCP) │             │ - MCP API    │  (localhost)    │ Process  │
└──────┘             │ - SSH Server │                 └──────────┘
                     └──────────────┘
                            │
                            ▼
                     ┌──────────────┐
                     │ JSON Storage │
                     │ - sessions   │
                     │ - messages   │
                     └──────────────┘

Project Structure

.
├── cmd/server/main.go           # Entry point
├── internal/
│   ├── config/config.go         # Configuration with validation
│   ├── mcp/
│   │   ├── server.go            # MCP SSE server & tool registration
│   │   └── handlers.go          # 13 tool handlers
│   ├── sshserver/server.go      # Internal SSH server (gliderlabs/ssh)
│   ├── sshclient/client.go      # Internal SSH client (crypto/ssh)
│   ├── session/
│   │   ├── session.go           # Session lifecycle (goroutine-safe)
│   │   └── manager.go           # Thread-safe session registry
│   ├── buffer/buffer.go         # Multi-reader ring buffer (1MB per reader)
│   ├── storage/store.go         # Atomic JSON file persistence
│   ├── message/message.go       # Message management (per-session mutex)
│   └── ansi/strip.go            # ANSI escape code removal
├── pkg/api/types.go             # Public types (Session, Message, SessionMode)
├── go.mod
└── go.sum

Key Design Decisions

Multi-Reader Ring Buffer: Each agent registers as an independent reader with its own ringbuffer.RingBuffer instance. Writes broadcast to all readers. Slow readers lose oldest data (overwrite mode) rather than blocking the writer.
Internal SSH Architecture: The server starts a gliderlabs/SSH server on localhost. Each start_process creates an SSH session via crypto/ssh client, leveraging SSH's mature PTY allocation, window resize, signal forwarding, and environment variable passing.
SSE over HTTP Transport: Unlike traditional stdio-based MCP servers, this server exposes an HTTP endpoint supporting MCP SSE transport. Agents connect remotely, enabling cross-machine deployment.
Atomic JSON Persistence: Session metadata and I/O messages are stored via temp-file + fsync + rename, preventing half-written files on crash:
- data/sessions.json — Session list
- data/messages/{session_id}/index.json — Message index
- data/messages/{session_id}/messages/{msg_id}.json — Message content
Session Lifecycle Safety: Exit goroutine is the single authority for Status/ExitCode (via sync.Once). Terminate is idempotent. Stdin writes are serialized via a dedicated mutex.

Examples

Example 1: SSH Remote Operations

AI Agent Flow                                   Process Output
─────────────────                              ────────────────

start_process(
  command="ssh",
  args=["deploy@192.168.1.100"],
  mode="pty"
)
                                    ←    "deploy@192.168.1.100's password: "

send_and_read(
  text="my_secret_pass",
  press_enter=true
)
                                    ←    "Welcome to Ubuntu 22.04 LTS
                                          deploy@web-server:~$ "

send_and_read(
  text="df -h",
  press_enter=true
)
                                    ←    "Filesystem      Size  Used Avail Use% Mounted on
                                          /dev/sda1       100G   45G   55G  45% /
                                          deploy@web-server:~$ "

terminate_process(session_id="abc123")

Example 2: Python REPL Debugging

start_process(command="python3", mode="pty")
                                    ←    "Python 3.10.12\n>>> "

send_and_read(text="data = [1, 2, 3, 4, 5]", press_enter=true)
                                    ←    ">>> "

send_and_read(text="sum(data)", press_enter=true)
                                    ←    "15\n>>> "

Example 3: Multi-Agent Collaboration

# Agent A starts a monitoring process
start_process(command="top", mode="pty")
  → session_id: "sess-001"

# Agent B joins the same session without stealing output
register_reader(session_id="sess-001")
  → reader_id: 2

# Agent A reads its own cursor
read_output(session_id="sess-001", reader_id=1)
  → "PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEM   TIME+ COMMAND..."

# Agent B reads from the beginning independently
read_output(session_id="sess-001", reader_id=2)
  → "top - 14:32:10 up 3 days,  2:15,  1 user,  load average: 0.52, 0.58, 0.59..."

# Agent B is done
unregister_reader(session_id="sess-001", reader_id=2)

# Agent A terminates the session
terminate_process(session_id="sess-001")
delete_session(session_id="sess-001")

Example 4: Multi-session Parallel Management

start_process(command="ping", args=["-c", "5", "google.com"], name="ping-test")
  → session_id: "a1b2c3"

start_process(command="python3", args=["-m", "http.server", "8080"], name="web-server")
  → session_id: "d4e5f6"

list_sessions()
  → [{id: "a1b2c3", status: "running"}, {id: "d4e5f6", status: "running"}]

read_output(session_id="a1b2c3")  → ping statistics

terminate_process(session_id="a1b2c3")
terminate_process(session_id="d4e5f6")

Tool Reference

`start_process`

Start an interactive process.

Parameter	Type	Required	Default	Description
`command`	string	Yes	—	Command to execute
`args`	string[]	No	`[]`	Command arguments
`mode`	"pty" \| "pipe"	No	`"pty"`	I/O mode
`name`	string	No	Auto-generated	Session name
`rows`	integer	No	`24`	PTY row count (1–1000)
`cols`	integer	No	`80`	PTY column count (1–1000)

Returns: { session_id, pid, initial_output }

`send_input`

Send text to a process.

Parameter	Type	Required	Default	Description
`session_id`	string	Yes	—	Session ID
`text`	string	Yes	—	Text to send
`press_enter`	boolean	No	`false`	Whether to append a newline

`read_output`

Read new output since the last read for the given reader.

Parameter	Type	Required	Default	Description
`session_id`	string	Yes	—	Session ID
`reader_id`	integer	No	`0`	Reader ID (0 = default)
`strip_ansi`	boolean	No	`true`	Strip ANSI escape codes
`timeout`	number	No	`5`	Wait time in seconds (0.1–60)
`max_lines`	integer	No	`0`	Max lines (0 = unlimited)

Returns: { output, has_more, lines_returned, bytes_returned }

`send_and_read`

Atomic operation: send input + wait + read output. Parameters are the union of send_input and read_output.

`list_sessions`

List all sessions. Returns: { sessions: [...] }

`get_session_info`

Get session details. Returns: { id, name, command, args, mode, status, exit_code, pid, created_at }

`terminate_process`

Terminate a process.

Parameter	Type	Required	Default	Description
`session_id`	string	Yes	—	Session ID
`force`	boolean	No	`false`	Use SIGKILL directly
`grace_period`	number	No	`5`	Seconds to wait after SIGTERM (0–60)

`delete_session`

Remove an exited session from the registry.

Parameter	Type	Required	Default	Description
`session_id`	string	Yes	—	Session ID

`resize_pty`

Resize PTY dimensions (PTY mode only).

Parameter	Type	Required	Default	Description
`session_id`	string	Yes	—	Session ID
`rows`	integer	No	`24`	Row count
`cols`	integer	No	`80`	Column count

`register_reader`

Parameter	Type	Required	Default	Description
`session_id`	string	Yes	—	Session ID

Returns: { reader_id }

`unregister_reader`

Unregister a reader to free resources.

Parameter	Type	Required	Default	Description
`session_id`	string	Yes	—	Session ID
`reader_id`	integer	Yes	—	Reader ID

`list_messages`

List the message index for a session.

Parameter	Type	Required	Default	Description
`session_id`	string	Yes	—	Session ID

Returns: { messages: [{id, type, created_at, byte_size}, ...] }

`get_message`

Get the content of one or more messages.

Parameter	Type	Required	Default	Description
`session_id`	string	Yes	—	Session ID
`message_ids`	string[]	No	—	Message IDs to retrieve

Returns: { messages: [{id, session_id, type, content, created_at, byte_size}, ...] }

Installation

Build from source

go build -o server ./cmd/server

Requirements: Go >= 1.21 / macOS or Linux

Run

./server --host 127.0.0.1 --port 8080 --data-dir ./data

Options:

Flag	Default	Description
`--host`	`127.0.0.1`	HTTP server host
`--port`	`8080`	HTTP server port
`--data-dir`	`./data`	JSON storage directory
`--ssh-host`	`127.0.0.1`	Internal SSH server host
`--ssh-port`	`0` (random)	Internal SSH server port

Configuration

Claude Code

In .claude/settings.json or .mcp.json:

{
  "mcpServers": {
    "interactive-process": {
      "type": "sse",
      "url": "http://your-server:8080/sse"
    }
  }
}

Or via CLI:

claude mcp add --transport sse interactive-process http://localhost:8080/sse

Other MCP Clients

Any MCP client that supports SSE transport can connect to http://<host>:<port>/sse.

Community

linux.do — Chinese tech community

License

MIT

Available Tools

8 tools

get_session_infoB

Get detailed information about a session.

Args: session_id: The session ID to query.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations exist, so the description must fully disclose behavior. It only states it gets details, without mentioning safety (read-only), side effects, rate limits, or what 'detailed information' comprises.

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 concise with one clear sentence and a parameter definition. However, it lacks a return description or context, making it slightly under-specified.

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?

With 1 parameter, no output schema, and no annotations, the description provides basic purpose but not enough detail on return format or error scenarios. It is minimally adequate for a simple tool.

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 0%, but the description adds 'The session ID to query' which clarifies the parameter's purpose minimally. It does not describe format, constraints, or valid values.

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 uses 'Get detailed information about a session' as a specific verb+resource combination, distinguishing it from sibling tools like list_sessions 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 Guidelines2/5

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

No usage guidelines are provided. The description does not mention when to use this tool versus alternatives like list_sessions or read_output.

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

list_sessionsB

List all interactive process sessions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are present, so the description must cover behavioral traits. It only states the action without revealing whether the operation is read-only, what data is returned, or any side effects, which is insufficient.

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 a single, clear sentence with no superfluous words. It is appropriately sized for the tool's simplicity and front-loads the key information.

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

Completeness2/5

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

Despite having no parameters, the description lacks completeness because it does not explain what constitutes an 'interactive process session' or describe the return format, which is especially important given the absence of an output schema.

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?

There are no parameters, so schema coverage is 100%. The description does not need to add meaning beyond the schema, meeting the baseline expectation for zero-parameter tools.

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 specifies a clear verb ('list') and a distinct resource ('interactive process sessions'). It is unambiguous and differentiates from siblings like 'get_session_info' which targets a single session.

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 usage guidance is provided. The description does not mention when to use this tool versus alternatives like 'get_session_info' or the other session-related tools, leaving the agent to infer context.

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

read_outputA

Read new output from an interactive process since last read.

If no new output is available, waits up to timeout seconds. Returns empty output on timeout (not an error).

Args: session_id: The session ID returned by start_process. strip_ansi: Remove ANSI escape codes from output. Default True. timeout: Seconds to wait for new output. Default 5. max_lines: Max lines to return (0 = unlimited).

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes
`strip_ansi`	No
`timeout`	No
`max_lines`	No

TDQS

A4.3/5.0

Behavior4/5

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

The description discloses blocking behavior and timeout handling, and clarifies that returning empty output on timeout is not an error. In the absence of annotations, this provides good transparency. However, it does not mention behavior on invalid session_id or process termination.

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 and front-loaded with the core purpose. The Args section is structured and each sentence adds value without redundancy.

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?

The description covers main use cases and return behavior. Lacks details on error handling for invalid session_id or process lifecycle. With no output schema, return values are partially described. Overall adequate for the tool's simplicity.

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

Parameters5/5

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

With 0% schema coverage, the description fully compensates by documenting each parameter's purpose, defaults, and constraints (e.g., session_id from start_process, strip_ansi removes ANSI codes, timeout in seconds, max_lines with 0 meaning unlimited).

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 reads new output from an interactive process since the last read, which is a specific verb and resource. It distinguishes from sibling tools like send_input and start_process.

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 explains behavior (waits up to timeout, returns empty on timeout) but does not explicitly guide when to use this tool versus alternatives like send_and_read. Usage is implied but not contrasted.

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

resize_ptyC

Resize the PTY terminal dimensions for a session.

Only works in pty mode.

Args: session_id: The session ID. rows: New row count. cols: New column count.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes
`rows`	No
`cols`	No

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description bears full burden. It mentions no side effects, auth requirements, or behavioral traits beyond the mode constraint. For a resize operation, it is safe but lacks detail on response or error behavior.

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 short and to the point, including a constraint and parameter list. It could be more concise by omitting the redundant 'Args' section that repeats schema names, but overall it avoids unnecessary filler.

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

Completeness2/5

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

Given no output schema and 3 parameters with defaults, the description is incomplete. It does not explain return values, what happens on error, or the relationship to other session tools. Adequate for simple use but lacks depth for an autonomous agent.

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

Parameters2/5

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

Schema description coverage is 0%, meaning the description must compensate. It lists params with brief explanations (e.g., 'New row count'), which adds minimal value over the schema titles and defaults. No deeper semantics like allowed ranges or units.

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

Purpose4/5

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

The description clearly states the action 'Resize the PTY terminal dimensions' with a specific resource (PTY terminal dimensions for a session). It distinguishes from sibling tools like start_process or send_input by focusing on resizing, but does not explicitly differentiate.

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?

The description includes a constraint 'Only works in pty mode' but provides no guidance on when to use this tool vs alternatives like send_and_read or start_process. No exclusions or context for selection.

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

send_and_readA

Send input to a process and immediately read its response.

Atomic operation: sends text, waits briefly, then reads new output.

Args: session_id: The session ID returned by start_process. text: Text to send. press_enter: Append newline after text. strip_ansi: Remove ANSI escape codes. Default True. timeout: Seconds to wait for response. Default 5. max_lines: Max lines to return (0 = unlimited).

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes
`text`	Yes
`press_enter`	No
`strip_ansi`	No
`timeout`	No
`max_lines`	No

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, but description explains behavior: atomic send, wait, read. Includes parameter details (press_enter, strip_ansi, timeout, max_lines). Lacks disclosure of errors or side effects.

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?

Two short paragraphs with a clear summary and structured Arg list. No redundancy, front-loaded purpose.

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?

Parameter details are present, but without output schema, description omits return value format. Also does not compare directly to using send_input + read_output separately.

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 coverage is 0%, but description fully explains all 6 parameters (e.g., press_enter appends newline). Adds meaningful context beyond schema defaults.

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 'Send input to a process and immediately read its response,' which is specific and distinct from siblings like send_input 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 Guidelines4/5

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

Indicates atomic nature and lists parameters with defaults, implying when to use (send-and-read). Does not explicitly exclude alternatives, but context is clear.

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

send_inputA

Send text input to a running interactive process.

Args: session_id: The session ID returned by start_process. text: Text to send to the process stdin. press_enter: Whether to append a newline after the text.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes
`text`	Yes
`press_enter`	No

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description takes full burden; it explains parameters but lacks disclosure of side effects, error conditions, or whether input is buffered. The behavior of text sending is adequately described but not comprehensively.

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 a one-line purpose statement followed by parameter details. No unnecessary words, and the most critical information is front-loaded.

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 sibling tools for process management, the description is sufficient for basic use. However, it omits return value information and potential errors, which would be helpful but not required since no output schema exists.

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

Parameters5/5

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

Schema has 0% description coverage; the description adds meaning for all three parameters: session_id origin, text content, and press_enter effect (appending newline). This fully compensates for the schema gap.

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 action ('Send text input to a running interactive process'), specifying the verb and resource, and distinguishes from sibling tools like start_process 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 context by referencing session_id from start_process, but does not explicitly state when to use versus alternatives like send_and_read, nor provides when-not-to-use guidance.

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

start_processA

Start an interactive process and return its session info.

Args: command: The command to execute. args: Command arguments. mode: I/O mode — "pty" (pseudo-terminal) or "pipe". Default "pty". name: Optional human-readable session name. cwd: Working directory for the process. env: Environment variables (dict of string key-value pairs). timeout: Process startup timeout in seconds. rows: PTY row count (pty mode only). cols: PTY column count (pty mode only).

ParametersJSON Schema

Name	Required	Default
`command`	Yes
`args`	No
`mode`	No	pty
`name`	No
`cwd`	No
`env`	No
`timeout`	No
`rows`	No
`cols`	No

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description bears the full burden. It explains parameters like mode (pty/pipe) but does not disclose side effects (e.g., resource consumption, cleanup) or authorization needs. Moderate 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?

The description is well-structured as a docstring with bullet points for each parameter, and the first line clearly states the purpose. It is moderately sized with no redundant sentences, though minor trimming is possible.

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

Completeness2/5

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

Despite covering all parameters, the description lacks detail on the return value ('session info' is vague) and does not explain how to subsequently interact with the process using sibling tools. Given absent output schema and no annotations, this is insufficient.

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

Parameters5/5

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

All 9 parameters are explicitly described in the description, adding meaning beyond the schema's type and default values. For example, mode explains 'I/O mode — 'pty' (pseudo-terminal) or 'pipe'.' and timeout is 'Process startup timeout in seconds.'

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 'Start an interactive process and return its session info,' which is a specific action on a distinct resource. This distinguishes it from sibling tools that query sessions, read output, or send input.

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 starting a process but does not explicitly state when to use it versus alternatives like get_session_info or send_input. No guidance on prerequisites or when not to use it.

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

terminate_processA

Terminate an interactive process.

Args: session_id: The session ID to terminate. force: Use SIGKILL instead of SIGTERM. Default False. grace_period: Seconds to wait after SIGTERM before SIGKILL. Default 5.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes
`force`	No
`grace_period`	No

TDQS

A3.6/5.0

Behavior3/5

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

Discloses signal types (SIGTERM/SIGKILL) and grace period behavior, but omits side effects like session state or error conditions. No annotations to supplement.

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?

Concise: one-line summary then parameter descriptions. No fluff, but could be slightly more structured.

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?

Covers parameter roles and basic behavior, but lacks return value, error conditions, and post-termination effects. Output schema absent.

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?

Description adds meaning beyond schema: force means SIGKILL, grace_period is wait time. Schema only provides defaults and types.

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?

Clear verb+resource: 'Terminate an interactive process.' Distinguishes from siblings like start_process and 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 explicit guidance on when to use or alternatives. Does not differentiate between graceful termination vs forced kill contexts.

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

A3.7/5.0

Disambiguation5/5

Each tool has a distinct and clear purpose: starting, listing, inspecting, sending input, reading output, resizing, and terminating sessions. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, such as start_process, read_output, and terminate_process. The naming is predictable and uniform.

Tool Count5/5

With 8 tools, the set is well-scoped for managing interactive processes. It covers essential operations without being overwhelming or sparse.

Completeness4/5

The tool surface covers core lifecycle operations (start, interact, read, resize, terminate). Minor gaps exist, such as explicit process status checking, but overall it is comprehensive.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

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

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
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
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
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21

Related MCP Servers

MCP Background Job Server
Shell Access Code Execution Developer Tools
dylan-gluck
A
license
A
quality
D
maintenance
An MCP server that enables coding agents to execute and manage long-running shell commands asynchronously with capabilities for process monitoring, interaction, and lifecycle management.
Updated a year ago (2025-08-06 02:03 UTC)
7
13
MIT
MCP Shell Server
Shell Access Command Line OS Automation
mako10k
A
license
B
quality
A
maintenance
A secure MCP server for shell operations, terminal management, and process control, enabling AI assistants to safely execute commands and manage interactive sessions.
Updated 3 days ago (2026-09-01 07:04 UTC)
13
204
6
MIT
mcp-interactive-terminal
Shell Access Command Line Code Execution
amol21p
A
license
A
quality
C
maintenance
MCP server that gives AI agents real interactive terminal sessions for running REPLs, SSH, database clients, and any interactive CLI with clean text output and smart completion detection.
Updated 7 months ago (2026-02-16 16:30 UTC)
7
84
18
MIT
mcp-ssh-interactive
Shell Access Command Line
qnxqnxqnx
A
license
Not graded
quality
D
maintenance
MCP server that enables AI agents to run fully interactive SSH sessions (via tmux) and execute commands like a human operator, with persistent sessions and multiple concurrent connections.
Updated 10 months ago (2025-11-05 08:10 UTC)
6
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/UserB1ank/interactive-process-mcp'

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