An MCP server that provides interactive user input and notification capabilities through terminal UI windows and intensive chat sessions
Interactive MCP provides 5 tools for user interaction via desktop UI windows. While all tools have descriptions and input schemas are visible, there are significant gaps in schema completeness, parameter documentation, and output schema definition. Naming conventions are mostly clear but some tools lack action verbs. Descriptions exist but are brief and sometimes vague about return values and use cases. Most critically, output schemas are undocumented, LLMs cannot know what to expect from responses. Parameter descriptions are inconsistent: some are clear, others generic. The server is fundamentally constrained by its STDIO-only transport (capped at 50 for protocol readiness), but definition quality itself has room for improvement.
Ask a question in an existing intensive chat session and get the user's response. Returns the answer or timeout indicator.
Send a desktop notification to indicate message completion. Displays a native system notification with the provided title and message.
Request user input with an optional timeout and predefined options. Displays a command window with a prompt message and returns the user's response or a timeout indicator.
Start an intensive chat session for multi-turn interactions. Creates a new chat window that can handle multiple questions and answers.
Stop and close an active intensive chat session. Terminates the chat window and cleans up session resources.
Output schemas completely undocumented. None of the 5 tools declare what they return, only inputs are specified. LLMs cannot plan downstream operations or extract returned data without knowing the response structure.
Tool 'message_complete_notification' does not start with an action verb. Name is noun-heavy ('message_complete_notification'). Clearer: 'send_completion_notification' or 'notify_completion'.
Descriptions are generic and lack context on when/why to use each tool. E.g., 'start_intensive_chat' says 'Creates a new chat window' but does not explain the difference from 'request_user_input' or when an LLM should choose one over the other.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Return value documentation missing. 'request_user_input' description says 'returns the user's response' but does not specify format (string, structured object?), what happens on timeout, or how to distinguish timeout from empty input.
Parameter 'sessionId' in 'ask_intensive_chat' and 'stop_intensive_chat' lacks description of format, how to obtain it, or error handling if invalid.
No error handling guidance. What happens if a session ID is invalid? If user closes window? If timeout occurs? Descriptions do not explain error cases or recovery paths.
Tool 'message_complete_notification' risk is marked READ_ONLY but it performs a side effect (sending a notification). Side effects should use proper risk categorization or the tool should be marked with a destructive hint if applicable.