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-Server zur Verwaltung interaktiver Prozesse. Ermöglicht es KI-Agenten (Claude Code, etc.), langlebige interaktive Programme — SSH-Sitzungen, REPLs, Installationsprogramme, Impacket-Tools — zu starten und über mehrere Runden hinweg mittels Lese-/Schreibvorgängen mit ihnen zu interagieren.

Funktionen

PTY- & Pipe-Modi — Der PTY-Modus emuliert ein echtes Terminal (Programme wie SSH, top, vim funktionieren korrekt); der Pipe-Modus dient der einfacheren stdin/stdout-Interaktion
Multi-Session — Verwaltung mehrerer interaktiver Prozesse gleichzeitig
ANSI-Bereinigung — Optionale Entfernung von Terminal-Escape-Codes für eine saubere Ausgabe
Nicht-blockierende Lesevorgänge — Der Agent liest die Ausgabe in seinem eigenen Tempo mit konfigurierbaren Timeouts
Graceful Shutdown — SIGTERM mit konfigurierbarer Karenzzeit vor SIGKILL

Related MCP server: MCP Shell Server

Anforderungen

Python >= 3.10
Linux (verwendet das pty-Modul)

Installation

pip install -e .

Oder mit Entwicklungsabhängigkeiten (zum Ausführen von Tests):

pip install -e ".[dev]"

Konfiguration

Claude Code

command

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

Oder

Fügen Sie dies zu Ihren Claude Code MCP-Einstellungen hinzu (.claude/settings.json oder .mcp.json auf Projektebene):

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

Oder bei Installation aus dem Quellcode:

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

Andere MCP-Clients

Jeder MCP-Client, der den stdio-Transport unterstützt, kann diesen Server verwenden. Der Einstiegspunkt ist:

interactive-process-mcp
# or
python -m interactive_process_mcp

Tools

`start_process`

Startet einen interaktiven Prozess und gibt dessen Sitzungsinformationen zurück.

Parameter	Typ	Erforderlich	Standard	Beschreibung
`command`	string	ja	—	Auszuführender Befehl
`args`	string[]	nein	`[]`	Befehlsargumente
`mode`	"pty"	"pipe"	nein	`"pty"`	E/A-Modus
`name`	string	nein	auto	Menschlich lesbarer Sitzungsname
`cwd`	string	nein	erben	Arbeitsverzeichnis
`env`	object	nein	erben	Umgebungsvariablen
`timeout`	number	nein	`10`	Start-Timeout (Sekunden)
`rows`	integer	nein	`24`	PTY-Zeilen (PTY-Modus)
`cols`	integer	nein	`80`	PTY-Spalten (PTY-Modus)

Gibt zurück: { session_id, pid, initial_output }

`send_input`

Sendet Text an einen laufenden Prozess.

Parameter	Typ	Erforderlich	Standard	Beschreibung
`session_id`	string	ja	—	Sitzungs-ID
`text`	string	ja	—	Zu sendender Text
`press_enter`	boolean	nein	`false`	Zeilenumbruch anhängen

Gibt zurück: { success: true } oder { error: "..." }

`read_output`

Liest neue Ausgaben seit dem letzten Lesevorgang. Wenn keine neue Ausgabe verfügbar ist, wird bis zu timeout Sekunden gewartet. Gibt bei Timeout eine leere Antwort zurück (kein Fehler).

Parameter	Typ	Erforderlich	Standard	Beschreibung
`session_id`	string	ja	—	Sitzungs-ID
`strip_ansi`	boolean	nein	`true`	ANSI-Escape-Codes entfernen
`timeout`	number	nein	`5`	Wartezeit (Sekunden)
`max_lines`	integer	nein	`0`	Maximale Zeilen (0 = unbegrenzt)

Gibt zurück: { output, has_more, lines_returned, bytes_returned }

`send_and_read`

Atomares Senden + Lesen. Sendet Eingabe, wartet kurz und gibt dann die neue Ausgabe zurück.

Kombiniert Parameter von send_input und read_output.

`list_sessions`

Listet alle aktiven Sitzungen auf.

Gibt zurück: { sessions: [{ id, name, command, status, pid, created_at }] }

`terminate_process`

Beendet einen laufenden Prozess.

Parameter	Typ	Erforderlich	Standard	Beschreibung
`session_id`	string	ja	—	Sitzungs-ID
`force`	boolean	nein	`false`	SIGKILL statt SIGTERM
`grace_period`	number	nein	`5`	Sekunden vor SIGKILL

`resize_pty`

Ändert die PTY-Dimensionen (nur PTY-Modus).

Parameter	Typ	Erforderlich	Standard	Beschreibung
`session_id`	string	ja	—	Sitzungs-ID
`rows`	integer	nein	`24`	Zeilenanzahl
`cols`	integer	nein	`80`	Spaltenanzahl

`get_session_info`

Ruft detaillierte Informationen zu einer Sitzung ab.

Parameter	Typ	Erforderlich	Beschreibung
`session_id`	string	ja	Sitzungs-ID

Gibt zurück: { id, name, command, args, mode, status, exit_code, pid, created_at }

Anwendungsbeispiele

SSH-Sitzung

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>>> " }

Interaktives Installationsprogramm

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" }

Architektur

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

Jede Sitzung führt einen eigenen Hintergrund-Lese-Thread aus, der die Prozessausgabe kontinuierlich in einen Ringpuffer (max. ~1 MB) liest. Der Agent konsumiert die Ausgabe in seinem eigenen Tempo über read_output / send_and_read.

Testen

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

Lizenz

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