n8n vs Make

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   n8n✓fullprobed8/10

   Direct probe confirms n8n serves a working llms.txt at https://docs.n8n.io/llms.txt (HTTP 200) with structured links to docs, which an agent can consume directly. missing for 10: no evidence of broader agent-oriented docs formats (e.g., per-page .md siblings or an agents.json manifest) or independent confirmation that agents actually consume it successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.n8n.io/llms.txt # n8n Docs ## Get started - [n8n Docs](https://docs.n8n.io/welcome.md): Get set u…”

   proof ↗⚑ flag

   Make✓fullprobed8/10

   Make hosts a live llms.txt at developers.make.com/llms.txt (HTTP 200, confirmed by probe) plus Markdown-formatted 'Make Skills' docs designed for AI assistants, directly supporting agent-oriented documentation consumption. missing for 10: confirmation that all doc subpages (not just the root) resolve as .md, and independent/third-party evidence of agents successfully using llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.make.com/llms.txt # Make Developer Hub ## Home - [Make Developer Hub](https://developers.ma…”
   • [claimed-docs] “Make Skills are Markdown files that help your assistant reliably perform Make-specific tasks, including building scenarios, configuring modu…”
   • [claimed-docs] “Make Skills are Markdown files that help your assistant reliably perform Make-specific tasks, including building scenarios, configuring modu…”
   • [probe] “PROBE docs-md: HTTP 200 at https://developers.make.com/api-documentation.md # Page Not Found The URL `api-documentation` does not exist. Th…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to n8n
   n8n✓fullprobed7/10

   n8n supports self-hosting via Docker/CLI and one-line install, has documented CLI configuration and command-line usage, an API, error-workflow handling for automated runs, and community reports of running it in production processing millions of workflows on small servers unattended — all consistent with headless/CI operation. missing for 10: no explicit CI/CD pipeline integration guide (e.g., GitHub Actions example) or dedicated 'headless mode' doc, and no independent benchmark of unattended reliability at scale beyond anecdotal community reports.

   • [claimed-docs] “Use the command line”
   • [probe] “official CLI documented at https://docs.n8n.io/deploy/host-n8n/configure-n8n/use-the-command-line”
   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [github] “curl -fsSL https://get.n8n.io | sh”
   • [claimed-docs] “n8n API”
   • [claimed-docs] “With an error workflow, you can control how n8n responds to a workflow execution failure.”
   • [community] “N8N is an amazing system. I use it daily and have seen incredible progress made consistently over the past few years. Currently my team use …”
   • [community] “We're using n8n in production for a month now and are pretty happy with it. Easily extendable and new integrations can be built easily.”

   proof ↗⚑ flag

   Make~partialprobed6/10

   Make exposes a REST API (with auth/scopes) and webhooks that let external systems or CI pipelines trigger, schedule, and manage scenarios without using the UI, which supports headless/automated invocation. However, there is no evidence of an official CLI, containerized runner, or CI-specific integration guide (e.g., GitHub Actions), and the openapi probe returned 404s, suggesting weaker machine-readable API tooling. Missing for 10: dedicated CLI or CI/CD integration docs, confirmed OpenAPI spec, and hands-on evidence of running scenarios in a pipeline.

   • [claimed-docs] “All requests to the Make API require authentication with the user authentication token with the relevant scopes enabled.”
   • [claimed-docs] “The Make API follows the REST API design. Make API is organized into resource-oriented URLs”
   • [claimed-docs] “custom webhooks allow you to create a url to which you can send any data”
   • [claimed-docs] “webhooks create a url that you can call from an external app or service, or from another use webhooks to trigger the execution”
   • [claimed-docs] “If you don't want to run your immediately after a webhook receives data, you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “you can schedule your to process all webhook requests periodically”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.make.com/openapi.json, https://developers.make.com/swagger.json, https://develope…”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round to n8n
   n8n✓fullprobed8/10

   n8n ships a documented built-in MCP Client node (n8n-nodes-langchain.mcpclient) that lets a workflow/agent connect to external MCP servers and use their tools, alongside an MCP Server Trigger for the reverse role, confirming first-party MCP client support. This is corroborated by an official docs page and probe confirmation. Missing for 10: independent hands-on community reports specifically validating the MCP Client node's tool-use in practice (community evidence is general n8n sentiment, not MCP-specific).

   • [claimed-docs] “MCP Client”
   • [claimed-docs] “MCP Server Trigger”
   • [probe] “official MCP server documented at https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger”

   proof ↗⚑ flag

   Make—none0/10

   All evidence describes Make exposing its own scenarios as an MCP server to external AI clients (Claude, ChatGPT), the reverse of this story's requirement that Make itself act as an MCP client consuming external MCP servers' tools. No documentation shows Make importing or calling third-party MCP servers as tool providers within its scenarios/agents.

   • [claimed-docs] “Turns your **active** and **on-demand** scenarios into callable tools for AI”
   • [claimed-docs] “AI systems like Claude and ChatGPT act as MCP clients of Make MCP server. The server provides them access to **scenario run** and **manageme…”
   • [claimed-docs] “AI systems like Claude and ChatGPT act as MCP clients of Make MCP server.”
   • [claimed-docs] “Make MCP server allows AI systems, such as large language models (LLMs), to run scenarios and manage the contents of your Make account.”
   • [claimed-docs] “learn about agentic automation with the make ai agents app”

   proof ↗⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Make
   n8n✓fullprobed7/10

   n8n ships an official MCP Server Trigger node (n8n-nodes-langchain.mcpTrigger) that lets external AI agents connect to n8n workflows via MCP, confirmed by docs and a probe hit; it also has a complementary MCP Client node for consuming other MCP servers. Missing for 10: independent/hands-on community confirmation of the MCP server trigger working in practice, and more detail on setup/auth specifics beyond the doc page title.

   • [claimed-docs] “MCP Server Trigger”
   • [probe] “official MCP server documented at https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger”
   • [claimed-docs] “MCP Client”

   proof ↗⚑ flag

   Make✓fullprobed8/10

   Make documents an official MCP server that turns scenarios into callable tools for AI systems like Claude/ChatGPT, exposing scenario run and management capabilities, plus Make Skills to help agents connect. Missing for 10: independent/hands-on third-party corroboration and details on auth scopes specific to MCP server usage.

   • [claimed-docs] “Turns your **active** and **on-demand** scenarios into callable tools for AI”
   • [claimed-docs] “AI systems like Claude and ChatGPT act as MCP clients of Make MCP server. The server provides them access to **scenario run** and **manageme…”
   • [claimed-docs] “AI systems like Claude and ChatGPT act as MCP clients of Make MCP server.”
   • [claimed-docs] “Make MCP server allows AI systems, such as large language models (LLMs), to run scenarios and manage the contents of your Make account.”
   • [claimed-docs] “Make Skills are Markdown files that help your assistant reliably perform Make-specific tasks, including building scenarios, configuring modu…”
   • [probe] “official MCP server documented at https://developers.make.com/mcp-server”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to n8n
   n8n~partialprobed6/10

   n8n documents an official command-line interface for configuring and managing self-hosted instances (n8n-docs-17, n8n-probe-4), which is a genuine first-party CLI. However, this CLI is oriented toward deployment/configuration tasks rather than AI-native agentic workflows (e.g., no evidence of CLI-driven workflow creation/execution for AI agents, no scripting API for agent orchestration via CLI). Missing for 10: evidence of AI-native/agent-oriented CLI use cases, independent hands-on corroboration of the CLI, and any agent-facing CLI commands beyond basic server configuration.

   • [claimed-docs] “Use the command line”
   • [probe] “official CLI documented at https://docs.n8n.io/deploy/host-n8n/configure-n8n/use-the-command-line”

   proof ↗⚑ flag

   Make—none0/10

   The evidence pack documents Make's REST API, MCP server, webhooks, and Skills, but contains no mention of an official command-line interface (CLI) tool for Make. Since automation platforms could plausibly ship a CLI, this axis applies, but no evidence supports it being delivered.

   ⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round to Make
   n8n~partialprobed6/10

   n8n documents a dedicated public REST API (n8n-docs-16 'n8n API') for programmatic control, which supports AI-native/agentic driving of the product beyond the UI. However, evidence is limited to a single doc title with no detail on endpoints/auth, and probes for an OpenAPI/swagger spec at expected paths all 404'd, weakening confidence in completeness or discoverability. Missing for 10: detailed API reference content, machine-readable OpenAPI spec, and independent/hands-on developer confirmation of using the API.

   • [claimed-docs] “n8n API”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.n8n.io/openapi.json, https://docs.n8n.io/swagger.json, https://docs.n8n.io/api/openapi.…”

   proof ↗⚑ flag

   Make✓fullprobed8/10

   Make documents a public REST API (resource-oriented URLs, token auth, troubleshooting section) plus a first-party MCP server exposing scenario run/management as callable tools, enabling AI-native driving of the product beyond just the raw API. Missing for 10: a working OpenAPI/swagger spec (probe found 404s) and independent hands-on corroboration of the API's completeness/reliability.

   • [claimed-docs] “All requests to the Make API require authentication with the user authentication token with the relevant scopes enabled.”
   • [claimed-docs] “The Make API follows the REST API design. Make API is organized into resource-oriented URLs”
   • [claimed-docs] “If you are experiencing issues with the Make API, go to the Troubleshooting section for tips about what could go wrong and how to fix it.”
   • [claimed-docs] “Turns your **active** and **on-demand** scenarios into callable tools for AI”
   • [claimed-docs] “AI systems like Claude and ChatGPT act as MCP clients of Make MCP server. The server provides them access to **scenario run** and **manageme…”
   • [claimed-docs] “Make MCP server allows AI systems, such as large language models (LLMs), to run scenarios and manage the contents of your Make account.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.make.com/openapi.json, https://developers.make.com/swagger.json, https://develope…”
   • [probe] “official MCP server documented at https://developers.make.com/mcp-server”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Make
   n8n~partialclaimed4/10

   n8n exposes a credentials system for per-integration secrets and a general n8n API, plus role-based access control and audit trails per the GitHub description, which are building blocks for limiting what an agent can access. However there is no evidence of a mechanism to issue scoped or least-privilege API keys/credentials specifically for an AI agent's use (e.g., read-only, node-restricted, or agent-specific tokens). Missing for 10: documentation of scoped API key creation, granular per-agent credential permissions, and independent confirmation that credential scoping actually restricts agent tool access.

   • [claimed-docs] “Credentials | Nodes | n8n Docs”
   • [claimed-docs] “n8n API”
   • [github] “Self-host or deploy securely with role-based access, audit trails, and support for sensitive data”
   • [claimed-docs] “Admin roles”

   proof ↗⚑ flag

   Make~partialclaimed5/10

   Make API tokens support 'relevant scopes enabled' for authentication, indicating some scoped credential capability, and MCP server access can be scoped to specific scenarios/tools rather than full account access. However there's no documentation of granular least-privilege scope definitions, no scope list, no per-agent credential issuance workflow, and no independent verification of enforcement. Missing for 10: a documented list of available API scopes, evidence of fine-grained least-privilege controls (e.g., read-only vs write, resource-level restrictions), and independent/hands-on confirmation that scoped tokens actually restrict agent access as claimed.

   • [claimed-docs] “All requests to the Make API require authentication with the user authentication token with the relevant scopes enabled.”
   • [claimed-docs] “The Make API follows the REST API design. Make API is organized into resource-oriented URLs”
   • [claimed-docs] “Make MCP server allows AI systems, such as large language models (LLMs), to run scenarios and manage the contents of your Make account.”
   • [claimed-docs] “View and modify scenarios and their related entities (e.g., connections, webhooks, and data stores)”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to n8n
   n8n~partialclaimed3/10

   n8n documents a public REST API (n8n-docs-16) that developers could build against, but there is no evidence of dedicated, officially maintained SDK packages (e.g., Python/Node client libraries) or SDK-specific quickstart docs — the API reference is the only artifact resembling programmatic access. missing for 10: official language SDKs (Python/JS/Go), SDK reference docs, SDK usage examples, and independent confirmation of SDK adoption.

   • [claimed-docs] “n8n API”

   proof ↗⚑ flag

   Make—none0/10

   Evidence shows a REST API and an MCP server, but no official client SDKs (Python/JS/etc.) or OpenAPI spec are documented—probes for openapi/swagger endpoints returned 404, indicating no formal SDK-generation artifact. The API docs describe raw REST endpoints and auth tokens, not packaged SDK libraries.

   • [claimed-docs] “All requests to the Make API require authentication with the user authentication token with the relevant scopes enabled.”
   • [claimed-docs] “The Make API follows the REST API design. Make API is organized into resource-oriented URLs”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.make.com/openapi.json, https://developers.make.com/swagger.json, https://develope…”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to n8n
   n8n✓fullprobed8/10

   n8n has a first-party Webhook trigger node (n8n-docs-21) that lets workflows (including AI agents) subscribe to and react to incoming HTTP events, plus an MCP Server Trigger (n8n-docs-19, n8n-probe-3) that exposes workflows as callable/event-driven endpoints for AI agent ecosystems. Community evidence corroborates real-world use of webhook-initiated workflows in production (n8n-comm-18). Missing for 10: independent hands-on verification specifically of webhook subscription reliability/latency and richer documentation on webhook authentication/security nuances.

   • [claimed-docs] “Webhook | Nodes | n8n Docs”
   • [claimed-docs] “MCP Server Trigger”
   • [probe] “official MCP server documented at https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”

   proof ↗⚑ flag

   Make~partialclaimed6/10

   Make's custom webhooks let a scenario expose a URL that receives events from external systems and trigger scenario runs, effectively letting a user 'subscribe' to external events via webhook (make-docs-5, make-docs-15, make-docs-25), with queuing/scheduling options (make-docs-6, make-docs-21). However, this is a general automation feature, not something exposed or documented specifically for AI-native/agentic consumption (e.g., no MCP tool or agent-specific API for creating/managing webhook subscriptions is shown). Missing for 10: evidence of webhook subscription management being agent-callable via MCP or API, and any outbound event-notification (pub/sub) webhook mechanism for external AI systems.

   • [claimed-docs] “custom webhooks allow you to create a url to which you can send any data”
   • [claimed-docs] “webhooks create a url that you can call from an external app or service, or from another use webhooks to trigger the execution”
   • [claimed-docs] “webhooks create a url that you can call from an external app or service, or from another use webhooks to trigger the execution of”
   • [claimed-docs] “If you don't want to run your immediately after a webhook receives data, you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “the whole queue is then processed every time your schedule criteria are met”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to n8n
   n8n~partialclaimed6/10

   n8n's AI agent nodes and templates explicitly support generating insights from data (e.g. 'Sales can Generate customer insights from reviews', 'Sec Ops can Enrich security incident tickets', 'What agents do' docs) by connecting LLMs to a user's own data sources. However this is delivered via user-built workflows rather than a native, out-of-the-box insights/suggestions feature, and there's no independent/hands-on evidence confirming this specific use case works well in practice. Missing for 10: first-party deep documentation of an insights-generation workflow end-to-end, and community/hands-on corroboration of AI-generated insights specifically (only generic AI-workflow templates are cited).

   • [claimed-docs] “Sales can Generate customer insights from reviews”
   • [claimed-docs] “Sec Ops can Enrich security incident tickets”
   • [claimed-docs] “What agents do”
   • [github] “Build and operationalize AI workflows and multi-step agents using your own data, models, and tools”
   • [github] “Connect to OpenAI, Anthropic, Google, or open-source models and switch providers without changing your architecture”

   proof ↗⚑ flag

   Make—none0/10

   Evidence shows Make's AI Agents app and MCP server let external AI systems build/run automations and manage scenarios, but there is no evidence of a feature that surfaces AI-generated insights or suggestions from a user's own data inside the product UI.

   • [claimed-docs] “learn about agentic automation with the make ai agents app”
   • [claimed-docs] “Make MCP server allows AI systems, such as large language models (LLMs), to run scenarios and manage the contents of your Make account.”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   n8n✓fullcommunity8/10

   n8n's core product is workflow automation triggered by webhooks/schedules that execute unattended, with error-handling workflows, execution history/search, and self-hosted/cloud deployment for always-on background operation; community evidence corroborates long-running, hands-off use (processing millions of workflows on a small server for years, following subreddits and sending notifications automatically, running in production for months). Missing for 10: an explicit dedicated schedule-trigger doc citation and independent uptime/reliability benchmarking for long-running autonomous agents.

   • [claimed-docs] “With an error workflow, you can control how n8n responds to a workflow execution failure.”
   • [claimed-docs] “Webhook | Nodes | n8n Docs”
   • [claimed-docs] “Execution search”
   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [community] “N8N is an amazing system. I use it daily and have seen incredible progress made consistently over the past few years. Currently my team use …”
   • [community] “I use it to follow subreddits, scrape posts, analyze based on arbitrary criteria, note the findings in a spreadsheet, then send a notificati…”
   • [community] “We're using n8n in production for a month now and are pretty happy with it. Easily extendable and new integrations can be built easily.”
   • [claimed-docs] “What agents do”

   proof ↗⚑ flag

   Make✓fullclaimed8/10

   Make scenarios are core automations that run autonomously on triggers (webhooks, schedules) in the background without human intervention, with error handling and history/monitoring built in, and can even be exposed as callable tools via MCP for AI orchestration. missing for 10: independent/hands-on evidence of long-running autonomous scenarios at scale, and no third-party corroboration beyond vendor docs.

   • [claimed-docs] “custom webhooks allow you to create a url to which you can send any data”
   • [claimed-docs] “If you don't want to run your immediately after a webhook receives data, you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “webhooks create a url that you can call from an external app or service, or from another use webhooks to trigger the execution”
   • [claimed-docs] “you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “the whole queue is then processed every time your schedule criteria are met”
   • [claimed-docs] “this page helps users navigate errors, diagnose and resolve issues in by providing detailed information on common errors and warnings, error…”
   • [claimed-docs] “scenario history”
   • [claimed-docs] “Turns your **active** and **on-demand** scenarios into callable tools for AI”
   • [claimed-docs] “Make MCP server allows AI systems, such as large language models (LLMs), to run scenarios and manage the contents of your Make account.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Make
   n8n—none0/10

   The evidence shows n8n lets users build AI agent workflows (nodes, LangChain integration, model connections) but none of it describes a built-in AI assistant inside the n8n product itself that a user can delegate tasks to (e.g., an in-app copilot for building/debugging workflows). All AI-agent references describe automations the user builds, not an assistant serving the user.

   ⚑ flag

   Make~partialclaimed3/10

   Make documents a 'Make AI Agents' app for 'agentic automation' inside the platform, suggesting a built-in AI agent/assistant capability, but the evidence is a single glancing mention with no detail on how tasks are delegated or what the assistant can do. Missing for 10: detailed docs on the AI Agents app's task-delegation UX, concrete examples of use, and independent/hands-on corroboration of its capabilities.

   • [claimed-docs] “learn about agentic automation with the make ai agents app”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Make
   n8n—none0/10

   The evidence shows n8n lets users build AI agents and convert natural language into API calls *as workflow outputs*, but there is no evidence of a natural-language interface for operating n8n itself (e.g., a chat-to-build-workflow assistant or NL command console). missing for 10: evidence of a prompt-driven workflow builder or NL command interface for controlling n8n's canvas/actions.

   • [claimed-docs] “What agents do”
   • [claimed-docs] “Dev Ops can Convert natural language into API calls”
   • [claimed-docs] “Build visually, go deep with code, connect to anything.”

   proof ↗⚑ flag

   Make~partialprobed6/10

   Make ships an official MCP server and 'Make AI Agents' app that let LLMs (Claude, ChatGPT) run and manage scenarios via natural-language tool calls, plus 'Make Skills' markdown files to guide assistants — this is real agentic/NL operation support. However, this capability is mediated entirely through external AI clients rather than a built-in natural-language command interface in Make itself, and there is no independent/hands-on corroboration of reliability. Missing for 10: evidence of a native in-product NL command bar/assistant, and third-party/hands-on validation of the MCP-driven workflow.

   • [claimed-docs] “Turns your **active** and **on-demand** scenarios into callable tools for AI”
   • [claimed-docs] “AI systems like Claude and ChatGPT act as MCP clients of Make MCP server. The server provides them access to **scenario run** and **manageme…”
   • [claimed-docs] “learn about agentic automation with the make ai agents app”
   • [claimed-docs] “Make MCP server allows AI systems, such as large language models (LLMs), to run scenarios and manage the contents of your Make account.”
   • [claimed-docs] “Make Skills are Markdown files that help your assistant reliably perform Make-specific tasks, including building scenarios, configuring modu…”
   • [probe] “official MCP server documented at https://developers.make.com/mcp-server”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   n8n—none0/10

   n8n documents a REST API (n8n-docs-16) but there is no evidence of an interactive, runnable API reference (e.g., Swagger/OpenAPI explorer); a direct probe for OpenAPI/Swagger specs returned 404 on all candidate paths, indicating no such interactive reference is exposed.

   • [claimed-docs] “n8n API”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.n8n.io/openapi.json, https://docs.n8n.io/swagger.json, https://docs.n8n.io/api/openapi.…”

   proof ↗⚑ flag

   Make—none0/10

   Make provides REST API documentation describing resource-oriented endpoints and authentication (make-docs-1, make-docs-11, make-docs-23), but no evidence shows an interactive reference with runnable/try-it examples; probes for OpenAPI/Swagger specs and even the docs page in machine-readable form returned 404s (make-probe-2, make-probe-3), suggesting no such interactive tooling exists.

   • [claimed-docs] “All requests to the Make API require authentication with the user authentication token with the relevant scopes enabled.”
   • [claimed-docs] “The Make API follows the REST API design. Make API is organized into resource-oriented URLs”
   • [claimed-docs] “If you are experiencing issues with the Make API, go to the Troubleshooting section for tips about what could go wrong and how to fix it.”
   • [probe] “PROBE docs-md: HTTP 200 at https://developers.make.com/api-documentation.md # Page Not Found The URL `api-documentation` does not exist. Th…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.make.com/openapi.json, https://developers.make.com/swagger.json, https://develope…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   n8n—none0/10

   While n8n documents a REST API (n8n-docs-16), the evidence pack contains an explicit probe showing all standard OpenAPI/Swagger spec paths returning 404 (n8n-probe-2), and no other citation shows a downloadable machine-readable spec for n8n's API. No evidence of an OpenAPI/Swagger JSON export exists.

   • [claimed-docs] “n8n API”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.n8n.io/openapi.json, https://docs.n8n.io/swagger.json, https://docs.n8n.io/api/openapi.…”

   proof ↗⚑ flag

   Make—none0/10

   Make documents its REST API but explicit probes for OpenAPI/swagger specs at standard paths all returned 404, and no downloadable machine-readable spec is referenced anywhere in the docs pack.

   • [claimed-docs] “The Make API follows the REST API design. Make API is organized into resource-oriented URLs”
   • [probe] “PROBE docs-md: HTTP 200 at https://developers.make.com/api-documentation.md # Page Not Found The URL `api-documentation` does not exist. Th…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.make.com/openapi.json, https://developers.make.com/swagger.json, https://develope…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to n8n
   n8n~partialclaimed3/10

   n8n's source-control/environments feature (n8n-docs-22, n8n-docs-7) implies the ability to maintain separate dev/staging/production n8n instances synced via Git, which could support sandbox testing without touching production data, but the evidence pack gives only page titles with no detail on how isolation, test data, or non-production execution actually works. missing for 10: explicit documentation of a sandbox/staging execution mode, test-vs-production webhook isolation, or first-party guidance on testing without affecting live data.

   • [claimed-docs] “Push and pull changes”
   • [claimed-docs] “Version control using Git”

   proof ↗⚑ flag

   Make—none0/10

   No evidence of a sandbox environment, staging account, or test/production data separation for Make; the docs cover webhooks, scenarios, error handling, and MCP server but nothing about isolating test runs from production data.

   ⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   n8n—none0/10

   n8n publishes an API (n8n-docs-16) but the evidence pack contains no documentation of API versioning scheme or a deprecation policy, and a probe for an OpenAPI spec returned 404s across all candidate paths (n8n-probe-2), indicating no discoverable versioned/spec-documented API contract.

   • [claimed-docs] “n8n API”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.n8n.io/openapi.json, https://docs.n8n.io/swagger.json, https://docs.n8n.io/api/openapi.…”

   proof ↗⚑ flag

   Make—none0/10

   The evidence shows Make has a REST API and MCP server documentation, but nowhere is there mention of API versioning scheme, version numbers, or a documented deprecation policy for breaking changes. Probes even show broken/missing OpenAPI spec links, further suggesting no formal versioning artifact is exposed.

   • [claimed-docs] “The Make API follows the REST API design. Make API is organized into resource-oriented URLs”
   • [claimed-docs] “If you are experiencing issues with the Make API, go to the Troubleshooting section for tips about what could go wrong and how to fix it.”
   • [probe] “PROBE docs-md: HTTP 200 at https://developers.make.com/api-documentation.md # Page Not Found The URL `api-documentation` does not exist. Th…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.make.com/openapi.json, https://developers.make.com/swagger.json, https://develope…”

   proof ↗⚑ flag

