This server has severe definition quality gaps. All 4 tools lack parameter descriptions entirely, a critical violation of the rubric (pattern:tool-description). Three tools (get_mcp_config, mcp_handshake, get_mcp_status) have empty input schemas {}, making them non-functional for LLM reasoning. The read_file tool has a schema but its description is generic (58 chars, below the 10 - 1024 baseline). No tool descriptions explain WHEN to use them or what they return. No output schemas are documented. Error handling is absent, no recovery guidance, no categorization. The server conflates HTTP REST endpoints with MCP tool semantics; tools are inferred from route handlers, not explicitly registered with proper MCP metadata.

• Add non-empty descriptions to all 4 tools (50 - 200 chars each). Explain WHAT the tool does, WHEN to use it, and what it returns. E.g., 'Retrieve the MCP server configuration including protocol version, supported capabilities, and list of available RTF files in the data directory.'
• Add parameter descriptions to read_file.filename: 'Name of the RTF file to read from the data directory (e.g., document.rtf). Must be a .rtf file; other formats are rejected.'
• Document output schemas for all tools. E.g., read_file returns {filename: string, content: string}. get_mcp_config returns {version: string, capabilities: string[], files: string[]}.
• Add error handling with recovery guidance. E.g., read_file 404 response: 'File not found. Available files: [list]. Call get_mcp_status to see all available files.'
• Replace empty input schemas {} with explicit schema objects. E.g., get_mcp_config: {type: 'object', properties: {}, required: []} to signal 'no parameters accepted'.