Zügel MCP Server

What Value Do You Get From Using Zügel?

We created Zügel to be the architectural conscience of your coding agent. It maintains its own dependency model of the project you are working on and therefore can answer many questions that are hard to answer for an agent without Zügel. Good architecture rests on two pillars: an architectural model reflected by the code and a good dependency structure that avoids cyclic dependencies as much as possible. Both of those pillars are covered by Zügel.

One good thing is that it already works without an architectural model. Just by helping agents to avoid cycles it will always be possible to add a fine-grained architectural model later. And you don't even have to write that yourself. Just tell the agent what you want and the agent will implement it based on Zügel's explanation of the .arc language features. It could be as simple as "use a layered architecture divided by domains".

To ensure that the tool actually provides real value, we ran two controlled experiments using the strongest coding agent available. Everything below is measured. Where the numbers did not support a claim, we say so — the last section is there so you can trust the rest.

Your architecture, checked before the code is written

Zügel turns your architecture into something the agent can ask about. In our experiment the agent proposed 52 dependencies and was refused 49 times — including both directions of the classic Order ↔ Customer and Order ↔ Shipment pairs, the mutual references that quietly create package cycles in every business application. It rerouted through shared identifier types instead. Nothing was written, nothing had to be reviewed, and the codebase finished with zero cyclicity.

The rules are a file the agent writes and maintains itself. Starting from nothing but Zügel's own explanation of the DSL, it produced an 83 line architecture specification and grew it to 279 lines as the project grew — and it never once relaxed a rule to unblock itself. Unlike a written architecture document, the rules survive the next session, because the next session can check them.

Dependency cycles can easily fly under the radar

Architecture rules verify boundaries you have declared. A dependency cycle is not always a boundary breach: it is a structural problem in its own right — and if left untouched it could very well become the kernel of a big ball of mud. While building Zügel itself, one of our own sessions produced a cycle of eleven classes. Every dependency in it was legal, all eleven lived inside the same architectural artifact, and zero violations were reported. Neither a rule engine nor a code review would have caught it, because each individual dependency was perfectly reasonable. Only cycle detection saw it, and it was gone again before the session ended.

Prevention is cheap. Repair is not.

We took jPOS, a real payments framework of 734 classes with a large tangle, and asked an agent to clean it up. Two sessions removed 89% of the class level cyclicity and 94% of the package level cyclicity without breaking a single one of its 3922 tests. It cost about 25 dollars of agent time and just under an hour — and it was only safe because jPOS has a test suite that runs in under a minute. Most codebases do not.

Preventing the same problem costs one tool call. That is the entire argument: the same outcome, two orders of magnitude apart in price.

Without it, you finish and believe you are done

We ran the same cleanup with no tooling at all — just the source and a capable agent, which is the situation most developers are in. It was the fastest and cheapest of our runs, it kept every test green, and it reduced package cyclicity nearly as well, because two packages referencing each other can be seen by reading the code.

It also left an eighteen class cycle and an eleven class cycle untouched, where the tooled run had removed them. A strongly connected group of eighteen classes is simply not visible by reading code. The untooled run fixed what it could see, left what it could not, reported success — and by every signal available to it, it had succeeded. In other words, without Zügel agents are blind when it comes to cyclic dependencies on the source file level.

If you need to fix a tangled code base, Zügel can really help

Because Zügel maintains its own dependency model, it can run a variety of graph algorithms over it and work out how to break file and package cycles with the least effort — an exact minimum cut where the group is small enough to solve, and a split that shrinks it where it is not. An agent without a dependency model has to infer all of this from reading source, and as the run above shows, it does not see the worst of it at all.

Knowing when to stop matters just as much. At the end of the jPOS cleanup, with the metric already down by more than 90%, Zügel found that moving a single file into a neighbouring package would dissolve another cycle outright, with not one import to update. For the knot that remained it said the opposite: no file move can help, this one needs real design work. Nobody goes looking for a one file fix after the hard part is done, and nobody can tell by eye whether what is left is expensive or merely unfound.

The same rules become your CI gate

Zügel reads Sonargraph's architecture DSL, so there is no second definition to maintain. The rules your agent consults before writing a dependency are the rules Sonargraph enforces on your build. Zügel prevents locally, in the agent's loop; Sonargraph gates globally, on the merge, where work from several people comes together and a set of individually clean branches can still add up to a tangle. We run exactly this arrangement on our own CI every day.

What our numbers do not show

We did not find a reliable saving on ordinary feature work. Across eight increments the difference in cost was small and changed sign from one increment to the next, although on the later ones — where the codebase was larger — the agent with Zügel was consistently around 40% cheaper and faster. That trend is the most interesting open question we have, not an established result: it comes from a single run.

We also did not find that a capable agent tangles a small, new codebase on its own. On a young project of a few thousand lines it mostly copes. The value shows up as the codebase grows, and in the tangles the agent cannot see for itself.

One result we did not expect: given no tooling, the agent built its own architecture checker, unprompted, and wrote in its comments that "a rule that is only written down drifts; this test makes it fail". It was right about the problem. What it built could not detect a single cycle, and it worked only by reading import statements. Since plenty of dependencies are not covered by an import — anything in the same package, or written as a fully qualified name — it could even miss real architecture violations.

What it costs

A Zügel subscription is 138.00 USD per year, which works out at 11.50 USD a month — less than half of what that one jPOS cleanup cost in agent time alone. Every Sonargraph-Architect license comes with a free accompanying Zügel license.

Get started