de en es ja ko ru zh

interactive-process-mcp

Name: interactive-process-mcp
Author: UserB1ank

by UserB1ank

Overview Schema Source Related Servers Discussions Admin

Local

interactive-process-mcp

対話型プロセスを管理するためのMCPサーバー。AIエージェント（Claude Codeなど）が、SSHセッション、REPL、インストーラー、impacketツールなどの長時間実行される対話型プログラムを開始し、読み取り/書き込み操作を通じて複数ターンにわたって対話することを可能にします。

機能

PTY & Pipeモード — PTYモードは実際の端末をエミュレートします（SSH、top、vimなどのプログラムが正しく動作します）。パイプモードは、より単純な標準入力/標準出力の対話用です。
マルチセッション — 複数の対話型プロセスを同時に管理します。
ANSIストリッピング — クリーンな出力のために端末エスケープコードを削除するオプション。
ノンブロッキング読み取り — エージェントが設定可能なタイムアウトを使用して、自分のペースで出力を読み取ります。
正常なシャットダウン — SIGKILLの前に設定可能な猶予期間を設けたSIGTERM。

Related MCP server: MCP Shell Server

要件

Python >= 3.10
Linux (ptyモジュールを使用)

インストール

pip install -e .

または開発用依存関係を含める場合（テスト実行用）:

pip install -e ".[dev]"

設定

Claude Code

command

claude mcp add --scope user interactive-process -- interactive-process-mcp

または

Claude CodeのMCP設定（.claude/settings.json またはプロジェクトレベルの .mcp.json）に追加します:

{
  "mcpServers": {
    "interactive-process": {
      "command": "interactive-process-mcp"
    }
  }
}

またはソースからインストールした場合:

{
  "mcpServers": {
    "interactive-process": {
      "command": "python",
      "args": ["-m", "interactive_process_mcp"]
    }
  }
}

その他のMCPクライアント

stdioトランスポートをサポートするすべてのMCPクライアントがこのサーバーを使用できます。エントリポイントは以下の通りです:

interactive-process-mcp
# or
python -m interactive_process_mcp

ツール

`start_process`

対話型プロセスを開始し、そのセッション情報を返します。

パラメータ	型	必須	デフォルト	説明
`command`	string	はい	—	実行するコマンド
`args`	string[]	いいえ	`[]`	コマンド引数
`mode`	"pty"	"pipe"	いいえ	`"pty"`	I/Oモード
`name`	string	いいえ	auto	人間が読めるセッション名
`cwd`	string	いいえ	inherit	作業ディレクトリ
`env`	object	いいえ	inherit	環境変数
`timeout`	number	いいえ	`10`	起動タイムアウト（秒）
`rows`	integer	いいえ	`24`	PTY行数（ptyモード）
`cols`	integer	いいえ	`80`	PTY列数（ptyモード）

戻り値: { session_id, pid, initial_output }

`send_input`

実行中のプロセスにテキストを送信します。

パラメータ	型	必須	デフォルト	説明
`session_id`	string	はい	—	セッションID
`text`	string	はい	—	送信するテキスト
`press_enter`	boolean	いいえ	`false`	改行を追加

戻り値: { success: true } または { error: "..." }

`read_output`

前回の読み取り以降の新しい出力を読み取ります。新しい出力がない場合は、timeout秒まで待機します。タイムアウト時は空を返します（エラーではありません）。

パラメータ	型	必須	デフォルト	説明
`session_id`	string	はい	—	セッションID
`strip_ansi`	boolean	いいえ	`true`	ANSIエスケープコードを削除
`timeout`	number	いいえ	`5`	待機時間（秒）
`max_lines`	integer	いいえ	`0`	最大行数（0 = 無制限）

戻り値: { output, has_more, lines_returned, bytes_returned }

`send_and_read`

送信と読み取りをアトミックに行います。入力を送信し、短時間待機してから新しい出力を返します。

send_inputとread_outputのパラメータを組み合わせたものです。

`list_sessions`

すべてのアクティブなセッションを一覧表示します。

戻り値: { sessions: [{ id, name, command, status, pid, created_at }] }

`terminate_process`

実行中のプロセスを終了します。

パラメータ	型	必須	デフォルト	説明
`session_id`	string	はい	—	セッションID
`force`	boolean	いいえ	`false`	SIGTERMの代わりにSIGKILLを使用
`grace_period`	number	いいえ	`5`	SIGKILLまでの秒数

`resize_pty`

PTYのサイズを変更します（ptyモードのみ）。

パラメータ	型	必須	デフォルト	説明
`session_id`	string	はい	—	セッションID
`rows`	integer	いいえ	`24`	行数
`cols`	integer	いいえ	`80`	列数

`get_session_info`

セッションに関する詳細情報を取得します。

パラメータ	型	必須	説明
`session_id`	string	はい	セッションID

戻り値: { id, name, command, args, mode, status, exit_code, pid, created_at }

使用例

SSHセッション

1. start_process(command="ssh", args=["user@host"], mode="pty")
   → { session_id: "abc123", initial_output: "user@host's password: " }

2. send_input(session_id="abc123", text="mypassword", press_enter=true)
   → { success: true }

3. read_output(session_id="abc123", timeout=5)
   → { output: "Welcome to Ubuntu...\n$ " }

4. send_and_read(session_id="abc123", text="ls -la", press_enter=true, timeout=3)
   → { output: "total 32\ndrwxr-xr-x ...\n$ " }

5. terminate_process(session_id="abc123")
   → { success: true }

Python REPL

1. start_process(command="python3", mode="pty")
   → { session_id: "def456", initial_output: ">>> " }

2. send_and_read(session_id="def456", text="print(2 + 2)", press_enter=true)
   → { output: "4\n>>> " }

対話型インストーラー

1. start_process(command="sudo", args=["apt", "install", "some-package"], mode="pty")
   → { session_id: "ghi789", initial_output: "Do you want to continue? [Y/n] " }

2. send_input(session_id="ghi789", text="Y", press_enter=true)
   → { success: true }

3. read_output(session_id="ghi789", timeout=30)
   → { output: "Setting up some-package ...\n" }

アーキテクチャ

MCP Server (main thread — JSON-RPC over stdio)
  ├── Session reader thread → ring buffer → agent reads
  ├── Session reader thread → ring buffer → agent reads
  └── Session reader thread → ring buffer → agent reads

各セッションは独自のバックグラウンド読み取りスレッドを実行し、プロセスの出力をリングバッファ（最大約1MB）に継続的に読み取ります。エージェントはread_output / send_and_readを通じて、自分のペースで出力を消費します。

テスト

pip install -e ".[dev]"
pytest tests/ -v

ライセンス

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.1.0Apr 27, 2026
- First observedget_session_info
- First observedlist_sessions
- First observedread_output
- First observedresize_pty
- First observedsend_and_read
- First observedsend_input
- First observedstart_process
- First observedterminate_process

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-04-27 14:10 across 8 tools

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

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Node CommandOAuth
io.github.huseyincig
Remote MCP server exposing your Node Command fleet (files, shell, processes, browser) to AI hosts.
1
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
FlowraOAuth
io.github.flowradev
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Agent Orchestration Autonomous Agents
11

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
20 PyPI
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 a month ago (2026-09-01 07:04 UTC)
13
172 npm
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 8 months ago (2026-02-16 16:30 UTC)
7
83 npm
19
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 a year ago (2025-11-05 08:10 UTC)
6
MIT