Make.com has an MCP endpoint now. The auth token goes in ...

I already let my AI agent read and repair my self-hosted n8n workflows. So when a client's Make.com scenario started misfiring — duplicate WhatsApp order notifications, fired in bursts — my first instinct wasn't to log into the web UI. It was: can I give the agent the same remote access to Make that it has to n8n?

Make.com shipped both a REST API and an MCP endpoint. So yes. But getting from "they have an API" to "my agent is connected and patching a live scenario blueprint" meant walking into four undocumented walls. Here they are, in the order they hit me.

Wall 1: The API is behind Cloudflare, and it hates your User-Agent

My first call was a throwaway Python script — urllib.request to GET /api/v2/users/me. It came back 403.

Not 401 (bad auth). 403. The token was fine. The request never reached Make's application layer — Cloudflare's WAF bounced it on the User-Agent. The default Python-urllib/3.x UA is on a block list.

The fix is unglamorous: use curl (whose UA sails through) and pipe the body into Python only for parsing.

T=$(security find-generic-password -s make-api-token -a "$USER" -w)
curl -s -H "Authorization: Token $T" \
  "https://eu2.make.com/api/v2/users/me" | python3 -m json.tool

Two things worth noting even in this tiny snippet:

Auth is Authorization: Token <token> — not Bearer. (Hold that thought; it comes back.)
The token never gets typed or echoed. It lives in the macOS Keychain and is read at call time. Secrets in shell history are secrets you've already leaked.

Wall 2: Listing scenarios needs a teamId, not an organizationId

The object hierarchy is Organization → Team → Scenario. Natural assumption: list scenarios by the org you're in.

GET /api/v2/scenarios?organizationId=<org>   → not what you want
GET /api/v2/scenarios?teamId=<team>          → ✅

/scenarios is scoped to a team, not an organization. So the real discovery sequence is:

GET /organizations
GET /teams?organizationId=<org>
GET /scenarios?teamId=<team>

Skip the middle call and you'll spend ten minutes convinced your token lacks scope, when it's just keyed on the wrong ID.

Wall 3: The blueprint JSON won't parse — and it's not your code

The whole point was to fix the scenario, and on Make the editable definition is the blueprint:

GET   /api/v2/scenarios/{id}/blueprint     # read it
PATCH /api/v2/scenarios/{id}               # write it back, blueprint as a JSON string

I pulled the blueprint, piped it through jq, and got a parse error. The JSON was, by the spec, invalid.

The cause: the scenario sends Hebrew WhatsApp messages, and the message templates contain raw, unescaped newline characters inside string values. Strict JSON forbids literal control characters in strings; Make emits them anyway.

jq refuses. So does Python's default json.loads. The escape hatch is one keyword:

import json, sys
blueprint = json.loads(sys.stdin.read(), strict=False)  # tolerate raw control chars

strict=False tells the parser to accept the control characters instead of throwing. Once it's a Python object you can edit the module you care about, re-serialize, and PATCH it back as a string.

Wall 4: The MCP endpoint 404s on a Bearer header

This was the one that cost me the most time, because everything looked right.

Make exposes an MCP server. I added it to my agent the way I add every other remote MCP — URL plus an Authorization: Bearer header. 404. Not 401. 404, as if the endpoint didn't exist.

It doesn't — not at the path I was using. The Make MCP doesn't authenticate via header at all. The token goes in the URL path:

https://eu2.make.com/mcp/u/<token>/stateless

Header auth on /mcp: 404. Token baked into the path on /mcp/u/<token>/stateless: 200, connected.

That's an awkward shape if you care about not pasting secrets into config files — a URL with a live token in it is exactly the kind of string that ends up committed. The way out is to assemble the URL at launch time from the Keychain, so the token is never written to disk:

// MCP server entry
{
  "command": "bash",
  "args": [
    "-c",
    "exec mcp-remote \"https://eu2.make.com/mcp/u/$(security find-generic-password -s make-api-token -a $USER -w)/stateless\""
  ]
}

mcp-remote bridges the streamable HTTP endpoint to a local stdio MCP server. The $(...) runs every launch, so the config on disk contains a Keychain lookup, never the token itself. Same pattern I use for other path-token services.

The payoff

Four walls — a WAF User-Agent block, a team-vs-org ID, control characters in "valid" JSON, and path-based MCP auth — and on the other side the agent can do, remotely and unattended, what used to mean opening the Make UI and clicking through a scenario by hand: list orgs and teams, pull a misbehaving scenario's blueprint, diff it, and PATCH the fix.

None of these are in the quickstart. All four are the difference between "they have an API" and "it actually works." If you're wiring an AI agent into Make.com, start with curl (not your HTTP library), scope /scenarios by team, parse blueprints with strict=False, and put the MCP token in the path.

I build WhatsApp bots and business automation for companies — self-hosted n8n, Make.com, WAHA, the works. More war stories and guides at Achiya Automation.

推荐订阅源