Single tool 'init' has a complete input schema with three parameters (project_name, prompt, output_dir), all with type definitions and descriptions. However, the tool description is minimal (18 chars in Portuguese: 'Inicializa um novo projeto usando o Zion MCP.'), falling well below the 50-200 char baseline for LLM-optimized descriptions. No output schema is documented, the tool's return type and structure are completely undocumented, making it impossible for LLMs to plan downstream actions. The tool combines multiple concerns (project initialization, code generation, file writing) without clear separation. Parameter descriptions are present but generic; 'Prompt personalizado para geração de código' lacks guidance on format, length, or examples. No error handling guidance is visible in the code.

• Expand tool description to 80-150 characters in English, answering: What does init do? When should the LLM call it? What does it return? Example: 'Creates a new project structure with generated code files. Call this first to scaffold a project. Returns a list of created files with paths and content.'
• Document the complete output schema. Specify that the tool returns {files: [{path: string, content: string}], project_path: string, status: string}. Include all fields LLMs need to reference created files.
• Split 'init' into three focused tools: create_project_structure (creates directories), generate_code_from_prompt (calls LLM), write_files_to_disk (persists files). Each tool does one thing and chains naturally.
• Add format constraints to 'prompt' parameter: 'A natural-language description of the project (50-500 characters). Example: "A REST API for managing tasks with authentication"'. Replace vague description with actionable guidance.
• Add error handling with recovery hints. Catch JSON parse errors and return: 'Code generation failed: LLM response was not valid JSON. Try a simpler prompt or check API key.' Categorize errors as retryable vs. fatal.