Agent integration

1. ai-native userHave an agent create, update, and activate a workflow programmatically through the public API

   weight 2 · round to Make
   n8n~partialclaimed3/10

   n8n's docs reference a dedicated 'n8n API' page confirming a public API exists, which is consistent with programmatic workflow management, but the evidence pack gives no detail on specific create/update/activate endpoints, authentication, or examples of an agent invoking them. Missing for 10: documented API endpoints for workflow create/update/activate, example agent-driven API calls, and independent/community confirmation the API works as described.

   • [claimed-docs] “n8n API”

   proof ↗⚑ flag

   Make~partialprobed5/10

   Make's public REST API is documented as resource-oriented and requires token auth, and the MCP server explicitly allows AI systems to view and modify scenarios, run them, and manage account contents, implying create/update/activate capabilities. However, no evidence explicitly documents an API endpoint or example for creating a new scenario or toggling activation state, and the docs snippets are largely generic descriptions rather than concrete workflow-lifecycle examples. missing for 10: explicit API endpoint documentation for scenario creation, explicit 'activate' endpoint/example, and independent confirmation of programmatic activation.

   • [claimed-docs] “The Make API follows the REST API design. Make API is organized into resource-oriented URLs”
   • [claimed-docs] “View and modify scenarios and their related entities (e.g., connections, webhooks, and data stores)”
   • [claimed-docs] “Make MCP server allows AI systems, such as large language models (LLMs), to run scenarios and manage the contents of your Make account.”
   • [claimed-docs] “All requests to the Make API require authentication with the user authentication token with the relevant scopes enabled.”
   • [probe] “official MCP server documented at https://developers.make.com/mcp-server”

   proof ↗⚑ flag

