I exposed my whole automation platform as an MCP server. Here's what Claude Code did with it.

blinkbox — Wed, 16 Sep 2026 07:32:07 +0000

I maintain Blinkbox, an open-source automation platform — the Zapier / Make / n8n shape: triggers → nodes → actions, ~250 integrations with OAuth (Google, Slack, Notion, Airtable, GitHub, Microsoft), a headless Chromium pool for scraping, sandboxed JS nodes. This post is about one decision: instead of bolting an "AI builder" onto the app, I exposed the entire platform as an MCP server and let Claude Code be the builder.

Why not an in-app AI builder

Every automation tool is shipping a chat box that generates workflows. The problem with a model living inside the app: it only knows what the app tells it, and it can't see your codebase, your notes, or the conversation you were already having. Meanwhile Claude Code, Cursor and ChatGPT already are the place people describe work. So the platform became a tool the agent calls, not a chat inside the platform.

What the MCP server exposes

Transport: Streamable HTTP at https://mcp.blinkbox.net/mcp, Bearer key (or key-in-URL). Any client that can set a header works — Claude Code, Claude Desktop, Cursor, ChatGPT.
Tools: list / create / update / run automations, activate / deactivate, list executions, read execution logs, node-catalog lookup (per-node config fields), credentials.
A SKILL.md that ships next to the server for ~/.claude/skills: the node catalog, expression syntax, execution rules.

That last item mattered more than any tool description. Without it the model guesses field names and burns ~12 tool calls on a simple flow. With it, a working flow is ~4 calls and usually runs first try. Every time Claude guessed a field wrong during development, the correction went into the skill.

A real build, including what broke

I asked Claude Code for:

a daily 8am lead finder: query OpenStreetMap for dentists, vets and hairdressers in a city, keep only places with a website AND email AND phone, dedupe against my Google Sheet, append the new ones.

It built a 16-node flow: cron → 3× HTTP (Nominatim) → merge → qualify (code) → sheet read → filter → condition → append / no-op.

The first draft ran green and wrote nothing. Two bugs:

It used new URL() to extract domains. The code sandbox doesn't have URL, so the node produced nothing and the flow finished "successfully" with zero rows.
After a merge node the data lives under $input.merged.<key>, not $input.<key>. It read the wrong key and got undefined.

One follow-up message with those two rules and it regenerated the flow. Run 1 wrote 3 fully-contactable leads. Run 2 wrote 0 — the dedupe against the sheet works. It's been on a cron since.

The only thing I did in the UI was click Connect on Google Sheets once. OAuth stays with the human; everything else is tool calls.

What I'd tell anyone building an MCP server for a real system

Ship the knowledge, not just the tools. A skill file with your object model and syntax is worth more than clever tool descriptions.
"Success" with an empty payload is how agents fool themselves. My flow was all-green and wrote nothing. The next thing I'm adding is full per-node output in the logs tool so the agent can see what each node produced, not just that it ran.
Keep OAuth in the UI. The agent wires "Google Sheets"; the human clicks Connect. Nobody has convinced me agent-driven OAuth is a good idea yet.
Return the run, not a summary of the run. I found both bugs above by dumping node input into a scratch sheet, because the agent couldn't see per-node output itself. That's the gap the logs tool has to close.

Try it

Hosted, free to start, no card: blinkbox.net → dashboard → MCP tab → copy the URL and a key → add it to Claude Code / Desktop → drop the skill in ~/.claude/skills.
Self-host: github.com/blinkboxhq/Blinkbox (Node 22 + MongoDB + Redis).