Connect the Make (get a free month of Make with 10K free actions here) MCP server to Claude. Describe the automation you want in plain language. Review the blueprint Claude generates. Import it into Make, connect your apps, and run a test. That is the full process — no module documentation, no field mapping guesswork, no prior Make experience required.

This how-to covers the exact steps from a blank Make account to a running automation using only a text description and Claude. For the context on what makes this possible and how it compares to building manually, see the Make vs Zapier vs N8N Complete 2026 Guide.

How Do You Connect the Make MCP Server to Claude?

In Claude Code, open your settings file (~/.claude/settings.json or the project-level equivalent). Add the Make MCP server configuration under the mcpServers key:

{
  "mcpServers": {
    "make": {
      "command": "npx",
      "args": ["-y", "@make/mcp-server"],
      "env": {
        "MAKE_API_KEY": "your-make-api-key-here",
        "MAKE_ZONE": "eu1"
      }
    }
  }
}

Set MAKE_ZONE to your Make account’s data region — eu1 for European accounts, us1 for US accounts. Find your zone in Make’s account settings under API. Restart Claude after saving the config. Verify the connection by asking Claude: “List my Make scenarios.” Claude returns your scenario names and IDs if the connection is live.

How Do You Write a Description That Produces a Good Blueprint?

The quality of the output matches the clarity of the input. Vague descriptions produce blueprints that need significant editing. Specific descriptions produce blueprints that need only credential connection and a test run.

A good description answers four questions:

1. What triggers the automation? “When a new form submission arrives from my Gravity Forms contact form…”
2. What conditions apply? “…where the Budget field is greater than $10,000…”
3. What actions happen? “…create a contact in HubSpot, send a Slack message to the #sales channel with the submitter’s name and budget, and log the submission to the Sales Pipeline Google Sheet.”
4. What should happen on failure? “If the HubSpot write fails, send me an email alert instead of losing the submission.”

Name your apps specifically (“HubSpot” not “my CRM,” “Google Sheet named Sales Pipeline” not “a spreadsheet”). Claude uses these names to select the correct Make modules.

How Do You Review the Blueprint Before Importing?

Claude returns a JSON blueprint. Before importing, ask Claude to explain what it built: “Walk me through each module in this blueprint and why you chose it.”

Claude explains: “Module 1 is a Webhooks > Custom Webhook trigger — this receives your Gravity Forms submission. Module 2 is a Router with two branches. Branch A handles submissions with Budget > 10000 and creates the HubSpot contact. Branch B catches all other cases…”

Read the explanation and verify it matches your intent. Common points to confirm:

• The trigger type is correct (webhook vs. scheduled vs. app-specific trigger)
• Conditional logic branches match your conditions
• All destination apps are included
• Error handling is present (look for a router branch or error handler module on critical write operations)

If anything is wrong, describe the correction: “The HubSpot contact should be created before the Slack message, not after.” Claude updates the blueprint in the same conversation.

How Do You Import the Blueprint Into Make?

In Make, click “Create a new scenario.” In the scenario editor, click the three-dot menu (top right). Select “Import Blueprint.” Paste Claude’s JSON output. Make renders the scenario in the visual editor with all modules positioned.

You will see orange warning indicators on any module that needs a connection — this is expected. The structure is correct; you are connecting the accounts next.

How Do You Connect Your Apps and Set the Field Mappings?

Click each module with an orange indicator. For OAuth apps (Gmail, HubSpot, Slack, Google Sheets), click “Add a connection” and complete the standard OAuth flow. For API-key apps, paste your key.

After connecting, open the module configuration fully and check field mappings. Claude maps fields by name — verify the field names in Make’s module match your actual data structure. For Google Sheets, confirm column headers exactly match. For CRM modules, confirm property names match your CRM’s field labels.

If any field label doesn’t match, update it in the module mapping interface. This takes 2–3 minutes per module for most scenarios.

How Do You Test the Scenario Before Activating?

Click “Run once” in the scenario editor. Perform the trigger action in the real app — submit the form, create the record, drop the file. Watch the scenario execute in real time. Each module shows its execution status and the data it processed.

Click any module after the run to see exactly what data it received as input and what it sent as output. If a module fails, the error message identifies the problem precisely — usually a field name mismatch or a missing required field.

Fix the issue in the module configuration and click “Run once” again. Most first-run issues resolve in one correction cycle.

Verify the output in the destination systems — confirm the HubSpot contact was created correctly, the Slack message arrived with the right data, the sheet row was added in the right format.

How Do You Know It Worked?

The scenario’s execution history shows a green checkmark for successful runs. Click any run to see the full data flow. All destination systems show the correct records from the test run.

After a clean test run, toggle the scenario active from the editor or the scenario list. Make begins processing real triggers. The execution log updates after every run — check it after the first few live runs to confirm everything continues working correctly.

Common Mistakes to Avoid

• Being vague about app names. “My CRM” produces a generic placeholder. “HubSpot” produces the correct module. Name every app specifically.
• Skipping the blueprint explanation step. Claude’s explanation catches mismatches between your intent and the generated structure before you spend time on credentials and testing.
• Not specifying error handling. If you don’t mention it, Claude may omit it. Always ask Claude to include an error handler for any module that writes data to an external system.
• Testing without the real trigger. The “Run once” button requires you to perform the actual trigger action in your app. Clicking “Run once” alone does nothing — you have to create the record, submit the form, or fire the webhook.
• Activating before verifying destination data. A green execution log means the module ran without errors — not necessarily that the data landed correctly. Check the destination app before declaring success.

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