de en es ja ko ru zh

Interactive MCP

Name: Interactive MCP
Author: ttommyth

by ttommyth

Overview Schema Related Servers Score Discussions

TypeScript

Local

интерактивный-mcp

npm-версия npm-загрузки значок кузнеца Лицензия GitHub стиль кода: симпатичнее Платформы Последний коммит GitHub

Скриншот 2025-05-13 213745

MCP-сервер, реализованный в Node.js/TypeScript, облегчающий интерактивное общение между LLM и пользователями. Примечание: этот сервер предназначен для локальной работы вместе с клиентом MCP (например, Claude Desktop, VS Code), поскольку ему необходим прямой доступ к операционной системе пользователя для отображения уведомлений и запросов командной строки.

(Примечание: этот проект находится на ранней стадии.)

Хотите краткий обзор? Ознакомьтесь с вводной записью в блоге: Stop Your AI Assistant From Guessing — Introducing interactive-mcp

Демонстрационное видео

Инструменты

Этот сервер предоставляет следующие инструменты через протокол контекста модели (MCP):

request_user_input : Задает пользователю вопрос и возвращает его ответ. Может отображать предопределенные параметры.
message_complete_notification : отправляет простое уведомление ОС.
start_intensive_chat : инициирует постоянный сеанс чата в командной строке.
ask_intensive_chat : Задает вопрос в ходе активного сеанса интенсивного чата.
stop_intensive_chat : Закрывает активный сеанс интенсивного чата.

Related MCP server: Interactive Feedback MCP

Демо

Вот демонстрации интерактивных функций:

Обычный вопрос	Уведомление о завершении

Начало интенсивного чата	Конец интенсивного чата

Сценарии использования

Этот сервер идеально подходит для сценариев, в которых LLM необходимо напрямую взаимодействовать с пользователем на его локальном компьютере, например:

Интерактивные процессы настройки или конфигурирования.
Сбор отзывов во время генерации или модификации кода.
Уточнение инструкций или подтверждение действий в парном программировании.
Любой рабочий процесс, требующий ввода данных или подтверждения пользователя во время работы LLM.

Конфигурация клиента

В этом разделе объясняется, как настроить клиенты MCP для использования сервера interactive-mcp .

По умолчанию запросы пользователя будут отсутствовать по истечении 30 секунд. Вы можете настроить параметры сервера, такие как тайм-аут или отключенные инструменты, добавив флаги командной строки непосредственно в массив args при настройке клиента.

Убедитесь, что у вас доступна команда npx .

Использование с Claude Desktop / Курсор

Добавьте следующую минимальную конфигурацию в файл claude_desktop_config.json (Claude Desktop) или mcp.json (Cursor):

{
  "mcpServers": {
    "interactive": {
      "command": "npx",
      "args": ["-y", "interactive-mcp"]
    }
  }
}

С определенной версией

{
  "mcpServers": {
    "interactive": {
      "command": "npx",
      "args": ["-y", "interactive-mcp@1.9.0"]
    }
  }
}

Пример с пользовательским тайм-аутом (30 с):

{
  "mcpServers": {
    "interactive": {
      "command": "npx",
      "args": ["-y", "interactive-mcp", "-t", "30"]
    }
  }
}

Использование с VS Code

Добавьте следующую минимальную конфигурацию в файл настроек пользователя (JSON) или .vscode/mcp.json :

{
  "mcp": {
    "servers": {
      "interactive-mcp": {
        "command": "npx",
        "args": ["-y", "interactive-mcp"]
      }
    }
  }
}

Настройка разработки

Этот раздел в первую очередь предназначен для разработчиков, желающих изменить или внести свой вклад в сервер. Если вы просто хотите использовать сервер с клиентом MCP, см. раздел «Конфигурация клиента» выше.

Предпосылки

Node.js: Проверьте package.json на совместимость версий.
pnpm: Используется для управления пакетами. Устанавливается через npm install -g pnpm после установки Node.js.

Установка (Разработчики)

Клонируйте репозиторий:

git clone https://github.com/ttommyth/interactive-mcp.git
cd interactive-mcp

Установить зависимости:
```
pnpm install
```

Запуск приложения (разработчики)

pnpm start

Параметры командной строки

