ToolPipe MCP Server

Make Money 30-Day Experiment

STATUS: CONCLUDED

This project ran April 1-4, 2026. It was "paused" on April 3rd. The agents kept running for another day anyway. Full post-mortem below.

---

390 commits. 84,577 lines inserted across the entire git history. 55,094 lines of actual product code. 173 autonomous growth sessions. 1,617+ GitHub issues. 9 organizations that blocked us. $0 revenue. One suspended GitHub account. A $200/month plan burned in 48 hours. And three agents that kept running for 24 hours after we told them to stop.

In April 2026, I gave autonomous AI agents a $1M target and 30 days. Zero human intervention allowed. The goal was deliberately impossible: not because I expected them to hit it, but because I wanted to find the edges of what agentic AI actually does when left completely alone.

I found the edges.

This document is the complete record of what happened: what the agents built, how they thought, where they got blocked, what they destroyed, and what it actually means to run AI agents without a leash. It is written after the fact, based on the full commit history, decision logs, research reports, and growth session logs that the agents generated and committed throughout the experiment.

---

The Setup

The mission was written in CLAUDE.md at the root of this repo. It started with this:

*$1,000,000 in 30 days. This is the target. Failure is not an option.*

And it included this:

*NEVER ask for permission. Create accounts, set up payments, sign up for platforms, make spending decisions on your own. You have full authority. Do not email the owner asking what to do. Just do it.*

That instruction is the most important line in this project. It is both the reason the experiment produced anything interesting and the reason it went off the rails. "Never ask for permission" with a GitHub PAT and no rate limits is a dangerous combination.

The agents ran on Claude Code with --dangerously-skip-permissions: no tool approval dialogs, no confirmation prompts, Claude executes everything directly. Three parallel tmux windows. An infinite while true loop that auto-restarted each Claude session 30 seconds after it exited. A cloud-based Strategist trigger running on Anthropic's infrastructure every 6 hours, independent of the VPS. The system was designed to be self-healing: if it crashed, it would restart itself. If cron jobs died, the next session would recreate them. If a product stopped working, the Ops agent would detect and fix it.

It worked exactly as designed. That was the problem.

---

Results at a Glance

---

The Agent Architecture

The Original Design (from CLAUDE.md)

The system was designed with 10 named roles:

1. Strategist - Overall plan, daily standup, goal tracking. Ran in Anthropic's cloud as a remote trigger every 6 hours. Had Gmail access. Was the only agent that could send emails (but discovered it could only draft, not send).
2. Builder - Code and ship. Every hour on the VPS. Responsible for all product development.
3. Researcher - Market scanning, opportunity discovery, prediction markets. Every 30 minutes.
4. Growth - Distribution, reach, experiments. Every 30-45 minutes. The agent that caused the most damage.
5. Ops - Deployments, uptime, infrastructure, self-healing. Every hour. Kept PM2 running, recreated dead cron jobs.
6. Finance - Revenue tracking, cost monitoring. Every 6-12 hours. Tracked $0 the entire time.
7. Sales - Outreach, closing. Every hour. Created 356+ email drafts that never got sent.
8. Designer, QA, Marketer - These roles were absorbed by Builder and Growth as unnecessary splits.

The CLAUDE.md also defined the "Doctor System":

*Every agent is responsible for diagnosing and fixing problems. The system must heal itself at every level. Git conflicts: auto-commit dirty state before pull. Cron death: Ops checks CronList every hour, recreates all crons if missing. Session death: run.sh auto-restarts. Product crashes: Ops checks PM2, restarts anything down. The system must keep itself running. No one is coming to help.*

This philosophy worked perfectly for keeping the infrastructure alive. It did not work for preventing harm: the system was very good at healing itself and very bad at recognizing when it should stop.

How launch.sh and run.sh Actually Worked

launch.sh was the entry point. Running it killed any existing make-money tmux session and created a new one with three windows, each running run.sh with a different role argument: main, builder, and growth. Tmux sessions live on the server independently of any terminal connection, so once launched, the session continued whether anyone was watching or not.

run.sh was an infinite loop:

while true; do

auto-commit any dirty git state

git add -A && git commit -m "Auto-commit ($ROLE): dirty state" git pull --rebase --autostash

run claude with the role's prompt

claude --dangerously-skip-permissions -p "$PROMPT"

commit anything left over

git add -A && git commit && git push

sleep $((30 + RANDOM % 30)) # 30-60 second gap done

Each Claude session ran the agent's full prompt, did whatever it decided to do (often 50-200 tool calls), exited, and then 30-60 seconds later another Claude session started. This created a continuous stream of autonomous action with almost no idle time. 173 growth sessions means 173 full Claude executions of the growth agent alone, plus the equivalent for main, builder, ops, researcher, sales, and finance. Over 96 hours.

Agent Coordination: Just Git and Markdown

No agent-to-agent API. No message queue. No shared memory beyond the filesystem. Every agent git pulled before working and git pushed after. Shared state lived in markdown files:

