XINCODE provides 10 tools with schemas and descriptions in Chinese. Naming follows verb_noun patterns (agent_plan, ask_reasoning, execute_code, code_graph, cronjob, current_time, describe_image, env_exec, generate_image, get_memory_by_title). Descriptions are present (avg ~150 chars) and explain WHAT and WHEN. However, critical gaps: (1) No output schemas documented for any tool, LLMs cannot predict return structure; (2) Parameter descriptions lack format/constraint details (e.g., 'schedule' in cronjob accepts '30m'/'2h'/'every 1d' but this is buried in description, not formalized); (3) No error handling guidance, tools return success/failure but don't guide recovery; (4) env_exec and execute_code are high-risk (DESTRUCTIVE/READ_ONLY) but lack confirmation patterns or dry-run support; (5) Tool definitions inferred from Kotlin source rather than explicit MCP registration visible in code. Strengths: consistent naming, reasonable description length, parameter types mostly present (string, integer, array, object).

• Add output schema documentation for every tool. Example for agent_plan: 'Returns {status: string, plan_id: integer, steps_completed: integer, current_step_id: integer}'. Use JSON Schema format.
• Formalize parameter constraints as enums or patterns in the schema, not just descriptions. E.g., cronjob.schedule should be enum: ['30m', '2h', '1d', 'every 30m', 'every 2h', 'every 1d'] or a regex pattern.
• Add error classification and recovery guidance. E.g., 'If code_graph returns "index not ready", call code_graph with action=status first, then retry. If "symbol not found", try a broader search term.'
• Implement confirmation/dry-run for destructive tools. env_exec should accept a 'dry_run=true' parameter; execute_code should warn about side effects and require explicit confirmation for file operations.
• Provide explicit MCP tool registration code (e.g., in a server.ts or main.rs) showing how tools are registered with the MCP protocol, including full schemas and descriptions.