2. ai-native userExpose my workflows or connected app actions as MCP tools that an external agent can call

   weight 3 · round drawn
   n8n✓fullprobed8/10

   n8n ships a documented MCP Server Trigger node that exposes a workflow as an MCP server tool callable by external agents, alongside a separate MCP Client node for consuming external MCP servers — directly matching the story of exposing workflows/app actions as MCP tools. This is corroborated by a probe confirming the docs page exists, but there's no independent/hands-on community report validating real-world use of the MCP Server Trigger specifically. Missing for 10: independent/community corroboration of the MCP server trigger in practice, and more detail on auth/security when exposing tools externally.

   • [claimed-docs] “MCP Server Trigger”
   • [claimed-docs] “MCP Client”
   • [probe] “official MCP server documented at https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger”

   proof ↗⚑ flag

   Make✓fullprobed8/10

   Make offers an official MCP server that turns active/on-demand scenarios into callable tools for AI agents like Claude/ChatGPT, exposing scenario run and management capabilities via a documented protocol; scenarios can connect to third-party app actions, making them exposable as tools. Missing for 10: independent hands-on validation of the MCP server beyond first-party docs and more detail on granular scoping/security of exposed tools.

   • [claimed-docs] “Turns your **active** and **on-demand** scenarios into callable tools for AI”
   • [claimed-docs] “AI systems like Claude and ChatGPT act as MCP clients of Make MCP server. The server provides them access to **scenario run** and **manageme…”
   • [claimed-docs] “AI systems like Claude and ChatGPT act as MCP clients of Make MCP server.”
   • [claimed-docs] “Turns your active and on-demand scenarios into callable tools for AI”
   • [claimed-docs] “Make MCP server allows AI systems, such as large language models (LLMs), to run scenarios and manage the contents of your Make account.”
   • [probe] “official MCP server documented at https://developers.make.com/mcp-server”

   proof ↗⚑ flag

Ai authoring

1. ai-native userGenerate or edit a workflow from a natural-language prompt

   weight 2 · round to Make
   n8n—none0/10

   The evidence pack covers n8n's visual/code building, AI agent nodes, MCP support, and integrations, but contains no documentation of a natural-language-to-workflow generation or editing feature (e.g., an 'AI workflow builder' or prompt-based canvas editing). n8n-docs-26 only describes a workflow that converts natural language into API calls as a use case, not n8n generating/editing the workflow itself from a prompt.

   • [claimed-docs] “Dev Ops can Convert natural language into API calls”
   • [claimed-docs] “What agents do”
   • [claimed-docs] “Build visually, go deep with code, connect to anything.”

   proof ↗⚑ flag

   Make~partialclaimed5/10

   Make's docs show 'Make Skills' (Markdown files) enabling an AI assistant to build and configure scenarios via the MCP server, and the MCP server lets AI systems like Claude/ChatGPT manage scenario contents — implying prompt-driven workflow creation/editing through external AI clients. However, this is an indirect, third-party-assistant-mediated path rather than a documented native in-product 'type a prompt, get a workflow' feature, and there's no hands-on or independent verification of it working. Missing for 10: a native first-party natural-language-to-workflow builder in the Make UI, concrete examples/screenshots of prompt-generated scenarios, and independent hands-on corroboration.

   • [claimed-docs] “Make Skills are Markdown files that help your assistant reliably perform Make-specific tasks, including building scenarios, configuring modu…”
   • [claimed-docs] “Make Skills are Markdown files that help your assistant reliably perform Make-specific tasks, including building scenarios, configuring modu…”
   • [claimed-docs] “Make MCP server allows AI systems, such as large language models (LLMs), to run scenarios and manage the contents of your Make account.”
   • [claimed-docs] “learn about agentic automation with the make ai agents app”

   proof ↗⚑ flag

Ai steps

