Make hosts an MCP server that turns on-demand scenarios into typed tools, and it has a REST API that runs the same scenarios, manages the same data stores, and has a long track record. Both reach the same automations. They differ on timeouts, zones, plan gating, and who holds which credential. This guide compares what each path lets an agent do, the OAuth and API token paths each one puts you on, and how to run either across many customer organizations in production.
Your agent needs to act through Make. A customer's revenue team has spent three years building scenarios that sync HubSpot to NetSuite, enrich leads, and post to Slack, and your agent should call those scenarios instead of rebuilding them. Make hosts an MCP server that turns those scenarios into tools, and Claude and ChatGPT already connect to it. Make also has a REST API that runs the same scenarios, manages the same data stores, and has a long track record. Both reach the same automations. They differ on timeouts, zones, plan gating, and who holds which credential. Here's how to pick.
Make's MCP server is a cloud-hosted Model Context Protocol (MCP) server that Make operates, using stateless Streamable HTTP. Make announced it on May 16, 2025 as a gateway that "turns your Make scenarios into tools that AI agents can call upon." It replaced the earlier local @makehq/mcp-server npm package, which is now labeled legacy. Make's docs carry no beta label for the hosted server.
Two kinds of tools come out of it. Scenario run tools are generated from your own scenarios: a scenario becomes a tool when it is active, uses on-demand scheduling, and has scenario inputs and outputs defined. Those inputs become the tool's parameters, and the scenario description becomes the tool's description. Management tools cover scenarios, executions, hooks, data stores, data structures, connections, keys, folders, teams, organizations, and custom apps. Scenario run tools work on every plan; management tools need a paid plan.
Clients connect two ways. OAuth uses the universal https://mcp.make.com/v2 URL and a consent screen where the user picks an organization and scopes. An API key (Make calls it an MCP token) uses https://<MAKE_ZONE>/mcp/v2 with Authorization: Bearer <API_KEY>, or the key embedded in the path at https://<MAKE_ZONE>/mcp/u/<API_KEY>/v2. For curated sets of scenarios, Make also offers MCP toolboxes: dedicated servers with their own keys, where each tool can be marked Read only or Read & write.
The Make API is REST under /api/v2 on the zone that hosts the organization: https://eu1.make.com/api/v2, eu2, us1, us2, and the Celonis EU1 and US1 zones. It covers scenarios (run, create, update, start, stop, clone), blueprints, executions and logs, hooks (webhooks and mailhooks), data stores and their records, data structures, connections, keys, teams, organizations, templates, and custom apps. Make notes that most endpoints are reserved for paid plans.
Auth is an API token sent as Authorization: Token <token>, created in Profile > API access with explicit scopes, or an OAuth 2.0 client. OAuth uses global endpoints at https://www.make.com/oauth/v2/authorize and /oauth/v2/token, supports OpenID Connect, and requires PKCE for single-page and mobile apps. Clients aren't self-service. You submit a registration form and Make reviews it within 10 business days.
The two surfaces overlap almost completely on management, because Make's MCP management tools are a thin layer over the same API. Where they diverge is in what happens at the edges. MCP gives you typed scenario tools without writing a schema and a guided credential-request flow; the API gives you callbacks for long runs, event subscriptions, and complete hook control.
The scenario-as-tool model is the reason Make MCP exists. A scenario named "Create NetSuite invoice" with inputs customer_id, amount, and currency shows up as a tool with those three parameters and the scenario's own description. On the API, your agent needs makemcp_scenarios_interface or its REST equivalent to read the input spec, then a schema you write, then POST /scenarios/{id}/run with a data object that matches it. Writing the schema is the hard part. Not the API call.
The tradeoff is that the scenario author now writes your tool descriptions. Make's docs tell you to write detailed scenario descriptions to improve results, which means a vague description in a customer's Make account becomes a wrong tool call in your agent. Tool names are also truncated to 56 characters by default (?maxToolNameLength accepts 32 to 160), so two scenarios with long, similar names can collide in ways the scenario builder never sees.
Scale matters too. Scalekit classifies 57 of the 163 tools as destructive, including makemcp_scenarios_delete, makemcp_organizations_delete, and makemcp_keys_delete. It also marks makemcp_scenarios_run as destructive, which is the honest classification: running a scenario can send email, charge a card, or delete records, and the tool schema can't tell you which.
OAuth is the cleaner path. The user connects to https://mcp.make.com/v2, signs in to Make, picks an organization, and approves scopes. The "Run your scenarios" scope exposes every active on-demand scenario in that organization; management scopes cover the rest. Make's docs say "only OAuth allows you to restrict access to a specific Make organization," and the universal URL means your client never needs to know whether the customer is hosted in eu1 or us2. For narrower access, Make's guidance is to use a Teams plan or higher and assign the connecting user to specific teams.
The API key path trades consent for portability. The key needs the mcp:use scope for scenario tools, and by default it reaches every active on-demand scenario across every organization the user belongs to. You narrow that with one URL parameter: ?organizationId=, ?teamId=, or ?scenarioId[]= repeated for multiple scenarios. The levels are mutually exclusive, and they apply only to scenario tools; management tools ignore them. Make warns plainly that an API key is a secret. Putting it in the URL path, which is one of the two supported formats, puts it in every proxy log, client config file, and screenshot that captures that URL.
API tokens carry explicit scopes per resource: scenarios:read, scenarios:write, and scenarios:run; hooks:read and hooks:write; datastores:read and datastores:write; connections:read and connections:write; plus scopes for teams, organizations, keys, functions, templates, data structures, incomplete executions (dlqs:read), and custom apps (scope list). An agent that only reads execution history and runs scenarios needs scenarios:read and scenarios:run, not scenarios:write. Least privilege is available; it's just not the default when a user generates a token in a hurry.
Three details break naive implementations:
In a multi-tenant B2B agent, MCP's OAuth flow gives you a token per user, and direct API calls give you a credential per user. In neither case does the path itself solve storage, rotation, or revocation; those are infrastructure problems regardless of which path you choose.
Make adds one sharp edge. Make credentials reach downstream credentials. A Make user's token doesn't just read Make data; it runs scenarios that hold the customer's Salesforce, Stripe, and Gmail connections. The blast radius of one leaked Make token is every system those scenarios touch.
Recommended reading: OAuth vs API keys for AI agents
Make hosts the server, generates scenario tools from scenario interfaces, and owns the management tool schemas. You own the OAuth grant per user, its storage and refresh, and the timeout behavior. Over OAuth, scenario run tools time out at 25 seconds and management tools at 30; with an API key, those limits are 40 and 60 seconds. A timed-out run keeps going for up to 40 minutes, and the response includes an executionId and scenarioId. Your agent then has to poll with makemcp_executions_get, which needs scenarios:read on the scenario's team. If the grant lacks that scope, the result is lost to the agent even though the scenario finished.
The tool list also changes when your customer changes Make. Activate a new on-demand scenario and a new tool appears; rename one and a tool name changes; switch a scenario to scheduled and its tool disappears. Your agent's tool surface is now partly owned by whoever builds scenarios in the customer's account.
You own schemas, zones, retries, and the token lifecycle. Rate limits are per organization: 60 requests per minute on Core, 120 on Pro, 240 on Teams, and 1,000 on Enterprise (rate limiting). Exceeding them returns 429 with "Requests limit for organization exceeded, please try again later." The limit is shared by every token in the organization, so your agent competes with the customer's own scripts. You can read the current limit from license.apiLimit on GET /organizations/{organizationId}.
POST /scenarios/{scenarioId}/run is exempt from those request limits, but not from operations limits. If the organization or team is paused for exceeding its operations or data transfer allowance, the run returns 429 with code IM310. That's a billing state, not a transient error, and retrying with backoff just burns time. Route it to the customer.
For long runs, send responsive: false with a callbackUrl. Make posts the executionId and a statusUrl there when the run finishes. For change events, Make's event subscriptions deliver signed POST requests with a Webhook-Id that stays stable across retries, so dedupe on it. Hooks have their own rules: deleting a hook attached to a scenario requires confirmed=true, because the scenario stops working without it.
The API is versioned in the path (/api/v2), and changes arrive on Make's schedule. The MCP server has already moved once, from the local npm package to the hosted v2 endpoint, and its scenario tools change whenever a customer edits a scenario's inputs. On the API path, a change is something you adopt. On the MCP path, the tool list your agent sees can change between runs, for reasons nobody on your team controls.
Both paths hand you a Make credential per user. Neither hands you a vault. A multi-tenant agent serving 60 customer organizations with 5 builders each holds 300 Make grants or tokens. Each is bound to one user, one zone, and one set of scopes. Each must be stored encrypted, kept out of logs and LLM context, refreshed if it's an OAuth grant, and revoked when a builder leaves or a customer churns.
The token type changes between paths; the problem doesn't. The tempting shortcut is one API token per customer, generated by an admin with every scope and pasted into the MCP URL path. That collapses 300 credentials into 60 secrets that run every scenario in every organization the admin belongs to, sit in plaintext in a URL, and carry the admin's access to every downstream system those scenarios connect to. Fewer secrets, a much larger blast radius per secret.
Scalekit's makemcp connector handles the OAuth flow against Make's MCP server, stores each user's tokens in the token vault, and refreshes them, so the MCP vs API decision doesn't change your auth infrastructure. Your agent passes an identifier; credentials never touch the agent runtime or the LLM context.
Recommended reading: why a token vault matters for AI agent workflows
Scalekit's makemcp connector is a vendor MCP connector: it routes your agent's tool calls to Make's own hosted MCP server through Scalekit. It exposes 163 tools: 79 read, 27 write, and 57 destructive. It authenticates with OAuth 2.1. Each user signs in to Make once, and Scalekit can use its own managed OAuth client, so you don't need to wait on Make's OAuth client review to get started.
In the Scalekit dashboard, go to AgentKit > Connections and create a Make MCP connection. The name you give it is the connection_name your code passes, and the string must match the dashboard exactly. This is the most common integration error. Copy SCALEKIT_ENVIRONMENT_URL, SCALEKIT_CLIENT_ID, and SCALEKIT_CLIENT_SECRET from Developers > API Credentials into .env.
get_or_create_connected_account returns the user's connected account. If it isn't ACTIVE, get_authorization_link returns a Make OAuth link. The user signs in, picks the Make organization, and approves scopes once; Scalekit stores and refreshes the tokens.
This is not a catalog load. The agent asks for the tools this user's connected account is authorized to call, then narrows them to the six an operations agent needs. Loading all 163 would put makemcp_scenarios_delete, makemcp_organizations_delete, and the custom-app editing tools in front of a model whose job is to run one scenario and report on it. Those tools never reach the model, so it can't delete a scenario while trying to fix one.
The loop runs until the model stops requesting tools. Every call executes with this user's Make grant, in the organization they selected at consent, and sees only the teams they belong to.
For pipelines, skip the model. execute_tool runs one tool with a fixed input and returns data plus an execution_id you can log. This job runs a known scenario with fixed inputs, then reads the Make execution it produced. The scenario ID comes from your app's config for this customer, resolved once with makemcp_scenarios_list.
Reading shared state works the same way. Many Make accounts keep lookup tables, such as a customer-to-region map, in data stores, and makemcp_data-store-records_list takes a dataStoreId and an optional limit:
Two IDs show up here, and they're different. execution_id on the response is Scalekit's record of the tool call. The executionId inside data is Make's record of the scenario run. Log both.
Scalekit doesn't ship a prebuilt connector for the Make REST API. If you need callbackUrl runs, hook enable and disable, or event subscriptions, create a custom connector with API_KEY auth, a zone field that the proxy_url uses, and an auth_field_mutations rule that adds the Token prefix Make expects:
Create a connection for it in AgentKit > Connections. Each user enters their zone and token once on the Scalekit-hosted page from get_authorization_link. If your product already collects Make tokens in its own settings page, write them from your backend instead, and make proxied calls with actions.request():
The zone lives on the connected account, next to the token, so the same code reaches a customer in eu2 and another in us1.
The makemcp connector has 163 tools. At roughly 200 tokens each, that's about 32,000 tokens of tool definitions before the agent does any work, and a model choosing among makemcp_scenarios_get, makemcp_scenarios_interface, makemcp_show_scenarios_list, and makemcp_scenarios_list picks wrong more often than one choosing among two. Overreach is the bigger risk: 57 of those tools are destructive, and an agent that only reports on failed runs has no reason to hold makemcp_scenarios_delete. A Scalekit virtual MCP server declares exactly which tools an agent role can see, and session tokens keep each run bound to one user's connected accounts. Docs: set up a virtual MCP server.
One server definition serves every user. Before each run, check that the user's accounts are active and mint a short-lived session token scoped to them. Any MCP client that speaks Streamable HTTP can connect; this example uses langchain-mcp-adapters (pip install langchain-mcp-adapters) and passes the token as a Bearer header.
The agent sees four tools instead of 163 Make tools plus everything Slack exposes. The endpoint is static; the identity is per-user. Unlike a Make API key in a URL path, the session token expires in 30 minutes and carries no Make credential at all; Scalekit resolves the user's Make grant at call time.
Every execute_tool call returns an execution_id, and every execution is attributed to a connected account, which maps to one of your users and one customer. Make records its own side: each scenario run has an executionId, visible in the scenario's history. Logged together, the two answer the question customers actually ask: which agent run, for which user, triggered the scenario that sent 400 invoices.
A shared credential breaks that. If every user's agent runs on one admin's API token, Make attributes every run and every edit to that admin, every agent can reach every scenario the admin can, and your side can only prove that the shared token did it. Shared credentials are a single-user solution. They do not survive a second user.
Recommended reading: audit trails for agent auth
If your agent is an assistant that runs a customer's existing on-demand scenarios, inspects executions, and helps builders debug while a human watches, Make's hosted MCP server is a good fit: scenarios become typed tools with no schema work, OAuth hides the zone, and scenario tools work even on the Free plan. If your agent runs unattended, waits on scenarios longer than 25 seconds, reacts to events, or needs per-scope least privilege across customers in several zones, build against the Make API and treat the scenario as a function you call with callbackUrl. Either way, you hold one Make credential per user that can run automations reaching every downstream system the customer has connected, and that's what needs production-grade infrastructure.
Yes. Make runs a hosted, stateless Streamable HTTP MCP server. With OAuth every client uses one URL, https://mcp.make.com/v2, and the user picks an organization and scopes at consent. With an API key the URL is zone-specific, https://<MAKE_ZONE>/mcp/v2. Any active scenario with on-demand scheduling and defined inputs and outputs becomes a typed tool on every plan; management tools need a paid plan.
Scenario run tools time out at 25 seconds over OAuth and 40 seconds with an API key, and management tools at 30 and 60. The scenario keeps running for up to 40 minutes, and the client gets back an executionId to poll. Long-running automations belong on the API, where a run can be sent with responsive false and a callbackUrl that Make posts to when it finishes.
With API tokens sent as Authorization: Token, created under Profile > API access with explicit scopes such as scenarios:read, scenarios:run, and scenarios:write, or with OAuth 2.0 clients that Make reviews within 10 business days. The base URL depends on the organization's zone, so a token for an eu2 organization fails against us1. Scopes are per resource type, not per scenario.
Per organization: 60 requests per minute on Core, 120 on Pro, 240 on Teams, and 1,000 on Enterprise, shared by every token in the organization. The scenario run endpoint is exempt from request limits but not from operations limits; a paused organization returns 429 with code IM310, which is a billing state rather than a transient error.
When it runs headless and a scenario takes longer than 25 seconds, when it needs per-scope least privilege such as read and run without write across customers in several zones, when it reacts to event subscriptions that report scenario changes, or when it writes to data stores in bulk and must budget against the organization's request limit.
The makemcp connector routes tool calls to Make's hosted MCP server through Scalekit, exposing 163 tools with OAuth 2.1 and a managed OAuth client, so there is no wait for Make's client review. Each user signs in once and picks their organization, Scalekit stores and refreshes the tokens, a virtual MCP server narrows the tools per agent role, and every execution returns an execution_id next to Make's own executionId.
Browse the Scalekit Make MCP connector and the Make MCP connector docs with the full tool list. See Scalekit pricing, or talk to us.