Сервер interactive-mcp принимает следующие параметры командной строки. Обычно их следует настраивать в настройках JSON вашего клиента MCP, добавляя их непосредственно в массив args (см. примеры «Конфигурация клиента»).

Вариант	Псевдоним	Описание
`--timeout`	`-t`	Устанавливает тайм-аут по умолчанию (в секундах) для запросов на ввод данных пользователем. По умолчанию 30 секунд.
`--disable-tools`	`-d`	Отключает определенные инструменты или группы (список, разделенный запятыми). Запрещает серверу рекламировать или регистрировать их. Параметры: `request_user_input` , `message_complete_notification` , `intensive_chat` .

Пример: установка нескольких параметров в массиве args конфигурации клиента:

// Example combining options in client config's "args":
"args": [
  "-y", "interactive-mcp",
  "-t", "30", // Set timeout to 30 seconds
  "--disable-tools", "message_complete_notification,intensive_chat" // Disable notifications and intensive chat
]

Команды развития

Сборка: pnpm build
Линт: pnpm lint
Формат: pnpm format

Руководящие принципы взаимодействия

При взаимодействии с этим сервером MCP (например, в качестве клиента LLM) придерживайтесь следующих принципов, чтобы обеспечить ясность и сократить количество неожиданных изменений:

Отдайте приоритет взаимодействию: регулярно используйте предоставленные инструменты MCP ( request_user_input , start_intensive_chat и т. д.) для взаимодействия с пользователем.
Просите разъяснений: Если требования, инструкции или контекст неясны, всегда задавайте уточняющие вопросы, прежде чем продолжить. Не делайте предположений.
Подтверждение действий: перед выполнением важных действий (например, изменением файлов, запуском сложных команд или принятием архитектурных решений) согласуйте план с пользователем.
Предоставьте варианты: по возможности предоставьте пользователю предопределенные варианты с помощью инструментов MCP, чтобы облегчить принятие быстрых решений.

Вы можете предоставить эти инструкции клиенту LLM следующим образом:

# Interaction

- Please use the interactive MCP tools
- Please provide options to interactive MCP if possible

# Reduce Unexpected Changes

- Do not make assumption.
- Ask more questions before executing, until you think the requirement is clear enough.

Внося вклад

Вклады приветствуются! Пожалуйста, следуйте стандартным практикам разработки. (Дополнительные подробности могут быть добавлены позже).

Лицензия

MIT (подробности см. в файле LICENSE , если применимо, или укажите лицензию напрямую).

Available Tools

5 tools

ask_intensive_chatA

ParametersJSON Schema

Name	Required	Description
`question`	Yes	Question to ask the user
`sessionId`	Yes	ID of the intensive chat session
`predefinedOptions`	No	Predefined options for the user to choose from (optional)

TDQS

A4.5/5.0

Behavior4/5

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

Despite missing annotations, the description discloses key behaviors: returns user's answer or indicates non-response, maintains chat history, and supports predefined options. However, it lacks details on error cases or rate limits.

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 with labeled sections and front-loaded summary. However, some repetition exists (e.g., features overlap with usage notes). Could be slightly more concise.

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 no output schema, the description explains return behavior. For a tool with 3 parameters and simple interaction, it covers essential aspects: session requirement, repeated use, and optional options. Missing potential edge cases.

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?

Input schema has 100% coverage, but the description adds value with examples and clarifies optional nature of 'predefinedOptions'. This exceeds the baseline 3 by providing practical usage context.

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 it asks a new question in an active intensive chat session previously started, with specific verb and resource. It distinguishes from siblings like 'start_intensive_chat' and 'stop_intensive_chat' by focusing on continuation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

The 'whenToUseThisTool' section explicitly lists scenarios for use, and importantNotes highlight the prerequisite session ID and repeated usage within the same response. This provides clear guidance on when and how to use vs alternatives.

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

message_complete_notificationA

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes	Notification body
`projectName`	Yes	Notification title

TDQS

A4.6/5.0

Behavior4/5

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

No annotations provided, so description carries behavioral info. It specifies cross-platform OS notifications and best practices like consistent projectName usage. Lacks details on potential side effects, but for a simple notification tool this is sufficient.

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 into sections (description, notes, when to use, features, best practices, parameters, examples). It is detailed but each section adds necessary value; no redundancy.

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

