Post: How Seeding an MCP With Existing Scenarios Changed Our Build Quality Overnight
There is a version of our Make MCP server that produced frustrating results. Modules came back with missing credentials. JSON structure was close but not quite right. We spent more time fixing outputs than we saved building them. That version existed because we skipped a step we did not know mattered.
The step is seeding. Once we understood it — and applied it — the quality gap between AI-assisted builds and hand-built scenarios nearly closed overnight. If you have been following our field notes on running Make with Claude, this is the lesson that made the rest of those lessons possible.
Here is what happened, what changed, and how you can replicate it.
- Problem: Claude built valid-looking scenarios with structural errors that required manual correction on every build
- Cause: MCP had no reference for our credential schema, module formatting conventions, or JSON patterns
- Fix: Seeded the MCP with a library of real, production-proven scenarios before any new builds ran
- Result: Credential blocks and JSON structure came back correct the first time — no manual fill-in required
- Time saved per scenario: 20–40 minutes of post-build cleanup eliminated
What Was Going Wrong Before We Seeded?
Our MCP was technically functional from day one. Claude could read our instructions, understand the task, and return a Make scenario in JSON. The problem was in the details — and in Make, the details are everything.
Credential blocks were the biggest offender. Make stores credentials as connection references tied to specific connection IDs. Claude did not know our connection IDs. It did not know our naming conventions. It did not know which credential type mapped to which service in our stack. So it guessed — and it guessed plausibly, which made the errors harder to catch.
The second problem was module internals. Make’s JSON schema for individual modules is precise. Field names, nesting depth, data type expectations — all of it has to be exactly right or the import fails silently, or worse, imports and then breaks mid-run. Claude knew the general structure of Make modules. It did not know the specific structure of our modules, built the way we build them.
Every build required a correction pass. We were checking credential references manually, adjusting field mappings, fixing nesting. The automation was saving some time. But it was not saving as much as it should have.
What Does Seeding Actually Do?
Seeding means giving the MCP a set of real, working scenarios before you ask it to build anything new. Not documentation. Not descriptions. Actual exported JSON from scenarios that already run in production.
When Claude has those examples, it learns the specific patterns of your stack — not Make’s patterns in the abstract, but your Make environment specifically. It sees how your credential blocks are structured. It sees your naming conventions. It sees how you handle pagination, how you format webhook payloads, how your error routing is organized.
From that point forward, when you ask it to build a new scenario, it is not inferring structure from general knowledge. It is matching structure from your existing library. The difference in output quality is significant.
Think of it the way a new hire learns your systems. You can hand them a manual, or you can sit them down with ten real examples of work product that already passed review. The examples win every time. Seeding is the equivalent of the examples.
How We Ran the Before/After Comparison
We did not set out to run a formal test. The comparison emerged because we had logged our build sessions before and after seeding as part of normal documentation practice.
The table below reflects what we observed across a set of comparable scenario builds — similar complexity, similar module counts, similar integration targets — in the two weeks before seeding and the two weeks after.
| Metric | Before Seeding | After Seeding |
|---|---|---|
| Credential blocks correct on first output | Rarely — required manual fill-in every time | Consistently correct — no manual fill-in |
| JSON nesting errors on import | Present on most builds | Rare — occasional edge cases only |
| Post-build correction time per scenario | 20–40 minutes | 0–5 minutes |
| Module field formatting accuracy | Inconsistent | Consistent — matched our production conventions |
| Naming convention compliance | Ad hoc — had to prompt for it each time | Automatic — pulled from seeded examples |
The pattern was clear. Seeding did not make Claude smarter about Make in general. It made Claude accurate about our Make environment specifically. That is the distinction that matters.
How Do You Seed Your Own MCP?
The process is straightforward. Here is how we did it and what we recommend.
Step 1: Select your seed scenarios carefully. You want variety, not volume. Pick scenarios that represent different integration patterns — one that uses webhooks, one that uses scheduled triggers, one that uses HTTP modules for a custom API, one with error routing. Aim for five to ten scenarios that collectively cover the range of your stack.
Step 2: Export the JSON from Make. In your Make account, open each scenario and use the export function to get the raw JSON. This is the actual blueprint file Make uses to define the scenario. Do not summarize it or paraphrase it — give Claude the real file.
Step 3: Load the exports into your MCP’s context or knowledge base. How you do this depends on your MCP setup. In our implementation, we store seed scenarios as reference files that the MCP pulls from at the start of every session. The key is that they are available before any build request runs — not retrieved on demand afterward.
Step 4: Include a brief annotation with each seed file. One or two sentences explaining what the scenario does and what patterns it demonstrates. This helps Claude retrieve the right reference when your build request is contextually similar to a specific example.
Step 5: Refresh your seed library when your stack changes. If you add a new integration or change your credential naming conventions, add a new seed scenario that reflects the update. Stale seeds produce stale outputs.
That is the full process. It takes about an hour the first time you do it. It pays back that hour on the first build that comes out clean.
This approach connects directly to what we cover in our production lessons from running a custom Make MCP server — seeding is lesson one because everything else depends on it.
What This Reveals About How MCP Context Actually Works
There is a broader lesson here that applies beyond seeding.
Claude is not building your scenarios from a neutral starting point. It is pattern-matching against everything it knows about Make, JSON, APIs, and automation conventions generally. When your MCP has no examples from your environment, that general knowledge is all it has to work with.
General knowledge produces generally correct outputs. Specific examples produce specifically correct outputs. The gap between those two things is where most of the build quality problems live.
Seeding is how you close that gap. It is not a hack or a workaround. It is the intended use of MCP context — you are giving the model the reference material it needs to match your environment instead of approximating it.
If you are building with Claude and Make and your outputs are close but not quite right, seeding is almost certainly the issue. Start there before you adjust your prompts, your instructions, or your workflow. You will save yourself a lot of iteration.
For the full picture of how we built and use this system, see why we built our Make MCP server before Make built one and our step-by-step guide on how to build a Make scenario with Claude.
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 does it mean to seed a Make MCP with existing scenarios?
Seeding means loading real, exported Make scenario JSON files into your MCP’s context before asking it to build anything new. This gives Claude concrete examples of your specific credential structure, module formatting, and naming conventions — so its outputs match your environment instead of a generic approximation of Make.
Why did our MCP produce credential errors before we seeded it?
Without seeded examples, Claude had no reference for your connection IDs, credential types, or naming conventions. It inferred plausible-looking values from general knowledge of Make’s schema. Those inferences were consistent enough to look correct but wrong enough to break on import or require manual correction every time.
How many scenarios do you need to seed an MCP effectively?
Five to ten scenarios is the right range for most stacks. The goal is variety, not volume. Choose examples that collectively cover your main integration patterns — webhooks, scheduled triggers, HTTP modules, error routing — so Claude has a reference for each type of build it will encounter.
Does seeding need to be updated as your stack changes?
Yes. If you add a new integration, change your credential naming conventions, or adopt new module patterns, add a new seed scenario that reflects the update. Stale seeds produce stale outputs — the MCP will continue matching against the old pattern until you replace it.
How long does it take to seed an MCP for the first time?
Roughly an hour for the initial setup — selecting scenarios, exporting the JSON, loading the files, and writing brief annotations for each. That hour pays back on the first build that comes out clean, because you eliminate the 20–40 minutes of post-build correction that was previously required on every scenario.
Can seeding help if Claude is already producing mostly correct outputs?
Yes. Even when outputs are mostly correct, seeding eliminates the remaining inconsistencies — naming convention drift, occasional nesting errors, credential references that are close but not exact. It is the difference between outputs that need a correction pass and outputs that are ready to import directly.
