Post: How 4Spot Used Its Own MCP Server to Deliver a Client Migration in Half the Expected Time
We do not talk about our own delivery workflow very often. But this one is worth documenting.
Earlier this year we ran a client migration — moving a set of legacy automation scenarios into a fresh Make environment — using the Make MCP server we had built for internal use. What we expected to take roughly two weeks came in just under one. If you want the full story on how we built and deployed that server, the field report on running Make with AI assistance covers the broader context. This post focuses on one engagement, one timeline, and what actually happened.
Below is a straight account of the workflow, the before-and-after, and the three lessons that held up under real delivery pressure.
Project type: Automation environment migration (Make)
Delivery timeline (expected): ~10 business days
Delivery timeline (actual): ~5 business days
Broken modules on handoff: 0
Primary driver of time savings: Complete scenario generation via MCP — no manual module repair
Human hours eliminated: Estimated 8–12 hours of QA and module-rebuild time
What Was the Project?
The client had a set of working Make scenarios that needed to be rebuilt in a new environment — different credentials, updated data structures, some revised logic. It was not a greenfield build. It was a migration with a handful of deliberate changes layered on top.
That is actually the harder case. Greenfield builds let you start clean. Migrations mean you are reading someone else’s work, translating intent, and then rebuilding — while also making changes. The surface area for error is larger, and the QA cycle is longer because you are comparing old behavior to new behavior at every step.
We estimated ten business days. That included discovery, build, QA, and handoff documentation.
What Did the Workflow Look Like Before MCP?
On a migration like this, our old workflow went roughly like this:
- Review existing scenarios module by module
- Document the logic in plain language
- Rebuild in the new environment — manually configuring each module, mapping each field
- Test runs to catch broken modules (there were always broken modules)
- Repair cycle — identify which module broke, why, fix it, re-run
- Second QA pass once everything ran clean
- Handoff documentation
The repair cycle was the time sink. A broken HTTP module with a malformed JSON body could take 20 to 30 minutes to diagnose and fix. Multiply that across a multi-scenario migration and you are losing half a day to repair work before you ever start QA.
How Did the MCP Server Change the Approach?
We had seeded our MCP with existing 4Spot scenarios before this engagement. That seeding step is not optional — it is the foundation. The MCP needed to understand our JSON structure, our credentialing patterns, and our module conventions before it could build anything worth using. Once that groundwork was in place, the server carried that context into every new build automatically. No re-explaining structure on each request.
For this migration, the workflow shifted:
- Review existing scenarios and document intent (same as before)
- Write precise build descriptions for each scenario
- Submit to MCP — receive complete scenario JSON
- Import, run, verify behavior
- Handoff documentation
The repair cycle disappeared. Not because the MCP is perfect — because the scenarios it produced were complete. Every module was populated. Every HTTP post had a correctly formatted JSON body. Field mappings were present and accurate to the description we provided.
That is the core of the time savings. We did not spend hours in repair. We spent that time on verification instead — which is the work that actually protects the client.
For a deeper look at how seeding affects build quality, this breakdown on seeding and MCP output quality goes further into the mechanics.
What Did We Still Have to Do Ourselves?
This is the part that gets glossed over in most AI-assisted delivery stories. The MCP does not replace judgment. It replaces repetitive construction work.
Here is what remained entirely human:
Description writing. The MCP builds exactly what you describe. If your description is vague, the output is vague. If your description has a logic gap, the scenario has a logic gap. Writing tight, complete build descriptions took real time and real expertise. You have to know what you are building before you can describe it well.
Logic review. The client’s original scenarios had some embedded decisions that were not obvious from the surface — conditional routing that depended on field values that were not documented anywhere. We had to trace that logic manually before we could describe it to the MCP accurately.
Verification runs. Every scenario still ran through a full test cycle. We verified output data, checked routing decisions, confirmed webhook payloads. The MCP reduced what we were looking for (no broken modules to hunt), but the verification work itself did not shrink.
Judgment calls on changed logic. Where the client wanted updated logic — not just a straight migration — we made those decisions ourselves and then described the new behavior to the MCP. The AI did not make those calls. We did.
The five production lessons from running our MCP in production cover this division of labor in more detail, including the inference and clarifying-question behavior that helped us catch ambiguities early.
Before and After: Timeline Comparison
| Phase | Without MCP (estimated) | With MCP (actual) |
|---|---|---|
| Discovery and logic documentation | 1.5 days | 1.5 days |
| Description writing (MCP-specific step) | N/A | 0.5 days |
| Scenario build / manual module config | 3 days | 0.5 days |
| Repair cycle (broken modules) | 2 days | 0 days |
| QA and verification | 2 days | 2 days |
| Handoff documentation | 1.5 days | 0.5 days |
| Total | ~10 days | ~5 days |
The build phase collapsed from three days to half a day. The repair cycle went to zero. Documentation was faster because the MCP-assisted build produced cleaner, more consistent scenario structures that were easier to write up.
What Were the Three Lessons That Held Up?
1. Seeding is not a setup step — it is an ongoing investment. The reason the MCP produced complete, correctly structured scenarios on this engagement is that we had put time into seeding it with real 4Spot scenarios before we ever used it on client work. That investment paid dividends here. If you try to use an unseeded MCP on production work, you will spend as much time correcting structure as you save on build speed.
2. Description precision is the new technical skill. In a manual build workflow, the technical skill is module configuration — knowing which fields to populate, how to format a JSON body, how to set up a webhook correctly. With the MCP, that construction work is handled. The technical skill shifts to description writing: can you articulate exactly what the scenario needs to do, in enough detail that the MCP builds it correctly the first time? That is a real skill. It is learnable, but it takes practice.
3. Verification stays human — and that is right. We did not use the MCP to verify its own output. Every scenario was tested by a human who understood the client’s intended behavior. The MCP compressed construction time. It did not replace the judgment required to confirm that what was built actually serves the client. Those are different things, and conflating them is where AI-assisted delivery goes wrong.
If you want to understand the mechanics of building Make scenarios with AI assistance from the ground up, this guide on building Make scenarios with Claude is a good starting point before you approach a migration at this scale.
Is This Repeatable?
Yes — with conditions.
This workflow holds up on migrations and new builds where the logic is well-understood before the build starts. If you are still figuring out the logic during the build, the MCP does not help you think faster. It helps you build faster once you know what you are building.
It also requires that the MCP is properly seeded and maintained. We treat our MCP the same way we treat any production system — it needs care, updates, and refinement over time. That is not a one-time task.
For clients asking whether they can expect faster delivery on their own projects: the answer is that our delivery speed is a function of how well we understand your requirements before we build. The MCP compresses construction and repair time. Discovery and logic documentation still take the time they take. Front-loading that work is what makes the rest go fast.
Information in this article is deemed to be accurate at time of publishing. 4Spot Consulting reviews and updates content periodically as best practices evolve.
