Make.com MCP Server Cursor IDE Setup 2026: Run Scenarios as AI Tools

How do you connect Make to Cursor IDE via MCP? Create an API token in your Make profile with the mcp:use scope, add a make entry to ~/.cursor/mcp.json pointing at https://<your-zone>.make.com/mcp with that token as a Bearer header, and restart Cursor. What you get isn't generic Make API access — it's your existing scenarios, exposed as individually callable tools an agent can invoke by name.

That distinction matters more here than with most MCP servers. Make's MCP server doesn't hand Cursor a general "do anything in Make" capability; it surfaces the specific automations you've already built as discrete, invokable functions. If you haven't built scenarios worth calling from an agent, this integration has nothing to offer you yet — it's not a replacement for the Make API, it's a front door to workflows you designed.

What This Actually Connects

Make (the platform formerly called Integromat) is a visual automation builder — scenarios are the workflows you wire together from modules and triggers. The MCP server takes that existing library and turns it into agent-callable tools: a scenario named "Sync new Stripe customers to HubSpot" becomes a tool Cursor can invoke mid-conversation, with whatever inputs that scenario expects.

On top of scenario execution, depending on which scopes your token has, the server can also expose management-style tools — listing scenarios, inspecting connections, reading from data stores. The free plan is scoped down to running scenarios only; broader visibility and control needs a paid plan.

Prerequisites

Step 1: Create an MCP Token

In Make, click your name in the top-right corner, then Profile. Go to the API access tab, find the Tokens section, and click Add token.

When selecting scopes, include mcp:use — this is the scope that makes your scenarios available as MCP tools. On a free plan, you'll typically only be able to select the "run your scenarios" permission; paid plans add broader scopes like viewing and modifying scenarios, connections, and teams. Name the token something you'll recognize later (like "cursor-mcp"), then click Add to generate it. Copy it now — Make won't show it to you again.

Step 2: Configure mcp.json

Open Cursor Settings (gear icon, top right) → Tools & Integrations (labeled Tools on the Free plan) → under MCP Tools, Add Custom MCP. This opens mcp.json:

{
  "mcpServers": {
    "make": {
      "url": "https://<MAKE_ZONE>/mcp",
      "headers": {
        "Authorization": "Bearer ${env:MAKE_MCP_TOKEN}"
      }
    }
  }
}

Replace <MAKE_ZONE> with your actual zone host (for example eu2.make.com), and set MAKE_MCP_TOKEN as an environment variable holding the token from Step 1. Using ${env:...} instead of pasting the token directly keeps it out of a file you might accidentally commit.

If you hit connection errors on the base /mcp path, Make's docs note a /stream variant of the endpoint as a fallback — worth trying before assuming the token itself is bad.

Step 3: Restart and Verify

Restart Cursor fully. In chat, try:

What Make scenarios do I have available as tools?

If real scenario names come back, the connection is live. If nothing comes back but there's also no error, double check the token actually has mcp:use in its scopes — a token without it will authenticate fine and simply expose nothing.

Practical Workflows

Triggering a scenario mid-task

I just finished this feature branch. Run my "Post deploy notification to 
Slack" Make scenario with the message "checkout-v2 deployed to staging."

Chaining a scenario into a coding task

Run the "Fetch latest Airtable inventory" scenario, then write a TypeScript 
type definition based on the actual field names and types it returns.

Auditing what's automated before building something new

List my active Make scenarios and their trigger types, so I can check 
whether a Postgres row update already gets picked up somewhere before I 
add a new webhook for it.

Where This Fits vs. Building Your Own MCP Server

A reasonable question: if you're already comfortable with Cursor and MCP, why route through Make's scenario builder instead of just writing a small custom MCP server that does the same thing? The honest answer is that it depends on who owns the automation. If the workflow already exists as a Make scenario — built by an ops person, a non-engineer, or you six months ago — this is close to zero marginal cost to expose to an agent. If you're building something net-new and you're the one writing code either way, a purpose-built MCP server gives you tighter control over inputs, error handling, and output shape than a scenario's module-chain UI will. Make's MCP server is at its best as a bridge to automations that already exist, not as your first choice for automations you're about to design from scratch.

Gotchas

Scopes determine what Cursor can even see, not just what it can do. A token scoped to mcp:use plus nothing else will run scenarios but won't let Cursor list or inspect them meaningfully — plan your scope selection around whether you want the agent to discover tools or just invoke ones you tell it about by name.

Free plan tokens are limited to running scenarios, not managing them. If you're on a free plan and expecting to have Cursor create or modify scenarios through this connection, that's not available — management scopes are paid-plan only.

The zone in your URL has to match your actual account zone exactly. Make accounts are provisioned to a specific regional cluster (us1, us2, eu1, eu2, etc.). Pointing mcp.json at the wrong zone doesn't gracefully redirect — it just fails to connect.

A scenario built for manual/webhook triggering doesn't automatically become "safe" to run from an agent. If a scenario sends an email, charges a customer, or writes to a production database, invoking it from an LLM-driven chat means the LLM is now a trigger source. Review what each exposed scenario actually does before treating "list scenarios" output as a menu Cursor can safely pick from unsupervised.

Troubleshooting

Token authenticates but no scenarios show up
The token's scopes don't include mcp:use, or the scenarios themselves are deactivated. Reactivate the scenario in Make and confirm the token's scope list before assuming the MCP layer is broken.

Connection refused or timeout on https://<zone>/mcp
Try the /mcp/stream variant of the URL mentioned in Make's own docs, and confirm the zone subdomain matches what's in your browser URL bar when logged into Make — not a guess based on your account's country.

A scenario runs from Make's own UI but fails when triggered via Cursor
Check whether the scenario expects a webhook payload shape or trigger-specific input that Cursor isn't supplying correctly — MCP tool invocation passes structured arguments, which may not match a trigger module's exact expected fields without adjustment.

403 errors specifically on management-style calls (listing connections, teams)
Expected on a free-plan token — those scopes aren't available below a paid plan, regardless of what you selected during token creation.

Frequently Asked Questions

Q: Is Make's MCP server official, or a community project?
A: Official — it's documented and hosted by Make itself (Make Developer Hub), not a third-party wrapper around Make's API.

Q: Can I use this on Make's free plan?
A: Yes, but scoped down — free-plan tokens can select "run your scenarios" only. Viewing or modifying scenarios, connections, teams, and organizations through MCP requires a paid plan.

Q: Does connecting MCP let Cursor build new Make scenarios from scratch?
A: Not directly through the standard scenario-execution scopes — this integration is built around invoking and (on paid plans) inspecting scenarios you've already created, not visually assembling new ones the way Make's own builder UI does.

Q: What's the difference between the base /mcp endpoint and the /stream variant?
A: Make's own documentation lists /stream as an alternative connection path to try if the base /mcp endpoint has connection issues — both point at the same underlying server, just different transport handling.

Q: Is it safe to expose all my scenarios to an agent at once?
A: Only if you'd be comfortable with any of them running unattended based on an LLM's judgment. Scope tokens narrowly and review what each exposed scenario actually does — sending emails, writing to production systems — before treating the full list as safe to invoke.

Related Guides