JHipster 9.1.0 just dropped. For years, that sentence put a specific knot in Sam's stomach — version bumps meant a git-merge adventure, surprise conflicts, and the nagging fear of a file you'd customized getting quietly overwritten. OtakuShelf is on 9.0.0 and Sam actually likes it the way it is. So the real question isn't "how do I upgrade," it's "should I, and what will it cost me?" The agent can answer both before a single file changes.

First, how big is this really?

Sam starts by scoping it:

How risky is upgrading /Users/sam/projects/otakushelf to JHipster 9.1.0?

The upgrade_advisor tool reads OtakuShelf's .yo-rc.json and entity configs and reports back the shape of the jump:

• current 9.0.0 → 9.1.0, a minor bump;
• risk: low — no blueprints, a plain monolith, a handful of entities;
• a couple of project-specific notes (nothing alarming here) and a short checklist;
• links to the 9.1.0 release notes.

One thing Sam appreciates: the advisor doesn't invent a list of breaking changes. A minor release shouldn't have many, but for the authoritative word it points Sam at the release notes rather than bluffing. It gives the facts and the scope; the specifics live where they actually live. For a minor, low-risk bump, the verdict is "go for it" — but Sam still wants to see the damage first.

The preview that doesn't touch a thing

Show me what upgrading OtakuShelf to 9.1.0 would change.

This is the one Sam wishes had existed years ago. preview_upgrade regenerates OtakuShelf's own model in an isolated temp copy using generator 9.1.0 — fetched on the fly via npx generator-jhipster@9.1.0, so Sam doesn't even have to install it globally first — and diffs the result against the current project:

Upgrade preview → generator-jhipster@9.1.0:
  +1 added  -0 removed  ~14 modified
Added (1): ...
Modified (14): build dependency bumps, a few Vue components, Liquibase config, ...

OtakuShelf itself is never touched — it's a diff against a throwaway regeneration. And there's an honest caveat the tool states plainly: that modified list mixes two things — changes the new generator makes and files Sam has customized. Telling them apart is the real work of any JHipster upgrade. The difference now is that Sam sees the whole list up front, on a calm afternoon, instead of discovering it mid-merge at 11pm.

Fourteen modified files, mostly dependency bumps and regenerated boilerplate, nothing touching Sam's hand-edited Franchise view. This is a Tuesday, not an adventure.

Applying it Sam's way

Notice what the MCP did not do: it didn't run the upgrade. The official jhipster upgrade is a git-based merge, and this server stays deliberately out of your git — so it previews instead of merging. With the diff in hand, Sam drives the actual change through a normal workflow: commit the current state, run the upgrade (the agent can kick off jhipster upgrade through the escape hatch, or Sam runs it by hand), and resolve the handful of spots the preview already flagged. Because Sam committed first and knew the blast radius in advance, the merge is a quick, confident review rather than a leap of faith.

A ./mvnw verify and an npm test later (the MCP told Sam those commands back in part 1, remember), OtakuShelf is happily running on 9.1.0.

What Sam got out of the experiment

Four sittings ago, OtakuShelf was an empty folder and a vague idea, and Sam was skeptical about letting an AI near a generator. Now there's a paginated, DTO-backed catalog of manga and anime — scaffolded, grown, polished, and version-bumped — and at no point did the agent's involvement mean less control. The pattern that emerged was simple and stuck:

• describe the change in plain language;
• validate and dry-run before touching the project — for free, because the MCP previews by isolation, not by trusting a flag that lies;
• apply, occasionally with a backup;
• and let the agent read the real project so its edits stay surgical.

The MCP didn't replace Sam's JHipster judgment. It deleted the friction around it — the JDL typing, the CLI prompts, the upgrade dread — and left the decisions where they belong.

That's the shelf built. Time to actually add some manga to it. 📚

Want the precise arguments and edge cases behind any of this? The story motivates; the docs specify — start with the tools reference. And the server itself: jhipster-mcp on npm.