TL;DR —
jhipster-mcpis an open-source Model Context Protocol server that lets an AI agent generate and evolve JHipster applications for you. You describe what you want in plain language; the agent writes JDL and drives the JHipster CLI. It's on npm — point your MCP host at it with one line. v0.0.4 is the first public release.📦 npm: https://www.npmjs.com/package/jhipster-mcp
🧑💻 GitHub: https://github.com/avdev4j/jhipster-mcp
The idea
JHipster has always been about speed: scaffold a production-grade Spring Boot + modern frontend app in minutes, model your domain with JDL (JHipster Domain Language), and let the generator write the boilerplate.
AI coding agents are great at intent: you tell them what you want, they figure out the steps.
jhipster-mcp connects the two. It exposes JHipster as a set of MCP tools an agent can call. So instead of remembering JDL syntax and CLI flags, you say:
"Create a JHipster monolith in
/tmp/shopwith PostgreSQL and an Angular frontend, plus aProductentity (name, price) and aCategorywith a one-to-many to products. Paginate everything."
…and the agent composes valid JDL, runs the generator, and streams the result back.
Goals
- Make JHipster conversational. Natural-language intent → correct JDL → real generated code.
- Stay safe and predictable. Non-interactive, no shell, validated input, no surprise writes.
- Be machine-friendly. Return structured results an agent can reason about, not just logs.
- Lean on JHipster, don't reinvent it. It spawns your JHipster CLI; the generator stays the source of truth.
Who it's for
- JHipster developers who want to scaffold and evolve apps faster from their AI editor.
- Teams standardising on JHipster who want guardrails around how the generator is invoked.
- AI / MCP tinkerers curious about wrapping a real, stateful developer CLI as MCP tools.
If you use Claude Code, Claude Desktop, Cursor, or any MCP-compatible host, you can plug it in today.
What you can do with it
The server ships 9 tools, JDL-first:
| Tool | What it does |
|---|---|
create_app_from_jdl |
Scaffold a brand-new app from a full JDL block. |
import_jdl |
Apply JDL (entities, relationships, options) to an existing project. |
add_entity |
Add one entity with fields, validations, and per-entity options. |
add_relationship |
Add a typed relationship between two entities. |
set_option |
Toggle JDL options (paginate, dto, service, search, …). |
validate_jdl |
Check JDL for errors without modifying anything. |
generate_ci_cd |
Scaffold a CI/CD pipeline (GitHub, GitLab, Jenkins, …). |
info |
Inspect project versions, config, and entities. |
run_jhipster |
Escape hatch — run an allowlisted subcommand safely. |
It also exposes a JDL grammar cheat-sheet as an MCP resource, so the agent writes valid JDL on the first try.
What's in v0.0.4 — the highlights
This first release focuses on making every tool call trustworthy and legible to the agent:
🔄 Live progress streaming
Full app generation can take 30–90 seconds. Instead of looking frozen, the server streams the generator's output as MCP progress notifications in real time.
✅ Validation + a true dry-run
You can validate JDL or preview a change without touching your project.
There's a fun gotcha here: JHipster's own --dry-run flag only prints conflicts — it still writes files (I confirmed this against the real CLI). So a flag-based "preview" would silently modify your project. jhipster-mcp instead does a real preview: it generates in a throwaway temp directory (copying your project's .yo-rc.json and .jhipster/ for context), parses what would be produced, and discards everything. Your project is never modified.
📦 Structured output
Every tool returns machine-readable JSON alongside the human-readable text, so the agent reasons on data instead of scraping logs:
{
"command": "jhipster jdl changes.jdl --force --skip-git",
"exitCode": 0,
"success": true,
"dryRun": false,
"entities": ["Customer", "Order"],
"filesChanged": [{ "action": "create", "path": "src/main/java/..." }],
"warnings": []
}
Why it's safe by design
-
No shell. The CLI is spawned with
shell: falseand an argument allowlist — no command injection. - Validated JDL builders. Entity/field/type names are checked against strict patterns before any JDL is written.
-
Non-interactive always. Runs with
--force --skip-gitandCI=true; never hangs on a prompt. -
Bounded. Every tool takes an explicit
workingDirectory; the server won't act outside it.
Under the hood it's TypeScript on the official MCP SDK, with 70 tests and CI on Node 22/24.
How to use it
1. Prerequisites
- Node.js 20+
- A working global JHipster CLI:
npm install -g generator-jhipster
jhipster --version
2. Add it to your MCP host
Claude Code:
claude mcp add jhipster -- npx -y jhipster-mcp
Claude Desktop / Cursor / others — add to your MCP config:
{
"mcpServers": {
"jhipster": {
"command": "npx",
"args": ["-y", "jhipster-mcp"]
}
}
}
No clone, no build — npx fetches and caches the package for you.
3. Just ask
"In
/Users/me/projects/shop, add aCustomerentity with firstName (required, 2–50 chars), lastName, and email, then a one-to-many from Customer to Order."
The agent reads the JDL grammar, builds the snippet, and applies it — streaming progress as it goes.
Want to look before you leap? Ask it to preview first:
"Show me what adding a
Tagentity would change — don't write anything yet."
…and it runs the same tool with dryRun: true.
What's next
This release completes the "Tier 1" experience work (progress, validation/dry-run, structured output). On the roadmap:
-
Project-state resources — let the agent read
.yo-rc.json, the entity list, and exported JDL directly. - Guided prompts — reusable workflows like "scaffold a CRUD monolith" or "convert to microservices".
- Safe-apply with rollback, elicitation for missing config, and sandboxing.
Try it
npx -y jhipster-mcp@0.0.4
⭐ Star it, break it, and tell me what's missing: https://github.com/avdev4j/jhipster-mcp
Built with ❤️ for the JHipster community.
#jhipster #ai #mcp #java #springboot #opensource
Top comments (1)
This pairing is smarter than the usual "let the agent write the code" approach, and it's worth saying why: JHipster already encodes a ton of hard-won correctness in its generators (auth, persistence, the boilerplate that's boring precisely because it has to be right), so having the agent drive JDL and the CLI instead of free-handing Spring Boot means the determinism lives in the generator and the model only owns the part it's actually good at, translating intent into a domain model. That's the durable shape for agentic scaffolding: model proposes the JDL, a battle-tested generator produces the code, far fewer ways to be subtly wrong than an LLM emitting controllers from scratch. I build Moonshift on exactly this instinct, lean on deterministic generators for the boring 80% and reserve the model for intent and the genuinely custom 20%. The "evolve" verb in your title is the spicy part though, scaffolding clean is one thing, but driving JDL changes against an existing app means migrations and merge conflicts. How are you handling evolution without clobbering hand-written code the generator doesn't own?