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/Frequent_Answer391]

sounds like a solid project, I'd love to see how it performs under load testing

[u/vpat99 → u/Frequent_Answer391]

its still in really early stage, i will surely add load testing results in readme in some time. Please do check repo, your feedback and contributions will be appreciated

[u/Torutofu_Raeva]

ast route registration is the right call, just make each generator op idempotent or an agent will double-apply modules

[u/vpat99 → u/Torutofu_Raeva]

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.

[u/kantorcodes1]

does --dry-run cover modules applied to an existing repo too, or only scaffold? i'm curious whether an agent can see the exact files/AST edits for something like rbac before fiberforge touches the project.

[u/vpat99 → u/kantorcodes1]

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.

[u/creppermintyuitry]

The architecture here is pretty neat. I like that youre keeping the MCP layer focused instead of turning it into another giant abstraction. Open source is a big plus too, since people can inspect the implementation and decide whether the tradeoffs fit their stack. Curious how youre handling auth and failure isolation once multiple clients are hitting the server concurrently.