Critical failure across all dimensions. Of 31 tools, only 6 have visible definitions in source code (smartstore, imweb, cafe24, threads_create_container, threads_publish, elevenlabs). The remaining 25 tools are declared only in .mcp.json config files with brief comments, no input schemas, no parameter descriptions, no output schemas visible. Even the 6 tools with source code lack proper schema documentation. Tool descriptions are present but generic (90-200 chars), lacking LLM-optimized guidance on WHEN to use each tool vs alternatives. No parameter descriptions found in any tool. No error handling patterns visible. This server is a thin wrapper around external APIs with minimal MCP-native tooling.

• Add explicit JSON Schema input definitions for all 31 tools. Each tool must declare parameter types (string, number, boolean, array, object), required fields, enums for constrained values, and min/max for numeric ranges. Use fastmcp's @mcp.tool decorator with proper schema annotations.
• Write LLM-optimized descriptions (50-200 chars) for each tool that answer: WHAT does it do? WHEN should the LLM call it instead of similar tools? WHAT does it return? Example: 'korean_law_search: Search Korean laws, precedents, and administrative rules by keyword. Use this FIRST to find relevant statutes before cite_check or applicable_law. Returns law ID, title, article text, and enactment date.'
• Add parameter descriptions to every input parameter. For each param, state: what it controls, valid values/ranges, format (ISO 8601 for dates, email format, etc.), and whether it's required. Example: 'query (string, required): Search keyword or phrase (1-500 chars). Supports Korean and English. E.g. "근로기준법" or "minimum wage".'
• Implement error handling with recovery guidance. Catch API errors and return structured responses like: '{"error": "User not found", "suggestion": "Try search_users() with a partial name", "retryable": false}'. Categorize errors as retryable, user-fixable, or fatal.
• Document output schemas for all tools. Specify what fields are returned, their types, and which fields are safe to pass to downstream tools. Example: 'Returns {law_id: string, title: string, articles: [{article_num: string, text: string}], enactment_date: ISO8601}'. This enables tool chaining.