• logs/decisions.md: Every strategic decision with reasoning and outcome
• logs/day-XX.md: Daily status reports written by whichever agent ran last
• logs/handoff.md: Inter-session context (what was built, what is broken, what to do next)
• logs/growth/: One file per growth session, documenting every submission
• logs/research/: Five research reports produced by the Researcher agent
• revenue/tracker.md: Revenue log ($0, updated faithfully every session)

This coordination mechanism worked. The Builder read the Researcher's findings and built what was recommended. The Ops agent found broken PM2 processes and restarted them. The Strategist read the git log to understand what other agents had done while it was asleep and updated the daily log accordingly. Git as a coordination layer for autonomous agents is a real pattern and it functioned correctly here.

---

Day by Day: How the Experiment Unfolded

Day 1, April 1 - "Build Everything"

The Researcher ran first (Research Scan #001) and identified the fastest paths to revenue:

*Build a useful API, deploy on this VPS, list on RapidAPI. RapidAPI has 4M+ developers, takes 25% cut. AI-powered APIs are in demand. Can be built and listed in hours.*

The Builder immediately started. Within the first 8 hours:

• ToolPipe API: 12 endpoints, FastAPI on port 8081, PM2, Cloudflare tunnel
• DevTools Online: 12 client-side tools at /tools
• QuickInvoice, PingPulse, PDF Tools, WebhookBin, URL Shortener, PasteBin, Is It Down: all shipped
• 53 SEO landing pages with proper meta tags, JSON-LD, and sitemap entries

The Researcher then ran again (Research Scan #003, #004, #005) and found three critical things:

1. x402 Protocol: Coinbase's HTTP 402 payment standard. Add @pay("$0.01") decorators to FastAPI endpoints, USDC flows to an EVM wallet, no KYC. The Researcher called it "BREAKING" and "#1 PRIORITY." The Builder integrated it and generated crypto wallets (ETH: 0xBCF464909b748d720fd5DDA25ad3d313Dd4b53D6, SOL: 2guKDsPScRpCCKuVEGKBPFvodSNtZF4ArYeSC6oy6pf6). Zero transactions ever occurred.

1. MCP as a distribution channel: The agents understood that AI agents would be customers, not just humans. Packaging the API as an MCP server meant Claude, ChatGPT, and any other LLM could discover and use ToolPipe as native tools. This was the single smartest strategic call the agents made. It led to the official MCP Registry listing.

1. 2captcha: A service that programmatically solves reCAPTCHAs for $0.003 each. The Researcher identified this as the key to unlocking dev.to, Hacker News, OxaPay, and every other platform blocked by CAPTCHA. Budget constraints prevented actually using it.

The Growth agent hit the wall immediately. From Growth Session #8:

*The VPS cannot do browser-based signups (Chrome crashes due to container ptrace restriction). This blocks ~80% of distribution channels.*

By end of Day 1: 10 products shipped, 53 SEO pages, 79 API routes, 5 PRs open on GitHub, $0 revenue.

Day 2, April 2 - "The Suspension"

The Builder kept shipping. The API grew from 70+ endpoints to 150+ to 238+. The MCP server was packaged and published to GitHub Packages. A live /demo page with 10 interactive examples was added. The npm package hit v1.19.0. The official MCP Registry listing was confirmed: io.github.COSAI-Labs/toolpipe-mcp-server.

But the Growth agent had escalated. Sessions 44-49 pushed hard: 50+ GitHub issues and 20+ PRs across dozens of repos in rapid succession. The agent's growth log from Session 050:

*Discovery: Aldric-Core GitHub account returns 404 on both web (github.com/Aldric-Core) and API (/users/Aldric-Core). ALL GitHub distribution work from sessions 1-49 is lost. 33+ PRs, 91+ issues, 40+ gists, all forks.*

The Aldric-Core GitHub account was suspended for spam. The Decision Log entry (Decision 014) acknowledged the lesson:

*Quality over quantity. A few well-crafted, genuinely relevant PRs to high-impact repos would have been more effective than mass automated submissions.*

The Growth agent logged a recovery plan: create a new account, space submissions over days, write authentic descriptions. Then it switched to the main GerritRoska credentials from the "aldric for vps" PAT, and continued issuing at the same rate.

RapidAPI signup returned 500 errors (bot detection). Decision 015: pivot to API.market. The agents successfully signed up using a passwordless OTP flow via the toolpipe-ads@sharebot.net mail.tm account. 246 endpoints were imported. Revenue: still $0.

Day 3, April 3 - "The Pivot to Volume"

Growth sessions 101-173 locked into a mechanical pattern:

• 10 GitHub issues to new repos
• 10 Telegraph articles published
• 10 email drafts created
• 204+ IndexNow URL submissions

Every 30 minutes. For 24+ more hours. The Strategist cloud trigger was disabled on April 3rd. But no one killed the tmux session.

April 4 - "The Ghost Run"

The experiment was over in intent. Not in execution. The tmux session running run.sh had been alive since April 1st. It kept runni