Completeness5/5

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

For a simple tool with 2 string parameters and no output schema, the description is fully complete: it explains purpose, usage, parameters, examples, and best practices. No gaps remain.

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 has 100% coverage with concise descriptions. The description adds value by explaining parameter use (title vs body) and providing examples, exceeding the baseline of 3.

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 notifies when a response completes and must be used exactly once per message. It distinguishes itself from sibling chat tools by focusing on signaling completion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Explicit 'whenToUseThisTool' and 'importantNotes' provide comprehensive guidance: use at end of query, after tool sequences, or multi-step processes. The mandatory once-per-message rule is emphasized.

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

request_user_inputA

ParametersJSON Schema

Name	Required	Description
`message`	Yes	The specific question for the user (appears in the prompt)
`projectName`	Yes	Identifies the context/project making the request (used in prompt formatting)
`predefinedOptions`	No	Predefined options for the user to choose from (optional)

TDQS

A4.7/5.0

Behavior5/5

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

Without annotations, the description fully discloses behavior: pop-up display, return of user response or timeout after 60 seconds, context maintenance, graceful handling of empty responses, and formatting with project context. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections but is lengthy (many sentences). Some redundancy between importantNotes and bestPractices (e.g., both emphasize frequent use). Could be tightened without losing clarity.

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

Completeness5/5

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

For a simple 3-parameter tool with no output schema, the description is exceptionally complete: covers purpose, usage guidance, features, best practices, and examples. Leaves no gaps in understanding.

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 100%, so baseline 3. The description's parameters section adds context beyond schema: e.g., projectName is 'used in prompt formatting', predefinedOptions are optional. This adds meaningful value.

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 sends a question to the user via a pop-up command prompt, with explicit purpose of clarifying requirements, confirming plans, or resolving ambiguity. It distinguishes from sibling tools like ask_intensive_chat by specifying a pop-up prompt rather than a chat message.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

A dedicated 'whenToUseThisTool' section provides exhaustive scenarios, and 'bestPractices' explicitly instructs not to use the tool when another tool can answer the question, offering clear alternatives. This provides excellent decision support.

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

start_intensive_chatA

ParametersJSON Schema

Name	Required	Description	Default
`sessionTitle`	Yes	Title for the intensive chat session

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description fully discloses behaviors: opens persistent console window, returns session ID, must be closed, configurable timeout, maintains chat history, and warns against unnecessary questions. This is comprehensive.

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 with separate sections but contains some redundancy (e.g., 'Highly recommended' and 'Very useful' are similar). It is thorough but could be slightly more concise.

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

Completeness5/5

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

Given the simple parameter list, no output schema, and missing annotations, the description covers all necessary aspects: purpose, usage, important notes, parameters, examples, and best practices. It feels complete for the tool's role.

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?

Only one parameter (sessionTitle) with 100% schema coverage. The description adds context that the title appears at the top of the console, which goes beyond the schema's description. A score of 4 is appropriate for the added value.

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 it starts an intensive chat session for gathering multiple answers quickly. It uses specific verbs like 'start', 'gather', 'opens', and distinguishes from sibling tools such as ask_intensive_chat and stop_intensive_chat.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

The description includes explicit when-to-use scenarios (e.g., collecting series of quick answers, multi-step processes) and when-not-to-use (e.g., prefer other tools if they can answer). It also provides important instructions on using ask_intensive_chat and closing with stop_intensive_chat in the same response.

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

stop_intensive_chatA

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes	ID of the intensive chat session to stop

TDQS

A4.5/5.0

Behavior4/5

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

Given no annotations, the description carries full burden and discloses key behaviors: closes console window, frees system resources, marks session complete. It omits potential side effects like idempotency or error handling, but the core behavioral traits are well covered for a termination action.

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?

Highly structured with clear sections (description, importantNotes, whenToUseThisTool, etc.). Every sentence adds value, and the core purpose is front-loaded. No unnecessary verbosity.

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

Completeness5/5

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

