de en es ja ko ru zh

interactive-process-mcp

Name: interactive-process-mcp
Author: UserB1ank

by UserB1ank

Overview Schema Related Servers Score Discussions

Local

interactive-process-mcp

MCP-сервер для управления интерактивными процессами. Позволяет ИИ-агентам (Claude Code и др.) запускать долгоживущие интерактивные программы — SSH-сессии, REPL, установщики, инструменты impacket — и взаимодействовать с ними в течение нескольких шагов с помощью операций чтения/записи.

Возможности

Режимы PTY и Pipe — режим PTY эмулирует настоящий терминал (программы вроде SSH, top, vim работают корректно); режим pipe предназначен для более простого взаимодействия через stdin/stdout
Мультисессионность — управление несколькими интерактивными процессами одновременно
Очистка ANSI — опциональное удаление escape-кодов терминала для получения чистого вывода
Неблокирующее чтение — агент считывает вывод в своем собственном темпе с настраиваемыми тайм-аутами
Корректное завершение — SIGTERM с настраиваемым периодом ожидания перед SIGKILL

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

Или

Добавьте в настройки MCP Claude Code (.claude/settings.json или .mcp.json на уровне проекта):

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

Или при установке из исходного кода:

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

Другие MCP-клиенты

Любой MCP-клиент, поддерживающий транспорт stdio, может использовать этот сервер. Точка входа:

interactive-process-mcp
# or
python -m interactive_process_mcp

Инструменты

`start_process`

Запуск интерактивного процесса и получение информации о сессии.

Параметр	Тип	Обязательный	По умолчанию	Описание
`command`	string	да	—	Команда для выполнения
`args`	string[]	нет	`[]`	Аргументы команды
`mode`	"pty"	"pipe"	нет	`"pty"`	Режим ввода/вывода
`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 escape-коды
`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`	SIGKILL вместо SIGTERM
`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

Каждая сессия запускает собственный фоновый поток чтения, который непрерывно считывает вывод процесса в кольцевой буфер (макс. ~1 МБ). Агент потребляет вывод в своем темпе через 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. Dates show when Glama detected each change.

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

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

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

Naming Consistency5/5

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

Tool Count5/5

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

Completeness4/5

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

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21

Related MCP Servers

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

Latest Blog Posts

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

MCP directory API

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

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

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