1. ai-native userAdd AI agent or LLM steps inside a workflow, with model choice and tool use

   weight 3 · round to n8n
   n8n✓fullcommunity8/10

   n8n has dedicated AI agent building blocks (docs on 'What agents do', LangChain-based nodes, MCP client/trigger), explicit model choice across OpenAI/Anthropic/Google/open-source providers, and tool use via integrations/credentials plus code nodes for advanced logic. This is corroborated by both first-party docs/GitHub claims and independent community use of n8n for AI workflows. Missing for 10: deeper hands-on independent verification of multi-agent orchestration quality and tool-calling reliability beyond marketing/docs claims.

   • [claimed-docs] “What agents do”
   • [github] “Connect to OpenAI, Anthropic, Google, or open-source models and switch providers without changing your architecture”
   • [github] “Model Flexibility, No Lock-In: Connect to OpenAI, Anthropic, Google, or open-source models and switch providers without changing your archit…”
   • [github] “Build and operationalize AI workflows and multi-step agents using your own data, models, and tools”
   • [claimed-docs] “MCP Server Trigger”
   • [claimed-docs] “MCP Client”
   • [claimed-docs] “OpenAI, the creator of ChatGPT, offers a range of powerful models including GPT-3, DALL·E, and Whisper. Leverage these models to build AI-po…”
   • [claimed-docs] “The Anthropic app, built by the creators of Claude, is an AI chat interface that allows users to interact with Claude models for tasks like …”
   • [claimed-docs] “Google Gemini is an AI assistant app that answers questions, summarizes content, and generates text, images, and short videos. It supports v…”
   • [community] “I use it to follow subreddits, scrape posts, analyze based on arbitrary criteria, note the findings in a spreadsheet, then send a notificati…”

   proof ↗⚑ flag

   Make~partialclaimed5/10

   Make has a dedicated 'AI Agents' app (make-docs-9) for agentic automation within workflows, implying model choice and tool use, but the evidence pack lacks first-party documentation detailing how to configure model selection or tool/function definitions within an agent step — most evidence instead focuses on the MCP server (which exposes Make scenarios as tools to external AI clients like Claude/ChatGPT, the reverse direction). missing for 10: detailed docs on adding an AI/LLM step inside a scenario, configuring model provider/choice, and defining tool use within that step, plus independent/hands-on confirmation of this workflow.

   • [claimed-docs] “learn about agentic automation with the make ai agents app”
   • [claimed-docs] “Turns your **active** and **on-demand** scenarios into callable tools for AI”
   • [claimed-docs] “Make MCP server allows AI systems, such as large language models (LLMs), to run scenarios and manage the contents of your Make account.”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Make
   n8n~partialcommunity4/10

   n8n's workflow engine inherently processes arrays of items and community evidence shows real-world use at high volume ("processing millions of workflows each year on a very small server"), implying capacity for bulk-scale automation, but the evidence pack contains no explicit documentation of batch/loop/bulk-item processing features (e.g., Split-in-Batches, item-array iteration) as a distinct capability. Missing for 10: explicit docs on batch-processing nodes or bulk-item iteration, first-party guidance on handling large item sets, and independent confirmation of bulk-operation reliability at scale.

   • [community] “N8N is an amazing system. I use it daily and have seen incredible progress made consistently over the past few years. Currently my team use …”
   • [community] “I use it to follow subreddits, scrape posts, analyze based on arbitrary criteria, note the findings in a spreadsheet, then send a notificati…”
   • [claimed-docs] “Build visually, go deep with code, connect to anything.”

   proof ↗⚑ flag

   Make~partialclaimed5/10

   Make's webhook queue processing and API/data-store functions imply some capacity for handling batches of items via scenarios, and the REST API with scoped tokens could be scripted for bulk actions, but no evidence documents a native bulk-operation feature (e.g., batch endpoints, bulk item processing UI, or iterator-based bulk automation) for AI-native use. missing for 10: explicit documentation of batch/bulk API endpoints or iterator modules for processing many items in one call, evidence of AI agents invoking bulk operations via MCP server, and any hands-on confirmation of bulk throughput/performance.

   • [claimed-docs] “custom webhooks allow you to create a url to which you can send any data”
   • [claimed-docs] “If you don't want to run your immediately after a webhook receives data, you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “the whole queue is then processed every time your schedule criteria are met”
   • [claimed-docs] “transform and format data using our range of functions”
   • [claimed-docs] “The Make API follows the REST API design. Make API is organized into resource-oriented URLs”
   • [claimed-docs] “Make MCP server allows AI systems, such as large language models (LLMs), to run scenarios and manage the contents of your Make account.”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to n8n
   n8n✓fullcommunity8/10

   n8n natively supports event-based triggers (Webhook, MCP Server Trigger, scheduled triggers) that fire workflows/actions automatically, plus error-handling workflows for reacting to execution events, directly matching rule-based automation on events. Community evidence corroborates real production use for automated multi-step workflows triggered by webhooks/schedules. missing for 10: no independent benchmark of complex conditional 'if X then Y' rule engines beyond trigger nodes, and no deeper docs on rule-composition beyond triggers/IF nodes.

   • [claimed-docs] “Webhook | Nodes | n8n Docs”
   • [claimed-docs] “MCP Server Trigger”
   • [claimed-docs] “With an error workflow, you can control how n8n responds to a workflow execution failure.”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”
   • [community] “I use it to follow subreddits, scrape posts, analyze based on arbitrary criteria, note the findings in a spreadsheet, then send a notificati…”

   proof ↗⚑ flag

   Make✓fullclaimed7/10

   Make's core scenario model is built on trigger-action automation: webhooks let users create URLs that trigger scenario execution on external events, schedules can batch-process queued events, and error handlers manage automated fault-response actions. This directly matches the story of defining rules that fire actions on events, though evidence is entirely first-party docs. Missing for 10: independent/hands-on verification and concrete examples of complex conditional rule logic beyond webhooks/schedules.

   • [claimed-docs] “custom webhooks allow you to create a url to which you can send any data”
   • [claimed-docs] “If you don't want to run your immediately after a webhook receives data, you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “webhooks create a url that you can call from an external app or service, or from another use webhooks to trigger the execution”
   • [claimed-docs] “you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “the whole queue is then processed every time your schedule criteria are met”
   • [claimed-docs] “webhooks create a url that you can call from an external app or service, or from another use webhooks to trigger the execution of”
   • [claimed-docs] “this page helps users navigate errors, diagnose and resolve issues in by providing detailed information on common errors and warnings, error…”
   • [claimed-docs] “diagnose and resolve issues in by providing detailed information on common errors and warnings, error handlers”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Make
   n8n~partialcommunity5/10

   The pack lacks any first-party documentation citation for a dedicated Schedule/Cron trigger node, but a hands-on community report confirms real production use of n8n for 'scheduled and webhook-initiated tasks' (n8n-comm-18), indicating the capability exists and works. Missing for 10: official docs reference to the Schedule Trigger/Cron node, details on interval/cron expression configuration, and independent verification beyond a single community anecdote.

   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”

   proof ↗⚑ flag

   Make✓fullclaimed7/10

   Make's docs confirm native scenario scheduling ('schedule a scenario') and webhook queues that can be processed on a periodic schedule, directly supporting recurring automated workflows. Missing for 10: independent/hands-on confirmation of scheduling reliability, details on schedule granularity/frequency options, and any AI-specific scheduling interface beyond generic scenario scheduling.

   • [claimed-docs] “schedule a scenario docid 8rwfo krohjlepg4qhx3 clone a scenario docid\ c8f35kwpicyg1az5vlgehdelete a scenario”
   • [claimed-docs] “If you don't want to run your immediately after a webhook receives data, you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “the whole queue is then processed every time your schedule criteria are met”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to n8n
   n8n~partialcommunity6/10

   n8n documents Git-based source control ("Version control using Git", "Push and pull changes") and execution history/search that lets users review past runs (n8n-docs-7, n8n-docs-22, n8n-docs-9), and community evidence confirms execution history is retained for debugging (n8n-comm-8). However, Git-based version control appears to be a paid/enterprise pricing-page feature rather than a built-in community capability, and there is no explicit documentation of a one-click 'rollback' mechanism for workflows beyond manually reverting via Git. Missing for 10: explicit rollback/restore workflow feature, confirmation that version control is available outside paid tiers, and independent hands-on confirmation of the review/rollback workflow.

   • [claimed-docs] “Version control using Git”
   • [claimed-docs] “Push and pull changes”
   • [claimed-docs] “Execution search”
   • [community] “I have written some stuff with n8n and I think it is better than most no code platforms because it's debuggable. It keeps all the historical…”

   proof ↗⚑ flag

   Make~partialclaimed5/10

   Make documents 'scenario history' and the ability to 'clone a scenario', which suggest some versioning/backup capability, but there is no explicit documentation of a review/diff UI or a true rollback mechanism restoring a prior version. missing for 10: explicit rollback/revert feature docs, version diff/review UI, and independent confirmation that history can restore a scenario to an earlier state.

   • [claimed-docs] “clone a scenario”
   • [claimed-docs] “scenario history”
   • [claimed-docs] “schedule a scenario docid 8rwfo krohjlepg4qhx3 clone a scenario docid\ c8f35kwpicyg1az5vlgehdelete a scenario”

   proof ↗⚑ flag

Code steps

1. developerDrop into real code (JavaScript or Python) as a step inside a workflow

   weight 3 · round to n8n
   n8n✓fullcommunity8/10

   n8n explicitly ships a Code node supporting JavaScript and Python (with npm packages) as a workflow step, confirmed by both vendor docs/GitHub (n8n-gh-1, n8n-gh-6, n8n-docs-1) and independent hands-on community feedback confirming custom JS/Python code blocks exist (n8n-comm-6). Missing for 10: deeper first-party documentation of the Code node itself (execution modes, sandboxing) and resolution of the community-noted limitation on importing external libraries.

   • [github] “Combine visual building with JavaScript, Python, and npm packages for advanced AI workflows”
   • [github] “Code When You Need It: Combine visual building with JavaScript, Python, and npm packages for advanced AI workflows”
   • [claimed-docs] “Build visually, go deep with code, connect to anything.”
   • [claimed-docs] “Build visually, go deep with code, connect to anything. Every step of your agents' reasoning, traceable on the canvas.”
   • [community] “N8n looks quite polished and seems primarily concerned about connecting pre-made blocks. There are custom code blocks (JS and Python only, w…”

   proof ↗⚑ flag

   Make—none0/10

   The evidence pack covers Make's API, webhooks, MCP server, error handling, and functions, but contains no mention of a custom code step, JavaScript/Python module, or code-execution capability inside a Make scenario. No evidence supports the ability to write and run custom code as a workflow step.

   ⚑ flag

Connector dev

1. developerBuild a custom connector or private integration with a documented developer platform, SDK, or CLI

   weight 2 · round to Make
   n8n~partialprobed6/10

   n8n documents a developer platform for extensibility: an n8n API (n8n-docs-16), a CLI (n8n-docs-17, n8n-probe-4), and code nodes supporting JavaScript/Python/npm packages for custom logic (n8n-gh-1, n8n-gh-6), plus self-hosting/OEM options for building private integrations (n8n-docs-3, n8n-docs-6). However, community feedback specifically flags that documentation for building custom nodes is weak ('leaves a lot to be desired... especially regarding custom node development' n8n-comm-12), and code blocks have 'limited ability to import libraries' (n8n-comm-6), indicating real gaps versus a mature SDK experience. Missing for 10: a dedicated custom-node SDK/scaffolding tool with strong docs, and independent confirmation that custom connector development is smooth rather than reported as under-documented.

   • [claimed-docs] “n8n API”
   • [claimed-docs] “Use the command line”
   • [probe] “official CLI documented at https://docs.n8n.io/deploy/host-n8n/configure-n8n/use-the-command-line”
   • [github] “Combine visual building with JavaScript, Python, and npm packages for advanced AI workflows”
   • [github] “Code When You Need It: Combine visual building with JavaScript, Python, and npm packages for advanced AI workflows”
   • [community] “The documentation leaves a lot to be desired. Especially regarding custom node development. But also on the user side, for example the kafka…”
   • [community] “N8n looks quite polished and seems primarily concerned about connecting pre-made blocks. There are custom code blocks (JS and Python only, w…”

   proof ↗⚑ flag

   Make✓fullprobed7/10

   Make provides a documented Custom Apps platform (App components: Base, Connections, Webhooks, Modules, Remote Procedure Calls) plus a REST API for building custom connectors/integrations, directly matching the story. Missing for 10: no confirmed official CLI or OpenAPI spec (probe found 404s for openapi.json/swagger.json and a broken docs-md page), and no independent/hands-on corroboration of connector-building success.

   • [claimed-docs] “App components * [Base] * [Connections] * [Webhooks] * [Modules] * [Remote Procedure Calls]”
   • [claimed-docs] “The Make API follows the REST API design. Make API is organized into resource-oriented URLs”
   • [claimed-docs] “All requests to the Make API require authentication with the user authentication token with the relevant scopes enabled.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.make.com/openapi.json, https://developers.make.com/swagger.json, https://develope…”
   • [probe] “PROBE docs-md: HTTP 200 at https://developers.make.com/api-documentation.md # Page Not Found The URL `api-documentation` does not exist. Th…”

   proof ↗⚑ flag

Data mapping

1. ops userMap and transform data between steps with expressions, functions, or formulas

   weight 2 · round to n8n
   n8n✓fullcommunity7/10

   n8n explicitly supports combining visual workflow steps with JavaScript/Python code and npm packages for custom data manipulation, and community users confirm using code nodes, SQL, JSON/XML parsing, and debugging data in/out between steps. Missing for 10: explicit first-party documentation of the dedicated Expression/Function editor syntax and independent verification of complex multi-step transform reliability (community notes it 'looks weird' and requires programming knowledge for hard data-mapping cases).

   • [github] “Combine visual building with JavaScript, Python, and npm packages for advanced AI workflows”
   • [github] “Code When You Need It: Combine visual building with JavaScript, Python, and npm packages for advanced AI workflows”
   • [claimed-docs] “Build visually, go deep with code, connect to anything.”
   • [community] “N8n looks quite polished and seems primarily concerned about connecting pre-made blocks. There are custom code blocks (JS and Python only, w…”
   • [community] “n8n is low code platform to build various applications... You need to write SQL, extract data from XML or JSON, describe HTTP queries and pa…”
   • [community] “I have written some stuff with n8n and I think it is better than most no code platforms because it's debuggable. It keeps all the historical…”
   • [community] “I think using this without programming knowledge is hard, you'll hit a lot of errors and data transformation issues that are hard to solve w…”

   proof ↗⚑ flag

   Make~partialclaimed6/10

   Make docs confirm a dedicated functions system for transforming/formatting data between modules (make-docs-8), which is the core mapping/expression mechanism ops users use between steps. However, evidence lacks depth on formula syntax, custom function scripting (e.g., IML/JS custom functions), or hands-on examples of complex transformations. missing for 10: detailed docs/examples of expression syntax, custom JS functions, and independent validation of transformation capabilities.

   • [claimed-docs] “transform and format data using our range of functions”

   proof ↗⚑ flag

Credentials

1. ops userStore connection credentials centrally, share them with my team, and control who can use which credential

   weight 3 · round to n8n
   n8n~partialclaimed6/10

   n8n has a dedicated Credentials system for centrally storing connection secrets across hundreds of integrations (n8n-docs-23, n8n-intdir-12..30), and enterprise-tier docs reference role-based access control, admin roles, and SSO/SAML/LDAP for governing team access (n8n-gh-5, n8n-docs-28, n8n-docs-8). However, the evidence never explicitly documents a 'share credential with specific users/roles' workflow or granular per-credential permission model, so team sharing and fine-grained control are only implied via general RBAC/admin claims. Missing for 10: explicit documentation of credential-sharing UI/permissions, independent/hands-on confirmation that per-credential access control works as described.

   • [claimed-docs] “Credentials | Nodes | n8n Docs”
   • [github] “Self-host or deploy securely with role-based access, audit trails, and support for sensitive data”
   • [claimed-docs] “Admin roles”
   • [claimed-docs] “SSO, SAML and LDAP”
   • [claimed-docs] “APITemplate.io credentials Asana credentials”

   proof ↗⚑ flag

   Make—none0/10

   The evidence pack only lists 'Connections' as an app component category in custom-app developer docs (make-docs-10); there is no evidence describing centralized credential storage, team sharing, or per-credential access control for ops users.

   • [claimed-docs] “App components * [Base] * [Connections] * [Webhooks] * [Modules] * [Remote Procedure Calls]”

   proof ↗⚑ flag

Human in the loop

1. ops userPause a workflow to wait for human approval or input before it continues

   weight 2 · round drawn
   n8n—none0/10

   The evidence pack contains no mention of a wait/pause node, human-in-the-loop approval step, or any mechanism for pausing execution pending human input — only unrelated items like error workflows, webhooks, and MCP nodes are cited. This is a fair capability to expect from a workflow automation tool, but no evidence in the pack demonstrates it.

   ⚑ flag

   Make—none0/10

   The evidence pack covers webhooks, error handling, MCP server, and API docs, but contains no mention of a human-in-the-loop approval step, pause/resume mechanism, or manual confirmation module within Make scenarios. missing for 10: any documentation of a 'wait for input/approval' or manual confirmation module, pause/resume scenario capability, or timeout-based human approval feature.

   ⚑ flag

Versioning

1. developerVersion workflows through source control or environments and promote changes from dev to production

   weight 2 · round to n8n
   n8n✓fullclaimed7/10

   n8n has dedicated docs on 'Push and pull changes' via source control and environments, plus a pricing-listed 'Version control using Git' enterprise feature, directly supporting versioning workflows and promoting them across environments. Missing for 10: independent/hands-on verification of the dev-to-prod promotion workflow, and details on CI/CD pipeline integration beyond Git push/pull.

   • [claimed-docs] “Push and pull changes”
   • [claimed-docs] “Version control using Git”
   • [claimed-docs] “Admin roles”

   proof ↗⚑ flag

   Make—none0/10

   Evidence only shows scenario cloning and scenario history features, with no documentation of source-control integration, environment separation, or dev-to-production promotion workflows for Make scenarios.

   • [claimed-docs] “clone a scenario”
   • [claimed-docs] “scenario history”
   • [claimed-docs] “schedule a scenario docid 8rwfo krohjlepg4qhx3 clone a scenario docid\ c8f35kwpicyg1az5vlgehdelete a scenario”

   proof ↗⚑ flag

Community

1. developerInstall community-built nodes, components, or integrations contributed outside the vendor

   weight 1 · round to Make
   n8n—none0/10

   Evidence covers n8n's vendor-built integrations directory, npm packages usable inside code nodes, and API access, but nothing documents an official community-nodes marketplace or process for installing third-party-built nodes/components contributed outside n8n itself.

   ⚑ flag

   Make~partialclaimed4/10

   Make provides a Custom Apps SDK (Base, Connections, Webhooks, Modules, RPCs) that lets developers build custom integrations, implying a framework where community-built apps could exist, but there is no evidence of a marketplace, directory, or install flow for discovering and installing third-party/community-contributed apps or modules into a Make account. missing for 10: evidence of a public app marketplace/store, discovery of community apps, one-click install of third-party nodes, and any review/vetting process for community contributions.

   • [claimed-docs] “App components * [Base] * [Connections] * [Webhooks] * [Modules] * [Remote Procedure Calls]”

   proof ↗⚑ flag

Connectors

1. ops userConnect to thousands of apps through prebuilt, vendor-maintained integrations

   weight 3 · round to n8n
   n8n✓fullcommunity8/10

   n8n's GitHub README and docs consistently tout '1500+ integrations' and thousands of templates, backed by an integrations directory covering major SaaS apps (Slack, Notion, GitHub, HubSpot, Jira, etc.) and a long list of built-in credential types, and community users corroborate ease of extending/using integrations in production. Missing for 10: explicit confirmation that all listed integrations are vendor-maintained (vs. community-contributed nodes) and independent benchmarking of integration reliability/coverage depth.

   • [github] “Combine a visual canvas with custom code, run it self-hosted or in the cloud, and connect to 1500+ integrations.”
   • [github] “1500+ integrations and 9,000+ workflow templates to connect AI with your existing systems”
   • [github] “connect to 1500+ integrations”
   • [claimed-docs] “12116 Workflow Automation Templates”
   • [claimed-docs] “Discover 12326 Automation Workflows from the n8n's Community”
   • [claimed-docs] “OpenAI, the creator of ChatGPT, offers a range of powerful models including GPT-3, DALL·E, and Whisper. Leverage these models to build AI-po…”
   • [claimed-docs] “Slack is a powerful collaboration tool for businesses of all sizes. It brings team communication and collaboration into one place so you can…”
   • [claimed-docs] “Notion is an all-in-one workspace for you and your team. It helps team members create tasks, wikis, and databases all at one place.”
   • [claimed-docs] “GitHub is the number one platform for developers. It boosts their software development and enhances their collaboration options. The tools o…”
   • [claimed-docs] “HubSpot is a leading all-in-one marketing and sales software that is tailored for content marketing, SEO, landing pages, lead management, ma…”
   • [community] “We're using n8n in production for a month now and are pretty happy with it. Easily extendable and new integrations can be built easily.”
   • [community] “I'm a developer but use N8N. One reason is not having to build and maintain integrations with lots of APIs for workflows that are just run o…”

   proof ↗⚑ flag

   Make—none0/10

   The evidence pack covers Make's API, webhooks, MCP server, and custom-app-building framework (Base/Connections/Webhooks/Modules/RPC), but contains no citation confirming a marketplace of thousands of prebuilt, vendor-maintained app connectors. Missing for 10: any documentation or listing of the app/connector marketplace, connector count, or vendor-maintenance claims.

   • [claimed-docs] “App components * [Base] * [Connections] * [Webhooks] * [Modules] * [Remote Procedure Calls]”
   • [claimed-docs] “The Make API follows the REST API design. Make API is organized into resource-oriented URLs”

   proof ↗⚑ flag

Templates

1. ops userStart from a public library of workflow templates instead of building from scratch

   weight 2 · round to n8n
   n8n✓fullclaimed8/10

   n8n publishes a public, searchable library of 12,000+ community workflow templates (n8n.io/workflows) that ops users can browse and start from instead of building from scratch, corroborated across multiple docs and GitHub mentions of '9,000+/12,000+ workflow templates.' Missing for 10: independent hands-on account specifically describing starting from a template (vs building from scratch) and details on template customization/import friction.

   • [claimed-docs] “12116 Workflow Automation Templates”
   • [claimed-docs] “Discover 12116 Automation Workflows from the n8n's Community”
   • [claimed-docs] “Discover 12326 Automation Workflows from the n8n's Community”
   • [github] “1500+ integrations and 9,000+ workflow templates to connect AI with your existing systems”

   proof ↗⚑ flag

   Make—none0/10

   The evidence pack covers Make's API, MCP server, webhooks, error handling, and scenario management, but contains no mention of a public template library or gallery that ops users could start from instead of building scenarios from scratch. Missing for 10: any documentation of a templates gallery, marketplace, or pre-built scenario library, and evidence of browsing/importing templates.

   ⚑ flag

Embedding

1. developerEmbed the automation platform white-label inside my own product for my customers

   weight 1 · round to n8n
   n8n✓fullclaimed7/10

   n8n explicitly documents an OEM deployment option that lets developers embed and surface n8n's interface inside their own product's UI, confirming white-label embedding is a supported first-party capability (though it requires a separate commercial agreement). Missing for 10: independent/hands-on developer accounts of actually shipping an OEM-embedded product, and details on branding/customization depth.

   • [claimed-docs] “n8n's OEM deployment option lets you embed and surface n8n's interface inside your own product's UI.”
   • [claimed-docs] “OEM deployment of n8n requires a separate commercial agreement with n8n.”

   proof ↗⚑ flag

   Make—none0/10

   The evidence pack covers Make's API, webhooks, MCP server, and app-building docs, but contains no mention of white-labeling, embeddable widgets, custom branding, or an embed SDK for reselling Make inside a third-party product. Absence of evidence for this applicable capability yields 'none'.

   ⚑ flag

Local dev

1. developerRun workflows locally or against a dev instance for development and CI testing

   weight 2 · round to n8n
   n8n~partialcommunity7/10

   n8n can be self-hosted locally (Docker Compose, one-line curl install) or run on a dev instance, configured via CLI, and supports pushing/pulling workflows between environments via source control integration, which enables dev/test workflows; community confirms long-term self-hosting in production. However, there is no explicit documentation or evidence of a CI-testing framework, automated test runner, or headless workflow execution for CI pipelines specifically. Missing for 10: dedicated CI/testing tooling or docs (e.g. workflow unit tests, CLI-based automated test execution in CI), and independent hands-on confirmation of dev/CI usage.

   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [claimed-docs] “Use the command line”
   • [claimed-docs] “Push and pull changes”
   • [github] “curl -fsSL https://get.n8n.io | sh”
   • [community] “N8N is great. Been self-hosting for years.”
   • [community] “We're using n8n in production for a month now and are pretty happy with it. Easily extendable and new integrations can be built easily.”

   proof ↗⚑ flag

   Make—none0/10

   Make is a cloud-hosted automation platform; the evidence pack shows only cloud scenario execution, webhooks, REST API, and MCP server management — there is no mention of a local runtime, CLI, self-hosted/dev instance, or CI testing workflow for scenarios.

   ⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Make
   n8n~partialprobed2/10

   The evidence pack confirms n8n has a documented REST API (n8n-docs-16) and a CLI (n8n-docs-17), but there's no evidence establishing that this API achieves full feature parity with the UI (e.g., building/editing every workflow node type, credentials, AI agent config, etc.), and a probe for a discoverable OpenAPI spec at standard paths returned 404s. Missing for 10: explicit documentation or independent testing confirming API/UI parity, a published OpenAPI spec, and evidence AI-native users can fully replicate complex canvas actions (agent config, node wiring) purely via API.

   • [claimed-docs] “n8n API”
   • [claimed-docs] “Use the command line”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.n8n.io/openapi.json, https://docs.n8n.io/swagger.json, https://docs.n8n.io/api/openapi.…”

   proof ↗⚑ flag

   Make~partialprobed6/10

   Make ships a documented, resource-oriented REST API covering scenarios, connections, webhooks, and data stores (make-docs-11, make-docs-14), plus an MCP server that lets AI systems run and manage scenarios (make-docs-3, make-docs-20). However, there's no evidence of a formal, discoverable OpenAPI spec (probe found 404s at standard locations, make-probe-3) and no explicit documentation confirming full parity for scenario-building/editing logic via API as opposed to the UI or Make Skills workflow. missing for 10: explicit API endpoints for full scenario creation/editing parity, public OpenAPI schema, independent confirmation of 1:1 UI/API feature parity.

   • [claimed-docs] “The Make API follows the REST API design. Make API is organized into resource-oriented URLs”
   • [claimed-docs] “View and modify scenarios and their related entities (e.g., connections, webhooks, and data stores)”
   • [claimed-docs] “AI systems like Claude and ChatGPT act as MCP clients of Make MCP server. The server provides them access to **scenario run** and **manageme…”
   • [claimed-docs] “Make MCP server allows AI systems, such as large language models (LLMs), to run scenarios and manage the contents of your Make account.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.make.com/openapi.json, https://developers.make.com/swagger.json, https://develope…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to n8n
   n8n✓fullcommunity7/10

   n8n workflows are stored as portable JSON and can be pushed/pulled via Git-based source control (n8n-docs-22), plus a documented REST API (n8n-docs-16) and full self-hosting (n8n-docs-3, n8n-comm-1/16/17) give users real control to extract and leave with their data. Missing for 10: explicit documentation of a bulk 'export all data' feature, independent confirmation of complete data portability (credentials, execution history), and clarity on the fair-code (not fully OSS) license implications for openness (n8n-comm-19).

   • [claimed-docs] “Push and pull changes”
   • [claimed-docs] “n8n API”
   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [claimed-docs] “Without a license key, n8n runs as the free Community edition.”
   • [community] “N8N is great. Been self-hosting for years.”
   • [community] “I have been using n8n for over a year. I prefer it over popular Zapier as it gives me more flexibility and I am able to self host. It has it…”
   • [community] “As per its description on github: N8n is a Free and source-available fair-code licensed workflow automation tool. Not really OSS.”

   proof ↗⚑ flag

   Make—none0/10

   Evidence covers Make's REST API, webhooks, MCP server, and scenario management, but nothing addresses a bulk/full account data export feature or open-format portability guarantee that would let a user leave with all their data. Missing for 10: documented data export/download feature, open format (e.g., JSON/CSV) export of scenarios and data stores, any GDPR-style account export or migration tooling.

   ⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to n8n
   n8n!disputedcontradicted4/10

   n8n's source code is publicly readable on GitHub and docs describe it as 'fair-code licensed' with a Sustainable Use License/Community edition, but this is explicitly not an OSI-approved open source license, and community evidence directly disputes the openness framing ('Not really OSS'). Missing for 10: an actual OSI-approved open license, and vendor acknowledgment that fair-code differs from open source rather than implying openness via branding.

   • [claimed-docs] “A standard, self-hosted version of n8n is available on GitHub.”
   • [claimed-docs] “n8n's Sustainable Use License and n8n Enterprise License are based on the fair-code model.”
   • [claimed-docs] “n8n is a fair-code licensed workflow automation tool that combines AI features with business process automation.”
   • [community] “As per its description on github: N8n is a Free and source-available fair-code licensed workflow automation tool. Not really OSS.”

   proof ↗⚑ flag

   Make—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to n8n
   n8n✓fullcommunity9/10

   n8n provides clear first-party documentation for self-hosting via Docker Compose, one-line install script, or other methods, and confirms a free Community edition runs without a license key; this is corroborated by extensive community testimonials of long-term self-hosting in production. Missing for 10: independent hands-on verification of the self-hosting setup process itself beyond community mentions of using it.

   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [claimed-docs] “Without a license key, n8n runs as the free Community edition.”
   • [claimed-docs] “A standard, self-hosted version of n8n is available on GitHub.”
   • [github] “curl -fsSL https://get.n8n.io | sh”
   • [community] “N8N is great. Been self-hosting for years.”
   • [community] “This is really neat! I'm generally prohibited from using stuff like Zapier at work, since we handle a lot of client data... The self-hosted …”
   • [community] “I have been using n8n for over a year. I prefer it over popular Zapier as it gives me more flexibility and I am able to self host. It has it…”

   proof ↗⚑ flag

   Make—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to n8n
   n8n~partialclaimed6/10

   n8n's self-hosting model (Docker Compose, own infrastructure, on-premises, or private cloud) lets a user fully control where data physically resides, and docs explicitly offer 'Deploy on your infrastructure or ours.' However, this is an indirect residency mechanism (achieved via self-hosting) rather than a first-class region-selection setting, and there is no evidence of specific region options for n8n Cloud. Missing for 10: explicit n8n Cloud region-selection UI/feature, documented data-residency guarantees or compliance certifications tied to region choice.

   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [claimed-docs] “Deploy on your infrastructure or ours.”
   • [claimed-docs] “A standard, self-hosted version of n8n is available on GitHub.”
   • [github] “Self-host or deploy securely with role-based access, audit trails, and support for sensitive data”

   proof ↗⚑ flag

   Make—none0/10

   The evidence pack contains no mention of data residency, regional data storage, or EU/US hosting options for Make; all citations concern MCP server, webhooks, API auth, and error handling. No evidence for data residency capability.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round to n8n
   n8n~partialcommunity4/10

   n8n offers self-hosting on your own infrastructure (n8n-docs-3, n8n-gh-8, n8n-comm-16), which gives users full control over where their data lives and implicitly prevents it from being sent to n8n's cloud or used by n8n for any AI training. However, there is no explicit policy statement, opt-out setting, or documentation addressing AI-training data usage specifically. Missing for 10: an explicit data-usage/AI-training policy or opt-out toggle, independent confirmation that self-hosted data is never used for model training, and clarity on cloud-plan data handling for AI training purposes.

   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [github] “curl -fsSL https://get.n8n.io | sh”
   • [community] “This is really neat! I'm generally prohibited from using stuff like Zapier at work, since we handle a lot of client data... The self-hosted …”
   • [claimed-docs] “Without a license key, n8n runs as the free Community edition.”

   proof ↗⚑ flag

   Make—none0/10

   The evidence pack contains no mention of AI training data opt-out, data usage policies for AI model training, or any privacy controls addressing this specific concern; all evidence covers API auth, MCP server, webhooks, and error handling instead.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to n8n
   n8n~partialclaimed4/10

   n8n's self-hosting option (n8n-docs-3, n8n-docs-14, n8n-gh-5) gives users full control over where data lives and implicitly the ability to delete or retain it as they see fit, and n8n-gh-5 mentions support for 'sensitive data' with audit trails. However, there is no explicit documentation in the pack of configurable execution-data retention/pruning settings, deletion APIs, or GDPR-style data-deletion controls within the product itself. missing for 10: explicit execution-data retention/pruning configuration, documented data-deletion workflow or API, independent confirmation of retention controls working as described.

   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [claimed-docs] “Deploy on your infrastructure or ours.”
   • [github] “Self-host or deploy securely with role-based access, audit trails, and support for sensitive data”

   proof ↗⚑ flag

   Make—none0/10

   The evidence pack contains no documentation of data retention policies, data deletion requests, or privacy/data lifecycle controls for AI-native users; only tangential scenario-management references (e.g., 'delete a scenario') exist, which do not address retention or deletion of underlying data/logs.

   • [claimed-docs] “schedule a scenario docid 8rwfo krohjlepg4qhx3 clone a scenario docid\ c8f35kwpicyg1az5vlgehdelete a scenario”

   proof ↗⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   n8n—none0/10

   No evidence in the pack addresses telemetry, usage tracking, or opt-out settings for n8n; self-hosting is documented but that alone doesn't confirm telemetry can be disabled or clarify what data is collected in cloud/community editions.

   ⚑ flag

   Make—none0/10

   No evidence pack items mention telemetry, usage tracking, analytics opt-out, or privacy settings; the pack covers API, MCP server, webhooks, and scenario docs only.

   ⚑ flag

Durability

1. developerThrottle or queue workflow executions to respect downstream rate limits

   weight 1 · round to Make
   n8n—none0/10

   The evidence pack shows error-workflow handling and community mentions of using 'retries' for sporadic errors, but there is no documentation or evidence of features like rate-limit throttling, request queuing, batching/wait nodes, or execution concurrency controls to respect downstream rate limits.

   • [claimed-docs] “With an error workflow, you can control how n8n responds to a workflow execution failure.”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”

   proof ↗⚑ flag

   Make~partialclaimed4/10

   Make's webhook documentation shows a queuing mechanism where incoming webhook data can be scheduled to be processed periodically in batches rather than immediately, which functions as a basic queue (make-docs-6, make-docs-16, make-docs-21). However, there is no documented general-purpose throttling/rate-limit control for scenario executions against downstream APIs, and no explicit concurrency or rate-limit configuration feature is evidenced. Missing for 10: explicit rate-limit/throttle settings for scenario modules calling downstream APIs, documentation of concurrency controls, and any independent/hands-on confirmation that queuing reliably respects downstream limits.

   • [claimed-docs] “If you don't want to run your immediately after a webhook receives data, you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “the whole queue is then processed every time your schedule criteria are met”
   • [claimed-docs] “custom webhooks allow you to create a url to which you can send any data”
   • [claimed-docs] “webhooks create a url that you can call from an external app or service, or from another use webhooks to trigger the execution”

   proof ↗⚑ flag

2. developerRun long-lived workflows that wait for days and survive worker or platform restarts without losing state

   weight 2 · round drawn
   n8n—none0/10

   The evidence pack contains no mention of n8n's wait/pause mechanism, execution state persistence across worker or platform restarts, or queue-mode durability for long-running workflows. Error-workflow handling (n8n-docs-5) and execution history search (n8n-docs-9, n8n-comm-8) address failure notification and debugging, not surviving restarts during multi-day waits, so this applicable reliability axis is unevidenced.

   ⚑ flag

   Make—none0/10

   Make is a scenario-based automation platform; while it supports scheduling and webhook queuing, there is no evidence of durable long-running workflow execution primitives (e.g., multi-day waits with guaranteed state persistence across worker/platform restarts) comparable to durable-execution frameworks. Evidence only covers webhooks, scheduling, error handling, and MCP server — none address long-lived stateful workflow durability.

   • [claimed-docs] “custom webhooks allow you to create a url to which you can send any data”
   • [claimed-docs] “If you don't want to run your immediately after a webhook receives data, you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “the whole queue is then processed every time your schedule criteria are met”
   • [claimed-docs] “this page helps users navigate errors, diagnose and resolve issues in by providing detailed information on common errors and warnings, error…”

   proof ↗⚑ flag

Error handling

1. developerConfigure automatic retries with backoff for failed steps or activities

   weight 3 · round to n8n
   n8n~partialcommunity4/10

   n8n provides an error-workflow mechanism to react to failed executions (n8n-docs-5) and community usage confirms retries are commonly relied upon in production (n8n-comm-18), but the evidence pack contains no explicit documentation of a configurable retry-with-backoff setting (e.g., delay/backoff intervals) for individual steps. Missing for 10: documentation of per-node 'retry on fail' with configurable backoff/delay, independent confirmation of backoff behavior, and any activity-level retry policy details.

   • [claimed-docs] “With an error workflow, you can control how n8n responds to a workflow execution failure.”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”

   proof ↗⚑ flag

   Make~partialclaimed3/10

   Make's docs repeatedly reference a dedicated 'error handling' system with 'error handlers' for diagnosing and resolving scenario failures, implying some built-in mechanism for handling failed steps, but none of the evidence explicitly mentions configurable retry counts or backoff intervals. missing for 10: explicit documentation of a retry directive with configurable attempts/backoff, and any hands-on confirmation of this behavior.

   • [claimed-docs] “this page helps users navigate errors, diagnose and resolve issues in by providing detailed information on common errors and warnings, error…”
   • [claimed-docs] “diagnose and resolve issues in by providing detailed information on common errors and warnings, error handlers”
   • [claimed-docs] “detailed information on common errors and warnings, error handlers, and how to use them”
   • [claimed-docs] “detailed information on common errors and warnings, error handlers, and how to use them in your”

   proof ↗⚑ flag

2. ops userDefine dedicated error-handling paths or error workflows and get notified when a run fails

   weight 2 · round to n8n
   n8n~partialcommunity6/10

   n8n has a documented first-party 'error workflow' feature letting users control how workflow execution failures are handled [n8n-docs-5], and community evidence confirms n8n keeps historical execution logs so failures are debuggable [n8n-comm-8]. However, the evidence pack doesn't detail specific notification channels (e.g., Slack/email alerting nodes) tied to error workflows or dedicated 'get notified on failure' setup steps, and one community comment notes users 'just live with' sporadic errors using retries rather than dedicated alerting [n8n-comm-18]. Missing for 10: explicit documentation of notification/alerting integration within error workflows, and independent hands-on confirmation that error-workflow notifications work reliably in production.

   • [claimed-docs] “With an error workflow, you can control how n8n responds to a workflow execution failure.”
   • [community] “I have written some stuff with n8n and I think it is better than most no code platforms because it's debuggable. It keeps all the historical…”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”

   proof ↗⚑ flag

   Make~partialclaimed5/10

   Make's help docs confirm a dedicated error-handling system with 'error handlers' for diagnosing and resolving failed runs, which is the core mechanism ops users would use to define error-handling paths. However, the evidence never explicitly describes configurable failure notifications (e.g., email/Slack alerts on scenario failure) or how error routes are wired into scenarios beyond generic mentions. Missing for 10: explicit notification-on-failure documentation, concrete error-handler route configuration details, and independent/hands-on confirmation.

   • [claimed-docs] “this page helps users navigate errors, diagnose and resolve issues in by providing detailed information on common errors and warnings, error…”
   • [claimed-docs] “diagnose and resolve issues in by providing detailed information on common errors and warnings, error handlers”
   • [claimed-docs] “detailed information on common errors and warnings, error handlers, and how to use them”
   • [claimed-docs] “detailed information on common errors and warnings, error handlers, and how to use them in your”

   proof ↗⚑ flag

Observability

1. ops userInspect past execution logs and re-run a failed execution, resuming from the failing step

   weight 2 · round to n8n
   n8n~partialcommunity5/10

   n8n clearly supports inspecting past execution logs (execution search feature, and community reports that 'it keeps all the historical executions so you can see what happened when workflows failed and what data was going in/out of each component') plus error-workflow handling for failures. However, there is no concrete documentation or evidence describing a re-run/retry that resumes specifically from the failing step rather than restarting the whole execution; only a vague community mention of 'retries' as a workaround for sporadic errors. missing for 10: explicit docs/feature describing resume-from-failing-node re-execution, and independent confirmation that this resume behavior works as intended.

   • [claimed-docs] “Execution search”
   • [claimed-docs] “With an error workflow, you can control how n8n responds to a workflow execution failure.”
   • [community] “I have written some stuff with n8n and I think it is better than most no code platforms because it's debuggable. It keeps all the historical…”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”

   proof ↗⚑ flag

   Make~partialclaimed4/10

   Make's docs confirm scenario execution history for inspecting past runs and dedicated error-handling documentation, which supports viewing logs and diagnosing failures, but none of the evidence describes a feature to re-run a failed execution and resume specifically from the failing step. Missing for 10: explicit documentation of a 'rerun/resume from failed step' capability, and any hands-on confirmation that partial re-execution (vs. full restart) is supported.

   • [claimed-docs] “scenario history”
   • [claimed-docs] “this page helps users navigate errors, diagnose and resolve issues in by providing detailed information on common errors and warnings, error…”
   • [claimed-docs] “diagnose and resolve issues in by providing detailed information on common errors and warnings, error handlers”
   • [claimed-docs] “detailed information on common errors and warnings, error handlers, and how to use them”
   • [claimed-docs] “detailed information on common errors and warnings, error handlers, and how to use them in your”

   proof ↗⚑ flag

Schedules

1. ops userRun workflows on cron-style schedules with timezone control

   weight 2 · round to Make
   n8n—none0/10

   The evidence pack lists numerous n8n trigger/node docs (Webhook, MCP Trigger/Client, credentials) but never mentions a Cron/Schedule Trigger node or timezone configuration options, so there is no direct evidence this specific capability is documented or delivered.

   ⚑ flag

   Make~partialclaimed3/10

   Evidence confirms Make has a scenario scheduling feature ("schedule a scenario") and periodic webhook queue processing, but no documentation snippet describes cron-style expressions or explicit timezone configuration options. missing for 10: cron/interval expression syntax details, explicit timezone selection UI/API evidence, independent confirmation of scheduling behavior.

   • [claimed-docs] “schedule a scenario docid 8rwfo krohjlepg4qhx3 clone a scenario docid\ c8f35kwpicyg1az5vlgehdelete a scenario”
   • [claimed-docs] “If you don't want to run your immediately after a webhook receives data, you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “the whole queue is then processed every time your schedule criteria are met”

   proof ↗⚑ flag

Triggers

1. ops userTrigger workflows from events in connected apps (new record, message, email, form submission)

   weight 3 · round to n8n
   n8n✓fullcommunity8/10

   n8n has documented trigger-based nodes (Webhook, MCP Server Trigger) and 1500+ app integrations that fire workflows off events like new records, messages, emails, or form submissions, backed by extensive integration docs and community reports of production use (webhook-initiated tasks, Slack/email/form-style automations). missing for 10: no explicit first-party doc snippet listing app-specific triggers (e.g., 'new email received', 'new form submission') by name, and no independent benchmark of trigger reliability/latency across many apps.

   • [claimed-docs] “Webhook | Nodes | n8n Docs”
   • [claimed-docs] “MCP Server Trigger”
   • [github] “Combine a visual canvas with custom code, run it self-hosted or in the cloud, and connect to 1500+ integrations.”
   • [github] “connect to 1500+ integrations”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”
   • [community] “We're using n8n in production for a month now and are pretty happy with it. Easily extendable and new integrations can be built easily.”
   • [claimed-docs] “Slack is a powerful collaboration tool for businesses of all sizes. It brings team communication and collaboration into one place so you can…”

   proof ↗⚑ flag

   Make✓fullclaimed7/10

   Make's docs describe webhooks that let external apps or events trigger scenario execution (make-docs-5,15,25) plus scheduling to batch-process trigger events (make-docs-6,16,21), which is the mechanism ops users use to fire workflows off new records, messages, forms, etc. from connected apps/modules (make-docs-10 lists Modules/Webhooks as core app components). Missing for 10: explicit named examples of app-specific instant triggers (e.g., new Gmail email, new Typeform submission) and independent/hands-on confirmation beyond vendor docs.

   • [claimed-docs] “custom webhooks allow you to create a url to which you can send any data”
   • [claimed-docs] “webhooks create a url that you can call from an external app or service, or from another use webhooks to trigger the execution”
   • [claimed-docs] “webhooks create a url that you can call from an external app or service, or from another use webhooks to trigger the execution of”
   • [claimed-docs] “If you don't want to run your immediately after a webhook receives data, you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “the whole queue is then processed every time your schedule criteria are met”
   • [claimed-docs] “App components * [Base] * [Connections] * [Webhooks] * [Modules] * [Remote Procedure Calls]”

   proof ↗⚑ flag

2. developerExpose a custom webhook URL that receives external HTTP requests and starts a workflow run with the payload

   weight 3 · round drawn
   n8n✓fullcommunity8/10

   n8n has a dedicated Webhook node documented in official docs, which lets developers expose a custom URL that receives external HTTP requests and triggers a workflow run with the incoming payload; community reports (n8n-comm-18) confirm real-world use of webhook-initiated tasks in production. missing for 10: independent hands-on verification of advanced webhook configuration (e.g., custom auth, response modes) and no dedicated deep-dive doc excerpt beyond the node reference page.

   • [claimed-docs] “Webhook | Nodes | n8n Docs”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”

   proof ↗⚑ flag

   Make✓fullclaimed8/10

   Make's custom webhooks feature lets developers create a URL that receives external HTTP requests and triggers scenario (workflow) execution with the received payload, with options for immediate or scheduled/batched processing of the queue. missing for 10: independent/hands-on corroboration beyond first-party docs, and no detail on payload parsing/validation specifics.

   • [claimed-docs] “custom webhooks allow you to create a url to which you can send any data”
   • [claimed-docs] “If you don't want to run your immediately after a webhook receives data, you can schedule your to process all webhook requests periodically”
   • [claimed-docs] “webhooks create a url that you can call from an external app or service, or from another use webhooks to trigger the execution”
   • [claimed-docs] “the whole queue is then processed every time your schedule criteria are met”
   • [claimed-docs] “webhooks create a url that you can call from an external app or service, or from another use webhooks to trigger the execution of”

   proof ↗⚑ flag

Builder

1. ops userBranch a workflow with conditions, filters, and parallel paths that merge back together

   weight 2 · round drawn
   n8n—none0/10

   The evidence pack contains only generic marketing language about visual building, code extensibility, and error-workflow handling, but no documentation of IF/Switch/Filter nodes or a Merge node that would let branches recombine. Community and docs items never describe conditional branching or parallel-path merging explicitly, so the specific branch-and-merge capability is unevidenced. Missing for 10: docs/evidence on conditional (IF/Switch) nodes, filter nodes, and a Merge node for recombining parallel paths.

   ⚑ flag

   Make—none0/10

   The evidence pack contains no mention of routers, filters, conditional branching, or parallel path merging in Make scenarios — it only covers API auth, MCP server, webhooks, error handling, and scenario management pages. Missing for 10: any documentation of router/filter modules, branch conditions, or parallel-path merge behavior.

   ⚑ flag

2. ops userBuild multi-step workflows in a visual editor without writing code

   weight 3 · round to n8n
   n8n~partialcommunity7/10

   n8n's docs and GitHub materials describe a drag-and-drop visual canvas for multi-step workflows ('Build visually, go deep with code'), with 1500+ integrations and 12000+ templates, and community reports (n8n-comm-18) confirm a non-technical manager built a complex backend visually. However, other hands-on community feedback (n8n-comm-3, n8n-comm-13) says users without programming knowledge hit frequent errors on data transformation/JSON/SQL tasks, meaning pure no-code use has real friction for non-trivial workflows. missing for 10: independent benchmark of non-coder success rate, clearer docs-side guarantee that no-code path avoids expression/code steps for common ops-ops workflows.

   • [claimed-docs] “Build visually, go deep with code, connect to anything.”
   • [github] “Combine a visual canvas with custom code, run it self-hosted or in the cloud, and connect to 1500+ integrations.”
   • [claimed-docs] “12116 Workflow Automation Templates”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”
   • [community] “N8n looks quite polished and seems primarily concerned about connecting pre-made blocks. There are custom code blocks (JS and Python only, w…”
   • [community] “I think using this without programming knowledge is hard, you'll hit a lot of errors and data transformation issues that are hard to solve w…”
   • [community] “n8n is low code platform to build various applications... You need to write SQL, extract data from XML or JSON, describe HTTP queries and pa…”

   proof ↗⚑ flag

   Make~partialclaimed4/10

   Evidence confirms Make's core building blocks—scenarios, modules, connections, webhooks, functions, and error handlers—implying a scenario-based workflow model, but nothing in the pack explicitly describes a visual drag-and-drop editor or no-code experience. Missing for 10: explicit description of the visual canvas/editor UI, no-code claims, and evidence of building multi-step workflows without code.

   • [claimed-docs] “clone a scenario”
   • [claimed-docs] “scenario history”
   • [claimed-docs] “schedule a scenario docid 8rwfo krohjlepg4qhx3 clone a scenario docid\ c8f35kwpicyg1az5vlgehdelete a scenario”
   • [claimed-docs] “transform and format data using our range of functions”
   • [claimed-docs] “this page helps users navigate errors, diagnose and resolve issues in by providing detailed information on common errors and warnings, error…”
   • [claimed-docs] “webhooks create a url that you can call from an external app or service, or from another use webhooks to trigger the execution”

   proof ↗⚑ flag

Composition

1. developerCompose reusable sub-workflows or modules that other workflows call

   weight 2 · round to Make
   n8n—none0/10

   The evidence pack covers n8n's general visual-building, AI/agent, integration, and deployment capabilities but contains no citation referencing sub-workflows, an 'Execute Workflow' node, or any modular workflow-calling-workflow mechanism, which is the specific capability this story asks about.

   ⚑ flag

   Make~partialclaimed4/10

   Evidence shows webhooks can be used to trigger one scenario's execution from another scenario or external app (make-docs-15, make-docs-25), which offers a rudimentary way to compose workflows, and custom apps can define reusable 'Modules' and 'Remote Procedure Calls' (make-docs-10). However there is no explicit documentation of a native 'call another scenario/sub-workflow' module or reusable workflow-as-module composition pattern within the visual builder itself. Missing for 10: dedicated sub-scenario/sub-workflow invocation feature, parameter passing between parent/child scenarios, and independent/hands-on confirmation of this composability pattern.

   • [claimed-docs] “webhooks create a url that you can call from an external app or service, or from another use webhooks to trigger the execution”
   • [claimed-docs] “webhooks create a url that you can call from an external app or service, or from another use webhooks to trigger the execution of”
   • [claimed-docs] “App components * [Base] * [Connections] * [Webhooks] * [Modules] * [Remote Procedure Calls]”
   • [claimed-docs] “custom webhooks allow you to create a url to which you can send any data”

   proof ↗⚑ flag

Testing

1. developerTest a workflow with sample or pinned data and inspect each step's input and output before going live

   weight 2 · round to n8n
   n8n~partialcommunity5/10

   n8n's canvas-based execution tracing is referenced in marketing docs ('Every step of your agents' reasoning, traceable on the canvas') and independently corroborated by a hands-on user noting it keeps historical executions so you can see data going in/out of each node when debugging. However, there is no explicit documentation or mention of the 'pin data' / sample-data testing feature described in the story, and no walkthrough of pre-production testing workflow. Missing for 10: explicit docs on pinning sample data for test runs, and a clear developer workflow showing pre-go-live inspection rather than just post-hoc execution history.

   • [claimed-docs] “Every step of your agents' reasoning, traceable on the canvas.”
   • [claimed-docs] “Build visually, go deep with code, connect to anything. Every step of your agents' reasoning, traceable on the canvas.”
   • [community] “I have written some stuff with n8n and I think it is better than most no code platforms because it's debuggable. It keeps all the historical…”

   proof ↗⚑ flag

   Make—none0/10

   The evidence pack covers Make's API, MCP server, webhooks, and error-handling docs, but contains no documentation of running a scenario with sample/pinned data or inspecting per-step input/output before publishing. 'Scenario history' and 'error-handling' entries are the closest topics but don't describe a test-run/inspect-bundle workflow. missing for 10: docs on 'Run once' test execution, pinned/sample data configuration, per-module input/output bundle inspection.

   • [claimed-docs] “scenario history”
   • [claimed-docs] “this page helps users navigate errors, diagnose and resolve issues in by providing detailed information on common errors and warnings, error…”
   • [claimed-docs] “diagnose and resolve issues in by providing detailed information on common errors and warnings, error handlers”

   proof ↗⚑ flag