When an automation scenario breaks in production, the clock starts running. Someone has to find the error, open the scenario, trace the failure point, read the logs, and figure out what went wrong — before they can fix anything. At 4Spot Consulting, that process was eating 20 to 30 minutes per incident. Multiply that across a production environment with dozens of active scenarios, and it adds up fast.

This post is a detailed account of how we solved that problem using a custom Make MCP server. It’s one of the most concrete wins from our ongoing field work building with Claude and Make — and it’s replicable if you’re running Make at any real scale.

What Was the Problem?

Automation scenarios break. That’s not a flaw — it’s a reality of production environments. APIs change, upstream data shifts, rate limits fire, field mappings go stale. The scenario stops. Make logs the error. And then someone has to figure out what happened.

Before this build, that process looked like this:

• Technician gets notified (or notices) that a scenario has errored
• Technician opens Make, finds the scenario, opens the error log
• Reads the execution history to identify which module failed
• Cross-references the scenario design to understand what that module was supposed to do
• Researches the specific error — API timeout? Bad payload? Missing field?
• Formulates a fix hypothesis before touching anything

Best case, a clean and obvious error: 15 minutes. Ambiguous errors — the kind where the failure is two modules upstream from where Make flags it — ran 30 minutes or more. That’s before any repair work starts.

We were running that cycle repeatedly. It was the single biggest labor sink in our production support workflow.

What Did We Build?

We configured our Make MCP server — the same server we use to build new scenarios — to function as an active error handler for our own production environment.

Here’s the core design:

1. When a Make scenario errors, it triggers a dedicated error-handling scenario instead of simply stopping.
2. That error-handling scenario calls the MCP server and passes it the broken scenario’s details — structure, module config, execution log, and the error message.
3. The MCP reads the scenario in full. It identifies which module failed, what the failure mode is, and what the likely cause is based on the error data and the scenario’s logic.
4. The MCP generates a plain-language diagnosis — what broke, why it broke, and a suggested fix.
5. That diagnosis gets packaged into an email and sent to the on-call technician.

The technician opens their email. They read the diagnosis. They decide whether the suggested fix is right. They make the repair.

We didn’t remove the human from the loop. We removed the research from the loop.

How Does It Actually Work?

The MCP server isn’t doing anything magic here. It’s doing what Claude does well: reading structured information and reasoning about it.

A Make scenario — especially one we built using the MCP in the first place — is a JSON structure. The module types are identifiable. The connections between modules are explicit. The error log tells you exactly which module fired last and what the error payload looked like. That’s a well-defined reasoning problem.

When the MCP receives a broken scenario, it has everything it needs to work with:

• The full scenario JSON — what the scenario was built to do, module by module
• The execution log — what actually ran and where it stopped
• The error payload — the raw error message from the failing module

From those three inputs, the MCP produces a diagnosis that typically includes: the specific module that failed, the error type, a plain-language explanation of why that error fires, and a recommended fix. When the error is one it hasn’t seen before, it flags that and notes what additional information the technician should look for.

It doesn’t guess silently. If context is missing, it says so. That keeps the technician in control — they’re reading a confident analysis, not a hallucinated diagnosis.

For the technical walkthrough of how this is structured inside Make and the MCP, see our step-by-step build guide for this error handler.

What Were the Results?

The reduction in research time was the headline result. But the secondary effect matters just as much: technician attention is now applied only where human judgment is actually needed. Reading logs and cross-referencing module configs isn’t judgment. It’s lookup work. The MCP does lookup work faster and doesn’t get it wrong the way a tired technician at the end of a long day does.

This ties into a broader pattern we’ve documented: AI doesn’t replace the operator’s judgment — it clears the path to it. You can see this same principle at work in how we approach routed error handling across production scenarios.

What Made This Build Work?

A few things made this build land cleanly instead of producing garbage output.

We seeded the MCP with our actual scenario library first. Before building the error handler, we had already loaded the MCP with existing scenarios so it understood our JSON structures, our naming conventions, and our module patterns. When it read a broken scenario, it wasn’t encountering our format for the first time. Context was already there.

We were specific about what we wanted in the diagnosis email. Vague instructions produce vague output. We defined the exact format: module name, error type, plain-language explanation, recommended fix, confidence level, and what additional context to flag when uncertain. The MCP builds exactly what you describe. Describe it precisely.

We didn’t ask it to repair autonomously. That was intentional. The repair step requires knowing the business context — whether a field rename was intentional, whether an API change is permanent or temporary, whether a fix should restore previous behavior or update it. That judgment lives with the technician. We designed the tool to inform that decision, not bypass it.

For a full summary of the production lessons we pulled from months of running this setup, see five production lessons from running a custom Make MCP server.

Can You Replicate This?

Yes — with a few prerequisites.

You need a Make MCP server already configured and seeded with your scenario structures. You need error-handling scenarios built at the scenario level in Make (not just relying on Make’s default error notification). And you need to spend real time on the diagnosis prompt — the quality of the email output depends entirely on how precisely you’ve defined what you want the MCP to produce.

If you’re already running Make at production scale and you’re losing 20 to 30 minutes every time something breaks, this build pays for the setup time inside the first week. That’s not a projection. That’s arithmetic.

The broader Make and Claude methodology behind this — including how we seed the MCP, how we handle HTTP modules, and how we structure AI-assisted builds — is detailed in our full field report on what daily use actually taught us.

Information in this article is deemed to be accurate at time of publishing. 4Spot Consulting reviews and updates content periodically as best practices evolve.

Keep Automating,
Jeff Arnold
Founder & CEO, 4Spot Consulting — Make Gold Partner

Sources & Further Reading

• How to Handle Errors — Make Help Center
• Overview of Error Handling — Make Help Center
• Scenarios Documentation — Make Help Center
• Introduction to Model Context Protocol — MCP Docs
• MCP Connector — Anthropic Docs