Make.com has an MCP endpoint now. The auth token goes in the URL — and 3 other walls the docs skip

A developer connecting an AI agent to Make.com's API encountered four undocumented issues: Cloudflare blocking Python's default User-Agent, scenarios being scoped to teams rather than organizations, unescaped newline characters in JSON blueprints requiring strict=False parsing, and the MCP endpoint requiring the auth token in the URL path instead of a header.

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 <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=<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. 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/<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. 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.