This MCP server provides 7 Russian text analysis tools with comprehensive descriptions and structured schemas. Tools are well-named with action verbs (humanizer_scan, humanizer_detect, humanizer_clean, etc.) and descriptions explicitly state WHAT the tool does, WHEN to use it, and WHEN NOT to use it. Input schemas are present and validated against a canonical contract.v1.json. However, significant issues exist: (1) enum constraints are EMPTY for genre and marker_class parameters across multiple tools, breaking parameter validation; (2) parameter descriptions are duplicated across tools and in Russian, potentially limiting LLM comprehension; (3) error handling guidance in descriptions is minimal, no recovery hints like 'call search_users() first'; (4) output schemas are referenced but not fully visible in the MCP tool definitions themselves; (5) tool composition could be improved, humanizer_facts and humanizer_report do similar change-tracking work; (6) STDIO transport caps this at 50 maximum, but definition quality alone is moderately solid (62 if transport-independent).

• Populate the enum constraints for genre and marker_class parameters. Load effective values from contract.v1.json's 'effective_by_tool' block at server initialization and inject them into tool definitions. This prevents LLM hallucinations and makes valid options discoverable.
• Translate parameter descriptions to English or provide bilingual descriptions. Use primary description in English (matching LLM training data) with optional Russian translation. E.g., 'Text to analyze (Russian prose; empty/non-Russian input is out of scope). / Обрабатываемый текст (русский связный текст; пустой вход, out-of-scope).'
• Add explicit outputSchema to each MCP tool definition. Extract from contract.v1.json and include in the tool registration. Document at least the top-level fields (e.g., for humanizer_scan: { markers: [...], confidence: number, language: string }).
• Add error recovery hints to tool descriptions. Example: 'If text is non-Russian, call humanizer_detect() first to confirm language.' Example: 'If genre is invalid, check available genres via humanizer_scan().'
• Merge or clearly distinguish humanizer_facts and humanizer_report. If both are needed, explicitly state: 'humanizer_facts returns structured diff metrics; humanizer_report returns a human-readable formatted report. Use facts for programmatic validation, report for human review.'
• Provide examples in the tool description (without literal example values in the description text itself). Instead, reference the contract.v1.json examples block or a separate examples endpoint to avoid LLMs copying example data literally.