Engineering · Benchmark

We taught our automation MCP to write code, not JSON — and it got cheaper and smarter

The automation below has 30 steps and six AI agents. It was built in under a minute, from a single sentence.

By the Ooperon team · Updated August 2026 · 5 min read

No dragging nodes around a canvas. We described what we wanted and Ooperon's MCP built the whole thing as a draft we could review and ship. Here's how we got there, and why it beats the way most automation MCPs work today.

The problem with tool-calling MCPs

Most automation MCPs — the n8n-style ones — work the same way: they hand the model a giant catalog of nodes and ask it to emit JSON, one tool call at a time. That's fine for a two-step flow. It falls apart the moment things get real.

The model guesses field names. It invents record IDs that don't exist. It re-reads the same schemas on every step, so the token bill balloons. And it has no compile-time safety net, so a subtly wrong config sails through until something breaks in production.

What we built: author-as-code

Instead of asking the model to emit JSON, Ooperon generates a typed TypeScript SDK from your actual connected tools. The AI writes real code against it. Then, before anything is saved, we type-check the code against the full node registry, run it in an isolated sandbox to produce the automation graph, and validate it against your real workspace — your tags, pipelines, and connections.

The result: the model physically cannot save a broken automation. If it hallucinates a node or an ID, the type-check or the validator rejects it. And because AI agents are first-class steps, it can build flows where the automation itself holds the conversation, qualifies the lead, and books the meeting.

We didn't just claim it. We benchmarked it.

We built 22 automations, from dead-simple to genuinely brutal (multi-agent, branching, merging paths), and ran each one twice on a deliberately cheap model, GPT-4o-mini. Then we put the standard tool-call approach head to head against our code-act approach, scoring the actual automation each produced, not the interface.

On simple tasks both approaches are fine. But as the automations got harder, tool-calling cracked — it failed to build many medium and complex flows at all. Code-act built and scored on tasks the tool-call approach couldn't complete.

Cheaper and more accurate, on a budget model. That combination usually doesn't exist.

Why it matters

Most “AI automation” is a demo that dies the moment the workflow gets real. The interesting result here is the opposite: our approach gets stronger as the tasks get harder, because the type system and validator do more work exactly when the model is most likely to slip.

If you run revenue operations on a CRM and you've ever lost an afternoon wiring up a follow-up sequence, this is going to feel like cheating. Describe it once. Review the draft. Ship it.

Benchmark details: 22 automations across four difficulty tiers, two runs each, GPT-4o-mini, scored on structural correctness against a live registry. The scorer grades the produced automation, not the interface, so the comparison is apples to apples.