Menu
Zügel MCP Server
Zügel is the German word for rein. In this metaphor we consider your coding agent to be a powerful and fast horse with its stubborn own will. You as the rider will need a rein to control it and guide it in the right direction.
AI productivity gains are strongly correlated with clean architecture
Currently, software architecture is not the strongest feature of AI coding agents. They are trained to optimize locally and therefore never consider the big picture when implementing a task. That will lead to architectural erosion, which makes it harder to understand and maintain the code. Moreover, a recent Stanford study that wanted to measure productivity gains from AI usage for 120 thousand developers found that the average productivity gain was only about 10%. But the outcomes between different teams were dramatically different. Some teams more than doubled their productivity while AI actually slowed down others. The best predictor for positive outcomes was the cleanliness of the code base the agent worked with. Cleaner and well-structured code bases lead to better results. Messy code bases lead to messier results. In other words, AI amplifies what it finds.
Zügel prevents architectural and structural erosion of AI generated code
The idea of Zügel is simple: assist the coding agent to respect your architectural intent and avoid adding cyclic dependencies. Those two features form the pillars of any well-architected code base. Coding agents need constraints to produce usable results. Without those constraints it is almost certain that the generated code will lose architectural cohesion over time and introduce more and more tangles, especially when several people work with agents on the same code base. And once the structural erosion kicks in it will create a self-reinforcing loop that will accelerate the deterioration.
So Zügel's most important contribution to your project is prevention. Every time the agent wants to add a new dependency it can ask Zügel whether that dependency respects the architecture and does not create or enlarge cyclic dependency groups. If the agent gets a negative reply Zügel helps with finding a correct alternative. So just by running Zügel with your agent you have a guarantee that the structure of your project will not end up as a big ball of mud. Moreover - if you have defined an architectural model using our architecture DSL (domain specific language) you also can be sure that all generated code respects the architecture. Prevention happens at the earliest possible moment - even before the agent generates code. No need to wait for a CI build to find out that something is wrong.
Even better - you can create the architecture using prompts. Zügel teaches the architecture DSL to the agent, so you can just say "Create a layered architecture split into domains". The agent will then create the architecture DSL file for you and use it to verify new dependencies.
Zügel also keeps track of its prevention work by maintaining a ledger. So you can actually ask the agent about the contributions of its sidekick. Also, you can be sure that with Zügel your project data never leave the machine Zügel is running on.
Disentangle legacy code bases
Since Zügel keeps a complete dependency model of your application in memory (currently supporting Java, C# and Python) it can also propose refactorings that would improve the structure of your application. That is a really valuable capability for any legacy code base. Many of them turned into a big ball of mud over the years. By using clever graph algorithms it can compute optimal breakup sets for cyclic dependencies on the file and directory/package/namespace level. That already works even without an architectural model, although in that case the breakup set is just based on the shape of the dependency graph. If you add an architectural model the breakup analyzer will take your architecture into account, which will produce even better results.
We tested that on an open source project named jPOS. The checked out version from August 2026 had a component (file) cyclicity of 1,147 and a package/directory cyclicity of 361. In just one afternoon with Claude and Zügel we were able to reduce component cyclicity by 79% (down to 242) and package cyclicity by 52% (down to 173) without breaking a single test. Of course that afternoon would not have been necessary if Zügel had been used on jPOS from the beginning.
On the fly we also created a basic architectural model for the existing code, and that turned out to be the turning point rather than a detour. Package structure barely moved while Zügel had only the shape of the dependency graph to go on. Once the architecture was declared, it could nominate cuts from your rules instead, and the final step of the exercise was the cheapest since that work began, as well as the one that improved the package structure the most. An architecture definition is not overhead you pay before the work — it is what makes the work cheap.
So if you need to break up a big ball of mud or modernize a legacy code base, Zügel tells you something your build cannot. All 4,437 jPOS tests were green at every checkpoint of that afternoon — including at the very start, at a cyclicity of 1,147. A passing build tells you the code still works. It tells you nothing about whether the structure just got worse, and by the time anyone notices, the cheap moment to fix it has passed.
Fix your existing architecture violations
Once you have an architectural model Zügel will know all the places in the code where a dependency violates your architecture rules. You can then simply delegate the fixing of those violations to your coding agent. That delegation works because the agent is not being asked for judgment it does not have: your rules already say which dependencies are legal, so Zügel can hand it the permitted alternatives together with the problem. Finding violations is not new — Sonargraph has done it for two decades. What is new is that the list is in your agent's hands while it works, and that it is refreshed on every change.
Fixing violations also does more than tidy up the rule book. On jPOS it was what broke the remaining tangle: once the architecture had been declared, Zügel reported that the surviving 16-package cycle could be broken by fixing violations alone, with no further cuts at all. The two repairs taken from that list produced the largest package improvement of the whole exercise. Structure and rules are not two separate problems — repairing the second is often how you repair the first.
We build Zügel with Zügel
Zügel's own source code is governed by Zügel. Its architecture is defined in an architecture DSL file, and the agent working on the server has to ask permission for every new dependency, exactly like the agent working on your code. At the time of writing that leaves the project at zero architecture violations, no component cycles and no package cycles at all — not as a cleanup we once did, but as a state neither we nor our agents are allowed to leave.
The product also improves where it is used. The jPOS afternoon described above produced eight Zügel releases while it was still running, every one of them from a gap we hit doing the actual work — the single most useful piece of information the tool offered during that exercise did not exist when the exercise started. Taking a real legacy code base apart with the tool is how the tool gets built.
Zügel and Sonargraph
You could think of Zügel as the Sonargraph-Architect for the coding agent. You can use Zügel completely independent of Sonargraph, but if you already have Sonargraph-Architect you get one Zügel license per Sonargraph-Architect license for free. If your project is already set up for Sonargraph-Architect you can generate Zügel's configuration file directly from Sonargraph. Your active architecture definitions will automatically be added to the Zügel configuration.
Using them together gives you additional benefits like architecture checks via Sonargraph-Build, an editor for the architecture DSL with error checks and autocompletion and of course powerful dependency visualizations.
How to use Zügel
To help you to get started, we wrote a short article first step with Zügel. The full Zügel manual can be found in this article that explains how to work with Zügel in more detail. It is updated everytime we add new features to Zügel. You can download the Zügel launcher directly from our download section.
Get started
Try our tools on one of your project. Evaluations are free and without obligation. Get registered or login to be able to download our products and request evaluation licenses.
Create an Account Login White Papers