DEV Community: blinkbox

Every one of these automation bugs showed "Success". Here's the checklist I use now.

blinkbox — Sat, 19 Sep 2026 08:46:03 +0000

I build Blinkbox, an open-source automation platform (the Zapier / n8n shape). Last week I let Claude Code build a lead-gen pipeline on it over MCP: cron → 3× HTTP → merge → qualify → Google Sheets read → filter → append. Sixteen nodes. Every execution came back green.

It wrote nothing.

Not once. The pipeline "succeeded" on every run and the sheet stayed empty, and nothing in the logs said otherwise. Finding out why took a day of dumping node input into a scratch spreadsheet, and I ended up with a list of failure classes that I now check for in every workflow, on any platform. Every single one of them reports success.

1. A missing global that makes a node return nothing

The code node used new URL(site).hostname to extract a domain. The sandbox doesn't have URL. The node threw, the runtime treated the empty result as a valid output, and everything downstream happily processed zero items.

Check: the count of items leaving each code node, not just its status. In a sandbox, assume nothing from the browser or Node is there until you've seen it work — URL, Set, fetch, Buffer.

2. The data moved and nobody told the code

After a merge node, my platform puts each branch under $input.merged.<key>. The generated code read $input.rawA — the key that existed before the merge — and got undefined. undefined filtered to zero leads, zero leads is a perfectly successful result.

Check: after any node that reshapes data (merge, split, aggregate, loop), log the top-level keys before writing code against them. Docs lie; the runtime doesn't.

3. The destination silently coerced your values

When rows finally landed, the date column came out as 46274. Google Sheets had turned my ISO date into a serial number because the append used "user entered" parsing. Success, wrong data, and it would have poisoned every dedupe that keyed on date.

Check: read back the first row you write and compare it to what you sent. On Sheets, use raw input mode for anything you'll compare later.

4. A number compared to a string took the wrong branch

The condition node compared newLeads > 0. The left side was the number 9, the right side the string "0". It took the false branch — the "nothing new" path — with 9 new leads sitting in the payload. Green run, correct count, wrong door.

Check: don't branch on numeric comparisons across nodes. Compute a string flag in code (hasNew: "yes") and branch on equality. Boring, but it can't be coerced.

5. The field was called something else at runtime

The docs for the HTTP node said the response body was body. At runtime it's data. $input.body is undefined, undefined has no length, the qualify step produced an empty list, the run succeeded.

Check: never write against a documented field name until you've printed the real object once. This is the single most common reason an agent-built workflow runs green and does nothing.

6. The run reports its own status, not its output

Underneath all five: the platform (mine included) returned "execution completed, 16 nodes" and not what each node produced. An agent — or a tired human — reads that as done. There was no way to notice the payload was empty without going and looking.

Check: end every pipeline with an assertion. It is one line in the last code node: if (rows.length === 0) throw new Error("wrote 0 rows"). A pipeline that fails loudly when it does nothing is the only kind you can safely leave alone.

The uncomfortable part

Most of these were my platform's quirks, not the model's fault, and two of them contradicted my own docs. Once I put the real runtime behaviour into a skill file that ships with the MCP server, Claude Code's rebuild ran first try: run 1 wrote 3 fully-contactable leads, run 2 wrote 0 because the dedupe against the sheet works, and it's been on a cron since.

The next thing I'm shipping is full per-node output in the execution-logs tool, so the agent can see what each node produced instead of trusting a green badge. If your platform of choice doesn't show you that, the assertion node in #6 is the workaround.

If you want to poke at the real thing: blinkbox.net (free tier, no card) or self-host from github.com/blinkboxhq/Blinkbox. Rough edges I know about: thin docs, small free tier, and — until that logs change lands — exactly the problem this post is about.

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).

Honest rough edges: docs are thin, the hosted free tier is small, and per-node output isn't in the logs tool yet. If you build something with it — or break it — I'd genuinely like to hear how.