Using the Gauntlet Loop to build a full MCP server
I used the Gauntlet Loop to build an entire MCP server, almost completely hands-off.
The Gauntlet Loop is a reusable skill for Claude Code. You give it a goal and a bar to hit, and it splits the work into small pieces, runs a builder agent and a separate critic agent on each one, and keeps looping until the output wins the comparison against the bar.
The loop is only half of it, though. Three things happened before I started it, and they are what gave the critic something worth measuring against. Here's the exact process I followed to build a full MCP server.
1. Define the server
First, Claude Code wrote the complete MCP server definition: behavior, tools and limitations.
Do a research, only research, on how an MCP would look like for LyricEdits so people can use their external agent.
2. Two fresh agents critique it
Then I handed that definition to two fresh agents and had them critique the proposed solution until they reached consensus.
Fan out two agents that will discuss this MCP implementation proposal: __link_to_github_issue__ Each agent must do independent research of pros and cons of the proposal, compare against best practices, and then compare against each other until they reach a consensus. Don't stop until the consensus is reached.
Note: I use a loop in Claude Code to orchestrate all work on GitHub issues.
3. An artifact of the conversations
Last, I had Claude Code create an artifact showing what actual conversations with an agent using the MCP should look like.
That step turned out to be the important one. The artifact became the behavioral reference. Not just "Does the MCP work?", but "What should the experience of using the MCP actually feel like?"
make an artifact to explain visually how the MCP proposed here would work __link_to_github_issue__ Don't assume any knowledge from the reader, be explicit and descriptive
The artifact looks like this, covering different scenarios:
4. Start the loop
The MCP definition became the implementation guide. The conversation artifact became the bar the reviewer agent evaluated the implementation against. And I added one more constraint: turn those example conversations into end-to-end tests.
So as the implementation evolved through the loop, it kept checking that the MCP's actual behavior wasn't drifting away from the intended experience.
/gauntlet-loop implement the MCP __link_to_github_issue__ Use this artifact as bar __link_to_claude__artifact__ We need e2e tests for the MCP, to make sure it doesn't break with new features
Aftermath
The result: a complete, working MCP server, built almost entirely hands-off.
It took a long time. And many, many tokens. This definitely wasn't a generate-for-ten-minutes-and-come-back workflow. I enabled remote control, walked away, and occasionally checked the run from my phone.
What I find most interesting is this:
The artifact wasn't documentation created after the software. It became the bar the software had to continuously prove itself against.
The agent didn't just implement a spec. It built, criticized, tested, compared and iterated until the implementation matched the intended experience.
That feels like a much more interesting model for agentic software development.
If you want to try it
The Gauntlet Loop was created by Matt Shumer, made a reusable skill for Claude Code by Jay E. Take a look: