Make

If you are working out whether Make belongs in your stack, here is the operator view. GetAgentTools lists only what I actually use, with a verdict and no sponsored placements. Verdict first, then the detail.

Verdict: RUNNING. In one line: no-code glue that keeps running for months.

What Make is and how it works

A scenario is a chain of modules. The first one listens or polls, a webhook arriving, a row appearing, a scheduled check. Every module after it does one action in one app: add a sheet row, post to an endpoint, send a message. Routers split the path, filters decide what passes, and the execution log shows you the data that went through each module on each run.

The catalogue is the selling point. More than 3,000 apps have ready-made modules, so the connector, the auth flow and the retries are already written. When an app is missing, the generic HTTP module covers it, which is the escape hatch that keeps Make useful past the catalogue.

Now the number that decides the cost: every module action that runs bills a credit. Their docs put it plainly, adding a Google Sheet row or fetching account data counts as one credit each. Credits replaced operations as the billing unit on 27 August 2025 and converted one to one, so older write-ups talking about operations are describing the same thing under the old name.

Why Make is RUNNING in my stack

Lead forms to sheets, webhooks to CRMs. Scenarios I built once and stopped thinking about.

The verdict is about maintenance, not features. Scenarios I built once and stopped thinking about. A lead form dropping rows into a sheet, a webhook pushing into a CRM. Those are unglamorous jobs that a script can also do, and then the script needs a host, a scheduler, credential rotation and somebody to notice when it dies quietly at 3am. Make carries all of that, and the scenarios keep running for months without me opening them.

The second reason is speed to first working version. Wiring a form to a sheet takes minutes, including the auth, because the connectors already exist. When the job is plumbing between two SaaS products, writing that plumbing myself is a worse use of an afternoon.

What I do not use it for is anything with real logic in it. Once a scenario grows routers, nested branches and five ways to fail, the canvas stops being clearer than code and the credit count climbs with every branch. That is the line where I move the job somewhere else.

Make AI Agents and MCP

Make's own framing of AI Agents is the clearest summary of where they fit: if it just needs doing, use automation, if it needs thinking, use an agent. A scenario is deterministic, the same path every run. An agent handles the part where the input is unstructured and the next step depends on what arrived.

Agents are available on all plans. Make's own AI provider works everywhere, and custom AI provider connections, OpenAI or Anthropic Claude among them, are available on paid plans. Credit usage differs depending on which provider you use, which is worth checking before you point an agent at a busy trigger.

There is also a Make MCP server. For anyone already running scenarios here, that is the cheapest way into agent work: the automations you built stay where they are and become callable actions for an AI client, instead of being rebuilt as tools somewhere else. If MCP is new to you, start with the MCP servers review.

Who Make is best for

Wiring SaaS apps without code. Small teams and solo operators who need two or three SaaS products to talk to each other and do not want a server to look after. It is also the right first tool for a non-developer: the modules teach the shape of automation, and nothing you learn there is wasted if you later move to something heavier.

When to skip Make

The logic fits in thirty lines of code. If the whole job is a loop, a couple of API calls and a condition, write the thirty lines. You get version control, tests and no per-step bill.

Skip it too when the scenario would be wide and busy. Because billing follows module actions, a long chain firing thousands of times a month gets expensive in a way a per-run tool does not. That is a pricing model choice rather than a flaw, and it is the main reason the next section exists. Ad platform work is another case where I go to the API directly rather than through modules, for the reasons in the Meta Ads API review.

How much does Make cost?

Plans as listed on the Make pricing page:

• Free, 0 dollars, 1,000 credits a month, 15 minute minimum scheduling interval
• Core, 9 dollars a month at the 10,000 credit tier
• Pro, 16 dollars a month, adds priority execution and full-text log search
• Teams, 29 dollars a month, adds team collaboration
• Enterprise, custom pricing

Paid plans drop the minimum scheduling interval to one minute, and annual billing saves 15 percent or more. Extra credits beyond your plan carry a surcharge, whether you buy them manually or let them auto-purchase, so a runaway scenario costs more per credit than a plan upgrade would. Check the Make pricing page for current numbers, the tiers have moved more than once.

The practical version: price the scenario, not the plan. Multiply modules by expected runs before you build. A four module scenario firing 250 times a month is 1,000 credits, which is the entire free plan.

How to build your first Make scenario

1. Take one job somebody is doing by hand today. A form entry retyped into a sheet is the classic first one.
2. Build it on the free plan. Two or three modules, run it once, read the execution log and see the data that actually arrived.
3. Add error handling before you add features. Decide what happens when the third module fails: retry, ignore, or alert you.
4. Count the modules and multiply by the runs you expect in a month. That is the credit bill, and it is easier to fix now than after the scenario has ten steps.
5. Keep anything that spends money or messages a real person behind a human approval step.

Make vs n8n: which one

The two land on the same shortlist and the billing unit separates them more sharply than the feature lists do.

Make bills per module action. Four modules, four credits, every run. n8n bills per workflow run, one execution whatever the node count. Short scenarios firing occasionally are cheap on Make and it will get you there faster. Wide workflows with many steps, or anything running on a tight schedule, tilt hard toward n8n.

The rest follows from that. Make is hosted only and has the bigger app catalogue, so it wins on time-to-first-integration. n8n can be self-hosted, runs code inside the workflow and exposes workflows over MCP in both directions, so it wins when the data has to stay on your infrastructure or the logic gets real.

I run both, for different jobs. Make for the plumbing that should never need me again, n8n when a workflow has to think or has to stay on my own server.

Make FAQ