Both tools have minimal, instruction-focused descriptions that fail to document what the tools actually do, when to use them, or what they return. Schemas are present but parameters lack descriptions. Tool names are action verbs but lack clarity about their role in the system. The server is designed as a terminal UI bridge, not a general-purpose tool suite, which limits applicability. No error handling guidance, no output schema documentation, and descriptions read like user instructions rather than LLM-optimized docstrings.

• Rewrite tool descriptions as LLM-optimized docstrings. Example for reply_to_terminal: 'Send a complete response to the user's terminal. Use this when the user is in a terminal-only session and you need to display your full answer. Returns success confirmation. Do not use for notifications, use notify_terminal instead.'
• Add parameter descriptions: 'text' → 'The complete response text to display. Supports plain text and ANSI color codes. Max 10000 characters.' 'message' → 'A brief notification (max 200 chars) for the terminal status bar.'
• Document output schema: both tools should return {success: boolean, message: string, timestamp: string} so LLMs know what to expect and can chain calls.
• Add error handling guidance: 'If terminal is disconnected, the tool returns {success: false, error: "terminal_disconnected"}. Retry after waiting 2 seconds or inform the user.'
• Clarify tool roles in the description: 'reply_to_terminal is for full responses; notify_terminal is for brief status updates. Use reply_to_terminal for the main answer, notify_terminal for progress or side information.'

Inferred effective spec: <=2025-11-25.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained