Loop Engineering, Applied: Syncing a Moving API into an MCP Server

I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.

— Boris Cherny, Claude Code lead at Anthropic

That line, along with a similar one from Peter Steinberger, started a wave of interest in what is now called loop engineering. Addy Osmani describes it as replacing yourself as the person who prompts the agent. You design the system that does the prompting instead. The leverage moves from writing a good prompt to designing a good loop.

It is an appealing idea, and it deserves some caution. Rather than add another opinion piece, we want to show the practice on a concrete, unglamorous problem: keeping our MCP server in sync with a moving API. It turned out to be a good fit for a loop, and a clear illustration of where the judgment, the determinism, and the human each belong.

The drift problem

We ship a Model Context Protocol (MCP) server that gives agents, ours and our customers’, tools for talking to the Rapidflare platform. Those tools are thin wrappers over two backend APIs. The MCP server does not import the backends’ code. It talks to them over HTTP and generates its client from each API’s OpenAPI spec (openapi.json).

That design is clean until the APIs move, which they do often. A backend adds an endpoint, changes a request schema, renames a field. The moment that happens, three things drift out of sync:

1. The committed spec in the MCP repo is stale.
2. The generated client no longer matches the real API surface.
3. The MCP tools do not expose the new capability at all.

The old fix was a checklist someone ran by hand: pull the new spec, regenerate the client, read the diff, hand-write wrappers for anything new, run the tests, open a PR. It works. It is also the kind of repetitive, error-prone task that quietly rots, where someone forgets a step or the resync lags the API by weeks. In practice, the wrapper re-writes and updates were done with AI coding tools, with an evolving but loosely captured skill combined with these tools just following the lay of the land.

This is the shape loop engineering is for: a recurring, well-defined task, with one or more AI/agentic steps in the workflow, and which you would rather not babysit. So we built a loop.

Why the spec keeps moving

It is worth asking why the API changes so often, because the answer is the real reason this loop matters.

Like many web platforms, our API’s initial and primary client was the UX along with various internal CLIs and other tooling. However, our platform is rapidly evolving toward an agents-first architecture. More and more of the operational work, the tasks a human operator used to click through, is done by agents running skills. This transformation is taking place from two different directions at once - our operations, and our customers’ interactions with the platform.

Those agents reach the platform through the same MCP tools our customers’ agents use. That makes our own agents the most demanding users of the tool surface, and it changes where API changes come from.

Part of how we build a skill is to have the agent run the task and then report back on the ergonomics of the tools it had to use: a confusing parameter, a missing endpoint, a response that forced three calls where one would do, a tool that is easy to misuse. That feedback becomes pressure on the API. The tools get reshaped by the agents that have to use them.

This is early, and it is a nascent loop rather than a finished one. But the direction is clear. The changes to the API increasingly originate from the agents consuming it. That puts the sync loop in a more interesting position than “keep the client fresh.” It is the propagation arc of a larger loop:

1. an agent uses the tools
2. that interaction surfaces ergonomics feedback
3. the API and MCP wrapper is tweaked in response
4. documented agent skills are updated to reflect the improved tool surface

The sync loop carries that change back out to every agent, and the next agent works with a better tool surface. The consumers are shaping the producer, and the sync loop keeps that honest and current.

That’s the context - in this post we’re talking about the inner, more engineering-flavoured loop - keeping the API and MCP in sync.

Anatomy of the resync

The manual procedure has a fixed shape.

• sync — pull the new openapi.json into the repo
• prepare — normalize it for the code generator
• codegen — regenerate the typed HTTP client
• diff — compute what actually changed
• curate — turn genuinely new endpoints into well-formed MCP tools, following our tool-mapping pattern
• verify — lint, type-check, run the test suite
• PR — open a pull request for review

Those seven steps split into two kinds, and the split is the whole design.

Six mechanical steps, one that needs judgment

Six of the steps are mechanical. Given the same spec, they produce the same output every time. Sync is a file copy. Codegen is a deterministic transform. Diff is set arithmetic. Verify is a test run. None of them need intelligence. They need a script.

One step needs judgment: curate. Our tool wrappers are deliberately thin, but they are not a mechanical pass-through of the API. We set the pattern for how a tool should map to the API: how it is named, what it exposes, how its parameters are shaped, and how it is made safe to call. Turning a new endpoint into a good MCP tool means deciding whether it belongs on the tool surface at all, and then fitting it to that pattern.

That step is itself done by Claude, running a highly refined skill that encodes the pattern, applies it to new endpoints, and flags anything new or ill-fitting for a person to weigh in on. It is reasoning work, not code generation, which is exactly why it is the one place we spend the model.

This distinction runs right through the loop-engineering writing. Armin Ronacher, reflecting on where loops actually work, argues they are strongest on clearly verifiable mechanical translation, and on artifacts that do not need a long shelf life. They are riskiest when generating lasting code unsupervised. Our codegen is exactly the safe case: a verifiable translation from spec to client. Andrew Ng frames the same discipline in control-theory terms, where the hard part of a loop is defining what it controls, how error is detected, what actuator corrects it, and where it stops. For us the loop controls spec-to-tool agreement, the error signal is the spec diff, the actuator is the resync, and the stop condition is an open PR.

The rule we settled on: keep the deterministic steps deterministic, and reserve the model for the one step that genuinely needs a mind. Every step you hand to an LLM is one that can be non-deterministic, slow, and costly. Every step you keep as a script is one you can reproduce and trust. We did not want an AI that resyncs the repo. We wanted a deterministic pipeline with a single, well-bounded reasoning step inside it.

Wiring it into a loop

Ronacher draws a useful line between two loops. There is the agent loop inside every coding agent: call a tool, read the result, edit a file, run tests, repeat. And there is the harness loop outside it, the system that decides whether the agent’s “done” is really done and what happens next. Loop engineering is mostly about that outer loop. Ours looks like this.

When a backend merges an API change to main, a GitHub Actions workflow fires a repository_dispatch at the MCP repo. That triggers a workflow which runs Claude Code headlessly, the same agent we use interactively, running unattended in CI on AWS Bedrock, pointed at a skill that encodes the resync procedure.

The agent runs the whole pipeline and opens a pull request. It never pushes to main. A human reviews the PR and merges. The harness loop wraps Claude Code’s agent loop, and the pull request is the only place a person is required.

The procedure lives in a skill

The reasoning step is not a free-form “figure it out” prompt. It is a skill: a version-controlled document that captures the procedure, the per-API conventions, and the guardrails, living in the repo next to the code it operates on.

Skills are one of Osmani’s five loop primitives, alongside automations, isolated worktrees, connectors, and sub-agents, and his framing is the right one. A skill is intent written down on the outside, written once where the agent reads it every run. Without it, the loop re-derives your project from zero every cycle and fills the gaps with confident guesses. With it, the knowledge compounds.

The skill has one more property we value. It is reusable by both a human and the machine. An engineer can run it locally to do a resync by hand, and CI runs it headlessly. There is one source of truth for how we do this, and improving it improves both paths.

Guardrails

Handing an agent write access to your repo raises the stakes on guardrails. Ours are layered:

• PR-only. The output is always a pull request. It cannot touch main.
• Diff-gated work. If the incoming spec is byte-identical to what is committed, the loop does nothing. Most upstream pushes change implementation, not contract, so most of the time there is nothing to do.
• Judgment-gated cost. The reasoning step runs only when the diff shows new endpoints. A schema tweak flows through the mechanical path alone. Loops can get expensive quickly, and cost is the first thing every practitioner writing about this flags.
• Least privilege. Scoped tokens, and a tool allow-list limited to the task.

The layering matters because an autonomous edit loop will find whatever gap you leave open. The protection has to live in more than one place, in config, in the skill, and in CI, so that a mistake that slips past one check is caught by another.

A second loop, for unreleased APIs

Once the merge-to-main loop worked, an obvious request followed. A backend engineer working on a feature branch wanted to drive their unreleased API through the MCP server before anything merged.

So we built a second loop on top of the first. An engineer labels their API pull request Preview MCP, and from then on the MCP repo maintains a tracking branch and a live preview deployment that follow their feature branch. The preview’s client is regenerated from the branch’s spec and pointed at the branch’s own preview backend. Client and backend move together, so the new API can be driven through real MCP tools end to end before merge.

By Ronacher’s test this is the safest place for a loop, because a preview is a throwaway artifact with no long shelf life. The economics are gated hard, since a developer pushes often and most pushes do not touch the contract:

Change on the branch	What runs
Implementation only (spec unchanged)	nothing, the preview keeps working
Schema or field change on existing endpoints	mechanical regeneration only
New endpoints added	mechanical regeneration and the judgment step, so the preview exposes the new tools

The model fires only when there are genuinely new endpoints to turn into tools. Everything else is free or nearly so, and the same pull request gate applies.

Staying the engineer

The loop-engineering discussion carries a worry underneath it. Ronacher puts it plainly: in a fully harness-driven loop, “I’m not sure what my role even is,” reduced to a messenger. Osmani names the failure mode cognitive surrender, where designing the loop “is the cure when you do it with judgement and the accelerant when you do it to avoid thinking.”

Our answer is the human gate. The loop removes the toil, so nobody runs the checklist anymore, but it keeps a person at the decision, reviewing a real diff and approving a real change. The engineer moves from running the procedure to approving its result, which is a role, not a rubber stamp. Osmani’s summary is the one we keep: build the loop, and stay the engineer.

A few things made the loop work in practice, and none of them are specific to MCP servers:

1. Separate the mechanical from the judgment. Script everything deterministic, and reserve the model for the step that needs a mind.
2. Pick loop-friendly problems. Verifiable transforms and throwaway artifacts are where loops are safe today. Shipping lasting, load-bearing code unsupervised is a different risk.
3. Write the procedure down as a skill. One artifact that a human and CI can both run, and that improves with every lesson.
4. Gate the expensive step and the cost. Diff before you work, and reason only when there is judgment to apply.
5. Layer the guardrails. The loop will find the gap you leave open, so protect it in config, in the procedure, and in CI.
6. Keep a human at the gate. A pull request is a good place to do it.

Zoom out and it is loops inside loops. Claude Code runs its agent loop. Our CI wraps that in a harness loop that keeps the tools in sync. Both sit inside the product loop we are building toward, an agents-first platform where the agents that use the tools are the ones that reshape them. The sync loop is what lets that outer loop close safely, so an improvement an agent asks for reaches the next agent, with a human signing off along the way.

Cherny’s observation was not that the work got easier. It is that the leverage point moved, from the prompt to the loop. Move it deliberately, keep a hand on the gate, and a moving API and its MCP server can stay honest to each other with very little standing in between.

---

Rapidflare builds domain-specific AI agents for technical sales and support in electronics and semiconductors. If building reliable agent infrastructure is your kind of problem, we’d love to talk.

Further reading

• Addy Osmani, Loop Engineering — the five building blocks, and “build the loop, stay the engineer.”
• Armin Ronacher, The Coming Loop — the agent loop versus the harness loop, and where loops are safe.