# Make.com has an MCP endpoint now. The auth token goes in the URL — and 3 other walls the docs skip > Source: > Published: 2026-06-14 16:26:58+00:00 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. 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: `Authorization: Token ` — `Bearer` . (Hold that thought; it comes back.)The object hierarchy is Organization → Team → Scenario. Natural assumption: list scenarios by the org you're in. ``` GET /api/v2/scenarios?organizationId= → not what you want GET /api/v2/scenarios?teamId= → ✅ ``` `/scenarios` is scoped to a **team**, not an organization. So the real discovery sequence is: ``` GET /organizations GET /teams?organizationId= GET /scenarios?teamId= ``` Skip the middle call and you'll spend ten minutes convinced your token lacks scope, when it's just keyed on the wrong ID. 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: ``` python 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. 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//stateless ``` Header auth on `/mcp` : 404. Token baked into the path on `/mcp/u//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. 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.*