The server implements 3 MCP tools with visible schemas and basic descriptions. However, there are significant quality issues: (1) tool_http_get_domains has identical parameter schema to tool_get_domains but no implementation (just 'print(ctx)'), making it non-functional; (2) descriptions are in Chinese and very short (13-17 characters), below the 34-char p10 baseline and violating the 20-char minimum rule for actionable descriptions; (3) no parameter descriptions exist, the 'domains' array and 'domain'/'color' params lack explanation of purpose, format, or constraints; (4) no output schemas are documented despite tools returning structured responses; (5) no error handling or recovery guidance. The schemas themselves are syntactically valid JSON Schema but lack semantic richness (no min/max for arrays, no examples, no format directives). The naming convention (tool_* prefix) is clear but redundant with MCP's tool namespace. Per-tool: tool_get_domain has enum constraints for 'color' which is good, but 'domain' param lacks validation rules. Tool composition is reasonable (separate batch vs single domain operations), but the HTTP variant appears broken.

• Rewrite all tool descriptions in English (or the target LLM language) and expand each to 50-150 characters, explaining purpose, when to use, and distinction from similar tools. E.g., 'Retrieve domain registration details (name, color/status tag, expiration) for a single domain. Use when you have a domain name and need metadata. Prefer tool_get_domains if querying multiple domains.'
• Add descriptions to every parameter. For 'domain': 'Domain name (FQDN or apex domain, e.g. example.com). Max 253 characters. Do not include protocol or path.' For 'domains': 'Array of domain names to query. Max 100 items; duplicates ignored. Each entry must be a valid FQDN.' For 'color': 'Domain color/status tag: red=inactive, green=active, blue=reserved. Determines priority or filtering in responses.'
• Document output schemas in code comments or structured form. For tool_get_domain, specify: 'Returns {domain: string, color: string, status?: string, expires_at?: ISO8601_date}.' This enables LLMs to reason about what fields are available.
• Add input validation constraints to schemas: domains array with minItems=1, maxItems=100; domain string with minLength=3, maxLength=253, pattern='^[a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(\.[a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$' (basic FQDN check).
• Implement tool_http_get_domains or remove it. If it is meant to differ from tool_get_domains (e.g., timeout, rate limit, response format), document the distinction clearly. If it is a duplicate, delete it.
• Add error handling with recovery guidance. E.g., 'If domain not found, return {error: "domain_not_found", suggestion: "Try search_domains() to find similar domains."}' or 'If domains array exceeds 100 items, return {error: "batch_size_exceeded", max_size: 100, suggestion: "Split into multiple requests."}.'