jhipster-mcp has 13 tools with mostly complete schemas and descriptions. Tool names follow verb_noun convention (validate_jdl, create_app_from_jdl, etc.), which is good. However, descriptions vary in quality, some are detailed (create_app_from_jdl: 200+ chars with dryRun explanation), others are terse (add_entity, add_relationship lack detail on what fields are required). Parameter descriptions are present but inconsistent: some params like 'blueprints' and 'extraArgs' are well-documented, others lack context on valid values or constraints. Output schemas are not explicitly documented in the visible code, tool responses are inferred from RunResult/ApplyJdlResult types but not surfaced in tool registration. Error handling is basic: no recovery guidance, no categorization of retryable vs fatal errors. The run_jhipster tool is a generic escape hatch that bypasses safety, high risk. Overall: solid foundation, but descriptions need depth, output schemas need explicit documentation, and error handling needs recovery guidance.

• Add explicit output schema documentation to each tool registration. Include field names, types, and descriptions so LLMs know what to expect. Example: validate_jdl should document that it returns {isValid: boolean, errors: string[], warnings: string[]}.
• Expand descriptions for add_entity, add_relationship, set_option, generate_ci_cd, generate_deployment to 100-200 characters. Include WHEN to use each tool and what it modifies. Example: 'Add a new entity to an existing JHipster project. Requires a valid entity name and optional field definitions. Modifies .jhipster/ directory.'
• Add parameter constraints and enums. For add_entity, document required fields (name, fields array structure). For set_option, list valid option names and their expected values. Use JSON Schema enums or pattern constraints.
• Implement error recovery guidance. When a tool fails, return actionable next steps. Example: 'JDL validation failed: syntax error at line 5. Review JDL grammar via the jdl_grammar resource, then retry with corrected syntax.'
• Restrict or remove run_jhipster, or add strict input validation and a whitelist of allowed CLI commands. Document which commands are safe (read-only) vs destructive. Consider splitting into run_jhipster_read and run_jhipster_write with separate permission gates.