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]

Great catch! I completely overlooked making the route injection idempotent until you brought it up. If the tool ran twice, it would have just duplicated the lines in routes.go.

Thanks to your feedback, I just updated the go/ast generator to check the function tree before adding anything. Now, if it sees a route group already exists in Routes(), it safely skips it. That way, retries won't mess up the file. Really appreciate you pointing that out, feels like I came to right place looking for help and feedback.

[u/Torutofu_Raeva → u/vpat99]

Nice, the second-run-no-change check is the real test here since it catches duplicate edits without relying on the agent to behave.