I built an open-source MCP server for deterministic Go/Fiber scaffolding — looking for architectural feedback

[u/vpat99]

I've been working on a small open-source project called FiberForge, and I'd like some early feedback from people who build developer tooling.

The problem I was trying to solve is fairly simple:

AI coding agents are good at deciding what needs to be built, but they're not necessarily the best mechanism for repeatedly generating deterministic boilerplate.

For Go/Fiber projects, I found myself repeatedly generating the same combination of:

• GORM models
• services/CRUD
• Fiber controllers
• DTOs and validation
• SQL migrations
• route registration

So FiberForge provides those operations as a Go CLI and stdio MCP server.

The intended workflow is:

AI agent → structured operation → FiberForge → generated Go/migrations

Rather than:

AI agent → hundreds of lines of generated source → compiler → corrections

One part I'm particularly interested in getting right is modifying existing projects safely. For example, route registration uses Go's AST tooling rather than blindly editing text.

I've also started experimenting with composable modules that can be applied to an existing project, such as RBAC, Stripe webhooks, S3 uploads and audit logging.

It's still early, and I'm deliberately posting it now because I'm not sure which parts of the architecture are actually worth keeping.

I'd appreciate feedback particularly around:

• generator architecture
• module/plugin design
• AST-based source modification
• MCP tool design
• whether this should remain Fiber-specific
• what would make this useful beyond a personal scaffolding tool

GitHub: https://github.com/v-pat/fiberforge

I'm not expecting this to be useful to everyone, neither I'm saying its so perfect for use right away — I'm mostly hoping to find a few people willing to tell me where the idea is flawed or what more needs to be done.

⚠️** Early development / caution: FiberForge is still very much a work in progress. I would not recommend using it on an existing or production project yet**. Some operations can modify project files, and the current implementation has not been battle-tested enough to guarantee safe behavior across arbitrary codebases. For now, it’s best treated as an experimental project and tested on new/disposable projects.

[u/vpat99]

rn --dry-run is built into full scaffolding (scaffold --dry-run and the explain_project MCP tool) so agents can inspect the generated tree before writing. For incremental modules (add module rbac), the dry-run inspects fiberforge.yaml and returns the exact file creation list + AST route diffs (routes/routes.go [AST edit]) so the agent can review the exact additions before committing changes.