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 및 파이프 모드 — PTY 모드는 실제 터미널을 에뮬레이트하며(SSH, top, vim과 같은 프로그램이 정상 작동), 파이프 모드는 더 간단한 표준 입력/출력(stdin/stdout) 상호작용을 지원합니다.
다중 세션 — 여러 대화형 프로세스를 동시에 관리합니다.
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	아니오	자동	사람이 읽을 수 있는 세션 이름
`cwd`	string	아니오	상속	작업 디렉토리
`env`	object	아니오	상속	환경 변수
`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`

원자적(Atomic) 전송 + 읽기. 입력을 보내고 잠시 대기한 후 새로운 출력을 반환합니다.

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