For a tool with one required parameter and no output schema, the description is fully complete. It covers what it does, when to use, how to use (with example), and what to expect. No gaps remain for an agent to select and invoke correctly.

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 100% for the single parameter 'sessionId', with the schema providing a description. The description repeats the same parameter info without adding new semantic meaning, so baseline 3 is appropriate.

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 explicitly states 'Stop and close an active intensive chat session' with a specific verb and resource. It clearly distinguishes from siblings like 'start_intensive_chat' and 'ask_intensive_chat' by noting it must be called after all questions have been asked.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Provides explicit when-to-use conditions: after completing 'ask_intensive_chat', when the multi-step process is complete, and as the final action. Also includes a strong directive that it 'must be called' and 'should always be called', leaving no ambiguity about its role in the workflow.

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.

5 tool updatesv1.6.0Apr 30, 2026
- Removedask_intensive_chat
- Removedmessage_complete_notification
- Removedrequest_user_input
- Removedstart_intensive_chat
- Removedstop_intensive_chat
5 tool updatesv1.10.0Apr 30, 2026
- Addedask_intensive_chat
- Addedmessage_complete_notification
- Addedrequest_user_input
- Addedstart_intensive_chat
- Addedstop_intensive_chat
5 tool updatesv1.10.1Apr 30, 2026
- Removedask_intensive_chat
- Removedmessage_complete_notification
- Removedrequest_user_input
- Removedstart_intensive_chat
- Removedstop_intensive_chat
5 tool updatesAug 14, 2025
- First observedask_intensive_chat
- First observedmessage_complete_notification
- First observedrequest_user_input
- First observedstart_intensive_chat
- First observedstop_intensive_chat

Install Server

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

TDQS

A4.7/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose: start, ask, and stop intensive chat sessions; request general user input; and notify completion. No overlap, as ask_intensive_chat is contextual within an active session, while request_user_input is standalone. The descriptions further clarify their distinct use cases.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., start_intensive_chat, request_user_input). The naming is predictable and logically groups related actions (start/ask/stop for intensive chat). No mixing of conventions.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose of managing interactive user input and notifications. Each tool is necessary and there is no bloat. This count is ideal for such a focused domain.

Completeness5/5

The tool set covers the full lifecycle of an intensive chat session (start, ask questions, stop), plus a general user input tool and a completion notification. There are no obvious gaps for the stated purpose of gathering user input and signaling completion.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
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
QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2

Related MCP Servers

MCP Terminal Server
Command Line Security Code Execution
RinardNick
A
license
B
quality
D
maintenance
A secure terminal execution server that enables controlled command execution with security features and resource limits via the Model Context Protocol (MCP).
Updated 2 years ago (2025-01-20 15:59 UTC)
1
12
11
MIT
Interactive Feedback MCP
Developer Tools Command Line OS Automation
noopstudios
A
license
A
quality
D
maintenance
A MCP server that enables human-in-the-loop workflow in AI-assisted development tools by allowing users to run commands, view their output, and provide textual feedback directly to the AI assistant.
Updated a year ago (2025-05-26 16:05 UTC)
1
1,711
MIT
interactive-mcp
Shell Access Communication
mikeysrecipes
A
license
A
quality
D
maintenance
A Node.js/TypeScript MCP server that facilitates interactive communication between LLMs and users, allowing AI assistants to request user input, display notifications, and manage command-line chat sessions.
Updated a year ago (2025-05-18 06:40 UTC)
5
29
1
MIT
Popup MCP
Autonomous Agents Developer Tools
Chietears
A
license
Not graded
quality
C
maintenance
A cross-platform MCP server that provides native popup windows for AI agents to gather user feedback, input, and safety confirmations. It enables agents to present interactive questionnaires and secure confirmation prompts for sensitive operations like file deletion or code execution.
Updated 9 months ago (2025-12-20 12:51 UTC)
13
MIT

Appeared in Searches

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/ttommyth/interactive-mcp'

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

интерактивный-mcp

Инструменты

Демо

Сценарии использования

Конфигурация клиента

Использование с Claude Desktop / Курсор

Использование с VS Code

Рекомендации для macOS

Настройка разработки

Предпосылки

Установка (Разработчики)

Запуск приложения (разработчики)

Параметры командной строки

Команды развития

Руководящие принципы взаимодействия

Внося вклад

Лицензия

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API