This server exposes 3 tools with critical definition gaps. The 'call' tool accepts arbitrary arguments as an untyped object with no validation schema, parameter constraints, or output documentation. 'tools' and 'check_connection' lack any parameter descriptions. None of the tools document their return schemas or error handling. Descriptions are present but generic (10-50 chars), below the 50-200 char baseline for LLM-optimized tools. No tool declares what it returns, when to use it, or how to handle failures. This is a thin CLI wrapper around an external MCP server, not a production-grade tool definition.

• Add explicit JSON Schema for 'call' tool: define 'name' as enum of available tool names (or string with pattern), and 'arguments' as object with additionalProperties: true but document expected structure per tool.
• Document output schemas for all tools. E.g., 'tools' returns {type: 'array', items: {type: 'object', properties: {name, description, inputSchema}}}. 'call' returns {type: 'object', properties: {result, error}}.
• Expand descriptions to 80-150 characters. E.g., 'tools': 'List all available tools from the connected MCP server, including their names, descriptions, and input schemas. Call this first to discover what operations are available.'
• Add parameter descriptions. Document what 'name' and 'arguments' mean in 'call': 'name: The exact name of the tool to invoke (string). arguments: A JSON object with tool-specific parameters (object).'
• Implement error classification and recovery guidance. Catch connection timeouts, JSON parse errors, and tool-not-found cases separately. Return structured errors like {error: 'tool_not_found', message: 'Tool X not found. Available tools: [...]', retryable: false}.