Tuxido provides 4 tools with partial schemas and descriptions. Two tools (validate_tui and get_framework_info) are defined in a CLI module and referenced in the MCP server via a dictionary structure (MCP_TOOLS), while two identically-named tools (validate_tui_tool and get_framework_info_tool) are explicitly registered via fastmcp decorators. The schemas are visible and reasonably well-formed with proper enums and defaults. Descriptions are present and actionable (10-200 chars range, well within baseline). However, critical issues reduce the score: (1) Tool duplication, validate_tui/validate_tui_tool and get_framework_info/get_framework_info_tool appear to be redundant, creating ambiguity for LLM selection and violating single-responsibility principle. (2) Output schema documentation is missing, tools return dicts but the structure is undocumented for downstream chaining. (3) Error handling is minimal, no guidance on recovery, categorization, or actionable error messages. (4) Parameter descriptions exist but lack format constraints (e.g., code param has no length guidance, filename has no validation rules). (5) STDIO-only transport caps score at 50 regardless of definition quality.

• Remove duplicate tools. Keep only validate_tui_tool and get_framework_info_tool (via fastmcp registration) or export both from the CLI and register once in MCP. Duplication violates single-responsibility and confuses LLMs during tool selection.
• Document output schemas explicitly. Add a pydantic model or JSON Schema comment showing the structure of returned dicts, e.g., ValidateResult with typed fields (status: str, errors: List[ErrorDetail], summary: Dict[str, int]).
• Enhance error messages with recovery guidance. Replace 'Code cannot be empty' with 'Code cannot be empty. Provide valid Python source code as a non-empty string.' or suggest a tool to call next if applicable.
• Add parameter constraints to descriptions. For 'code', add '(max 1MB, UTF-8 encoded Python source)'. For 'filename', add '(alphanumeric, hyphens, underscores, .py extension; no path traversal)'. For 'detail_level', the enum is good, keep it.
• Cap result limits on get_framework_info. Add to description: 'Returns up to 100 most-common widgets. For a complete list, pass detail_level="full" to enumerate all available.' Implement server-side limit enforcement.
• Add error classification to validate_tui. Distinguish syntax errors (user-fixable, retry guidance), forbidden imports (requires code change), and async pattern issues (design guidance). Return actionable messages per error.
• Document which fields in the response are used downstream. If other tools or the UI consume error_list or metadata fields, make those fields part of the contract and version them.