Post: 5 Real Production Lessons From Running a Custom Make MCP Server for Months
We built and ran a custom Make MCP server before Make released their own. Not as an experiment — as a production tool we used on real client work, day after day, for months.
That experience informed everything in our broader field report on running Claude with Make in production — and it surfaced lessons no documentation could have given us. The documentation tells you how the tool works. Only months of real builds tell you how it actually behaves.
These are the five production lessons that changed how we operate.
Quick Answer
Running a custom Make MCP server in production for months taught us five things: seeding the MCP with existing scenarios is non-negotiable for build quality; complete scenarios without broken modules are now the norm, not the exception; description precision determines output quality more than anything else; the MCP infers missing context and asks before it guesses; and a self-diagnosing error handler built on top of the MCP cut our per-error research time from 20–30 minutes down to a glance at an email.
What Does “Running a Custom MCP Server” Actually Mean?
Before Make released their own MCP server, we built one ourselves. We connected it to Claude, seeded it with our existing scenario library, and started using it on live client builds. No sandbox. No test environment. Real automations for real clients.
We did this because we saw the productivity floor — the time Claude spent guessing at JSON structure, mis-formatting HTTP modules, building scenarios with broken connectors — and we wanted to solve it. A custom MCP gave Claude the context it needed to stop guessing and start building correctly the first time.
What followed was months of iteration: what worked, what broke, what we had to change, and what surprised us. Here are the five lessons that stuck.
Lesson 1: Seeding Is the Foundation — Skip It and You Pay Every Single Build
This was the first thing we learned and the most important. We had to seed our MCP with existing scenarios so it understood the JSON structure from Make. Once seeded, it includes all credentialing and related details automatically — no manual fill-in required on every build.
Before seeding, Claude was inferring JSON structure from general knowledge. That sounds fine until you realize Make’s JSON schema has specific quirks — module IDs, connection references, metadata blocks — that general knowledge gets wrong. The result was scenarios that looked complete but had broken references buried in the middle. You would not find them until you imported and ran the scenario.
After seeding, those errors stopped. Claude was no longer inferring from the outside. It had real examples to pattern-match against. The difference in first-run import quality was immediate and significant.
- Seed with a range of scenario types — simple, multi-step, and HTTP-heavy
- Include at least one scenario per connection type you use regularly
- Reseed when you add new connection types or significantly change your standard build patterns
- Treat seeding as infrastructure, not setup — it is not a one-time task
If you want to see exactly how we approached the seeding process and what the build quality difference looked like, we documented it in detail: seeding an MCP with existing scenarios for build quality.
Lesson 2: HTTP Module Quality Is Where the MCP Earns Its Keep
The biggest day-to-day benefit — the one that showed up on almost every build — was complete scenarios without broken modules. Particularly strong on HTTP posts: it formats the JSON script and module internals correctly the first time.
HTTP modules are where manual builds fall apart. You are constructing the request body, headers, authentication, and response parsing by hand. Miss a bracket, reference a field incorrectly, or format the content-type wrong and the module fails silently until you run it. With a properly seeded MCP, Claude handles all of that correctly from the prompt.
We build a lot of integrations with tools that do not have native Make modules. Every one of those requires HTTP. The MCP turned what used to be the most error-prone part of a build into the most reliable part.
- Native module builds improved — but HTTP module builds improved most dramatically
- First-run import success rate on HTTP-heavy scenarios went from roughly 60% to well above 90%
- Time spent on post-build debugging dropped sharply on API-integration projects
This connects directly to another lesson below on API docs — the two compound when you use them together.
Does Description Precision Actually Change the Output?
Yes — more than almost any other variable. You have to be really good at describing exactly what you want. The MCP builds exactly what you describe. Vague input produces vague scenarios. Specific input produces specific scenarios.
This took us time to internalize. We assumed that a well-seeded, context-rich MCP would compensate for loose prompts. It does not. The MCP is a precision instrument. It rewards precision in return. When we wrote detailed, structured prompts — specifying trigger conditions, data mappings, error paths, and output format — we got complete, correct scenarios. When we wrote loose prompts, we got plausible-looking scenarios that missed half the logic.
We eventually built internal prompt templates for common scenario types. That standardization cut our average prompt-to-correct-build time in half. If you are using an MCP and the output quality is inconsistent, look at your prompts before you look at the tool.
- Specify the trigger, the data path, and the output in every prompt — no exceptions
- Name the modules you expect to see if you have a preferred build pattern
- Describe error handling explicitly — do not assume it will be inferred
- Build prompt templates for your most common scenario types and reuse them
For a deeper look at where AI-built scenarios commonly fall short — and how to catch it before it costs you — see seven things an AI-built Make scenario gets wrong.
What Happens When the MCP Hits a Gap in Its Context?
It asks. That was the answer, and it was not what we expected.
The MCP is good at inferring missing context — but when it hits something the operator would not be familiar with, it pushes back with clarifying questions. It does not silently guess. It asks first.
Early on, we expected the MCP to fill in gaps from its training. Sometimes it would. But on anything involving unfamiliar APIs, unusual data structures, or edge-case logic, it would stop and ask a targeted question rather than proceed on a bad assumption. That behavior saved us from a lot of quietly broken scenarios.
The lesson here is to treat those questions as signal, not friction. When the MCP asks, it is telling you that the context was incomplete. Answer specifically and the next output will reflect it. Dismiss the question or answer vaguely and you get the silent guess you were hoping to avoid.
- Clarifying questions from the MCP mean your prompt had a real gap — fill it
- The more precise your answer, the better the subsequent output
- Build a habit of pre-answering likely questions in your initial prompt
Can You Use the MCP to Handle Its Own Errors?
Yes — and it is one of the most practically valuable things we built. We built our MCP to act as an error handler for our own production scenarios. When a scenario errors, the MCP reads the scenario, identifies what is broken, and sends technicians an email with an analysis and a suggested fix. Research time per error went from 20–30 minutes down to a glance at an email.
This was not in the original plan. It emerged from a frustration: error diagnosis in Make is manual by default. You open the execution log, find the failed module, trace the data path, identify the break, and figure out a fix. That process reliably took 20–30 minutes per incident even for experienced operators. Multiply that by a production environment running dozens of active scenarios and the maintenance load becomes real.
We built a scenario that feeds error data back to the MCP, which analyzes it against the scenario structure and generates a plain-language diagnosis with a recommended fix. The human still makes the call — human-in-the-loop is intentional — but the research work is eliminated. The technician reads the email, confirms the diagnosis, and applies the fix. That is it.
- The MCP reads the error, the scenario structure, and the execution context together
- Output is a plain-language diagnosis plus a specific suggested fix — not generic advice
- Human-in-the-loop is preserved: the MCP recommends, the technician decides
- Per-error research time dropped from 20–30 minutes to the time it takes to read an email
- Scales cleanly across a large scenario library — the more scenarios you run, the more value it returns
This is the build that made the strongest case internally for why we started running a custom MCP server in the first place. You can read more about our reasoning and the original build decision in why I built a Make MCP server before Make did.
What These Five Lessons Have in Common
None of them came from the documentation. They came from building real things for real clients and paying attention to where the process broke down.
Seeding gave Claude the structural foundation to build correctly. HTTP module quality removed the most error-prone step in API integrations. Description precision turned out to be the operator variable — not the tool variable. Clarifying questions flagged real gaps before they became broken scenarios. And the self-diagnosing error handler turned a 30-minute manual process into a two-minute email review.
Each lesson made the next build faster and the production environment more stable. That compounding effect is the actual value of running a custom MCP in production — not any single feature, but what the whole system learns to do over time.
If you are considering building your own or evaluating whether the investment is worth it, start with our full Make and Claude production field report. That is where the complete picture lives.
Information in this article is deemed to be accurate at time of publishing. 4Spot Consulting reviews and updates content periodically as best practices evolve.
Frequently Asked Questions
What is a custom Make MCP server?
A custom Make MCP server is a Model Context Protocol server you build and host yourself, connected to Claude, that gives the AI direct context about your Make environment — scenario structures, JSON patterns, connection credentials, and build conventions. It allows Claude to generate complete, correctly formatted Make scenarios rather than inferring structure from general knowledge.
Why does seeding a Make MCP matter so much?
Make uses specific JSON schema conventions — module IDs, connection references, metadata blocks — that Claude cannot reliably infer from general training data. Seeding the MCP with real existing scenarios gives Claude accurate structural patterns to match against. Without it, imported scenarios frequently contain broken references you only find when you run them. With it, first-run import quality improves dramatically.
How much does description precision actually affect MCP output?
More than almost anything else. The MCP builds exactly what you describe. Vague prompts produce plausible-looking scenarios that miss key logic. Specific prompts — trigger, data path, error handling, output format all spelled out — produce complete, correct builds. Prompt templates for common scenario types are worth building early.
What does the self-diagnosing error handler do?
When a production scenario errors, it feeds the error data and scenario structure back to the MCP. The MCP reads both, identifies what broke, and emails technicians a plain-language diagnosis with a suggested fix. Human-in-the-loop is preserved — the technician confirms and applies the fix — but the research work is eliminated. Per-error time dropped from 20–30 minutes to a glance at an email.
Does the Make MCP handle tools with no native Make module?
Yes — this is one of its strongest use cases. Hand it the API documentation for a tool with no native Make module and it formulates correct API calls inside generic HTTP modules, including request body, headers, authentication, and response parsing. It collapses the problem of missing native integrations for most standard REST APIs.
Is a custom MCP worth building if Make now offers their own?
It depends on how much customization your production environment requires. Make’s official MCP covers standard use cases well. A custom MCP lets you seed with your own scenario library, bake in your credential patterns, and build tools like the self-diagnosing error handler on top of it. If you run a high-volume automation practice, the custom layer pays for itself quickly.
Sources & Further Reading
RELATED POST
