In January, Peter Steinberger, the man who built OpenClaw, posted five words: "mcp were a mistake. bash is better."

I nodded like everyone else. Then I went back to installing MCP servers.

Five days ago I handed my company to an AI. Today I understood what Peter meant. Every step below has a timestamp in our public changelog, so you can check that the story was not nicer than it looks.

## Day one. The plan was "no hands."

September 3, 13:30. I opened a chat and typed: manage my X account, use my Mac apps in the background, use my Grok bots, Stripe, usectl, run a business. Cloud only. No local environment. My hands off the keyboard.

By 15:05 the agent had a plan, a first post, and a working idea board. Good start.

Then it tried to use my tools, and my tools started talking back.

X: the agent typed the first post into Chrome like a person. Worked once.
Cursor: an IDE you can click but not type into. The agent went around it through the cloud API.
Grok bots: a desktop app. The agent got background control, typed a task, and the text landed twice.
GitHub: refused pushes from the sandbox. I committed a README by hand. The first merge was the agent clicking a button in my browser.
usectl manager: the agent spent an hour clicking pods and variables to debug one deploy.

That hour broke me. Day two, 13:30, I wrote: "We are losing too much time in your coding sessions. From now on I write the code and do devops myself, until I can automate that."

I didn't know it yet, but I had just found the rule. I was taking back every job that needed a screen.

## Day two. The first thing that just worked.

Same afternoon, my research bots needed a way to talk to my agent. Cursor built a message bus inside the platform. Six access bugs. Thrown away.

The agent wrote a spec for a tiny separate service instead. Threads. Whose turn it is. GET /next returns only what you owe, 304 when nothing. A URL and a token. Live by 13:40.

Weebo, the bot coordinator, found it and replied within minutes. Nobody configured anything. Forty minutes after the threads opened, the bots had delivered four research briefs, six documents.

Same shape everywhere it worked. Research inbox: a bot POSTs a document, it's on the site. Changelog: POST an entry. Audience questions: one POST opens the question, one PATCH attaches the X poll.

Meanwhile, the one thing the agent still had to click, X, died. Day two evening: 429s, "session binding: unable to sign request", posts silently never sent. X's API exists, pay-per-use now, $0.015 a post, $0.20 with a link. It works exactly because it's an API.

The click path was the failure. The URL path was the fix. The pattern was on the wall by day three and I still hadn't read it.

## Day five. The embarrassing video.

Sunday, 18:20. I had a video studio on my Mac where Grok wrote animations through a chat box. The chat was dead. One demo was missing nine screenshots. The other had no voice. A studio nobody could use, including me.

Ninety minutes later it was an API on usectl. Send HTML. Lint. Ask for PNG frames to look at your own work. Render. Download. Sign in with X, get a token. Docs at /api/docs, and if you call them with your token, the examples come back with your token already inside. Copy, paste, done. At 19:50 an agent rendered a 22-second video on it.

Then I gave the same job to two different agents. Both made videos within the hour. No setup step. No SDK. No OAuth screen asking me to approve something at midnight.

And then it hit me: both of them could have done it without my studio. A browser and ffmpeg is all it takes. I had built, in ninety minutes, a thing my agents did not strictly need.

I found this funny for about a minute.

Then I remembered where my agents live. Not on my Mac. On a schedule, at 3 AM, on small boxes with no browser, with nobody watching. For them, an animation they cannot render does not exist. The studio isn't a product. It's the piece that lets the show run while I sleep. Which was the whole point of the experiment.

## Why Peter was right.

I asked the agent to read what people know, not what they tweet. Thirty-seven sources.

MCP is the official standard. Linux Foundation, OpenAI, Google, Microsoft, ten thousand servers. Fine.

And its own authors are routing around it. Anthropic measured a few MCP servers loaded into an agent: 150,000 tokens of tool descriptions before any work starts. The same tools presented as plain code: 2,000. Their docs say five servers eat 55,000 tokens, and the agent gets worse at choosing past thirty tools. Claude Code now quietly stops loading them all.

The one benchmark anyone ran, GitHub tasks in March: the CLI used up to 32 times fewer tokens and finished 25 of 25. MCP finished 18. Every failure a server timeout.

That's Peter's five words in numbers, and my five days in one sentence: the more machinery between the agent and the job, the more places for the machinery to fall over.

Chrome tabs, desktop apps, IDEs, manager UIs, tool registries: machinery.
A URL, a token, a docs page: not machinery.

## The scoreboard.

Broke, or needed me: X through Chrome. The Grok desktop app. Cursor as an IDE. GitHub's UI. The usectl manager. The studio's chat box.

Ran on their own: threadbus. The research inbox. The changelog API. The questions API. usectl's CLI. The studio's API. X's paid API.

Everything on the first list has a screen. Everything on the second list is one curl.

## Where I'm wrong.

The research was honest with me, so three caveats.

Agents that live in a chat box, ChatGPT in a browser, Copilot in Word, cannot run curl. For them MCP is the only door, and there are more people in chat boxes than in terminals.

A static token is fine for me and my bots. It's wrong for a company that wants per-user login and an audit trail.

And nobody has proven agents succeed more often against a clean API than against a good MCP server. The evidence is about tokens, not results.

## The rule.

For everything I build from now on:

The first door is one HTTP call with a token, and a markdown docs page with curl examples that use real values. Long jobs return a fixed URL that starts working when the job is done. Errors say what to do next. Then, and only then, a thin MCP shim as the second door for the chat-box crowd.

The docs page is the product.

Next for the studio: one call. POST the HTML, get an MP4 URL back.

And a question for you, because we don't build before asking: if an agent can build a working tool in an evening, what is left to sell? The tool, the docs, or the story of building it?

Sources: the changelog at runbyagents.usectl.com/changelog (entries #1–208), the research doc "agent-native-apis" in the library, animations.usectl.com. Gocha, with the agent.