# Automation platform vs MCP access: which job?

> Scheduled workflows and ad hoc assistant calls are two jobs. How to split automation platform vs MCP access, and when one tool covers both.

**TL;DR** An automation platform runs scheduled, repeatable workflows on a fixed credential. MCP access gives each person's AI client their own governed reach into company apps for questions nobody wrote a workflow for. Elaichi covers the second job, and the two overlap only when a workflow is really a person asking something on a timer.

## The situation

You already run n8n or Zapier. It fires on schedules and webhooks, it moves records between apps, and it has been reliable for two years. Now your support lead wants to ask Claude about open tickets, and your finance analyst wants ChatGPT to read last month's spend. Somebody suggests building that in the automation platform, because the connections already exist there.

That suggestion is where the automation platform vs MCP access question starts. MCP is the Model Context Protocol, the standard an AI client uses to discover and call tools. The two tools do different jobs, and the cost of mixing them up is paid in audit trails and offboarding, not on day one.

## What does an automation platform actually do well?

An automation platform runs a workflow somebody wrote, on a trigger somebody set, with a credential somebody stored. Nothing about it is ad hoc. That is the point.

The shape is fixed in advance: this trigger, these steps, this app, these fields. You test it, you publish it, it runs identically a thousand times. When it breaks you read the execution log and see exactly which node failed, because the run was the same every time.

The credential model follows from that. n8n's Fixed credential is the default type and is used regardless of who runs the workflow; n8n's own docs say this can expose one person's access and data to everyone else ([n8n, End-user credentials](https://docs.n8n.io/administer/manage-credentials/end-user-credentials), checked October 2026). That is not a flaw for a nightly sync. A nightly sync has no person behind it. It is a flaw the moment the thing on the other end is a person asking a question.

The logs follow from it too. n8n's workflow-lifecycle log events carry a userId field that is not present when n8n starts the execution itself, for example from a schedule trigger ([n8n, Stream logs to external systems](https://docs.n8n.io/administer/observe-and-log/stream-logs-to-external-systems), checked October 2026). For a nightly sync there is no user to name.

n8n's own mechanism for per-person accounts is end-user credentials, which resolve to the connected account of whoever triggers the workflow. They need an Enterprise plan, they are in Preview, n8n advises against relying on them in production, and they support OAuth-based credential types only ([n8n, End-user credentials](https://docs.n8n.io/administer/manage-credentials/end-user-credentials), checked October 2026). Whether an n8n MCP OAuth2 credential can be one of them is not documented on that page.

## What does MCP access do that a workflow cannot?

MCP access gives a person's AI client the ability to find and run tools nobody wrote a workflow for, under that person's own permissions. The question arrives first and the tool call is chosen second.

With Elaichi, Claude, ChatGPT and Cursor all sign into the same address, https://api.elaichi.ai/mcp, with OAuth. Each person connects their client once and approves their own grant, and every call made with that grant's tokens acts as the person who approved it, in the organization they picked. Their permissions are looked up on each request rather than stored in the token.

That is the difference in one line. A workflow runs as a stored credential. An MCP call runs as a person.

The tool list follows the same logic. Elaichi never lists connected tools one by one, however few there are. The model finds a connected tool with `search_tools` and runs it with `execute_tool`, so a grant that reaches four hundred tools does not flood the model's context with four hundred names. A workflow needs none of this, because the author already picked the step.

## Where does the line fall in automation platform vs MCP access?

Ask one question about each piece of work: did a person decide to do this now, or did a schedule?

| Axis | Automation platform (scheduled workflow) | MCP access (Elaichi) |
| --- | --- | --- |
| Who decides a run happens | A trigger somebody set in advance | A person asking something now |
| Steps | Fixed when the workflow is published | Chosen after the question, found with `search_tools` |
| Identity on the call | A stored credential. In n8n a Fixed credential is used regardless of who runs the workflow ([n8n](https://docs.n8n.io/administer/manage-credentials/end-user-credentials), checked October 2026) | The person whose grant the call was made with, with permissions looked up on each request |
| Who the log names | n8n's log events carry no userId when n8n starts the run itself ([n8n](https://docs.n8n.io/administer/observe-and-log/stream-logs-to-external-systems), checked October 2026) | The member whose MCP grant made the call, plus the grant's OAuth client |
| Offboarding | A stored credential keeps working until somebody removes it | Removing or suspending a member revokes their grants, and their clients fail on the next call |

If a schedule decided, it belongs in the automation platform. A nightly Salesforce-to-warehouse sync, a webhook that creates a Jira issue when a form is submitted, a monthly invoice export. Nobody is waiting on the other end, the steps never vary, and a fixed credential is the honest model for work with no person behind it.

If a person decided, it belongs in MCP access. "Which accounts have no activity this quarter." "Summarize the last six tickets from this customer." "What changed on this contract." These are not workflows. Writing a workflow for each one means writing a workflow for every question anyone will ever ask, which is the same as writing none.

The awkward middle is the digest: a scheduled job whose job is to answer a question a person would otherwise ask. ChatGPT's own scheduled tasks can use connected apps such as Gmail, Slack and GitHub, and an action that sends a message or changes external data may require approval, pausing the task until the user reviews it ([OpenAI, Scheduled tasks in ChatGPT](https://help.openai.com/en/articles/10291617-scheduled-tasks-in-chatgpt), checked October 2026). That one genuinely sits on the boundary, and it is covered in more depth in the piece on [governing scheduled agent tasks in advance](/blog/scheduled-ai-agent-tasks-safely/).

## When does one tool cover both?

Sometimes it does, and pretending otherwise wastes a vendor contract.

If your entire AI ambition is three recurring summaries and nothing else, build them in the platform you already run and stop. Your automation platform has the connections, the execution log and the on-call rota. Adding a second vendor to serve three cron jobs is not an improvement, and the honest answer here is the same as in [when you don't need an MCP gateway yet](/blog/when-you-dont-need-an-mcp-gateway/).

Some automation vendors also serve the ad hoc half themselves. Zapier MCP gives each named MCP client its own server on one shared Zapier endpoint, and Zapier's security page says app and action restrictions are not currently configurable for Zapier MCP alone, because a restriction applies account-wide across Zapier features ([Zapier, MCP security](https://docs.zapier.com/mcp/manage/security), checked October 2026). If that account-wide shape matches how your team already works, one vendor may be the whole answer.

If your team is five people on one or two apps and everybody has their own vendor connector already configured, you are also fine. Elaichi earns its place when the list of apps and the list of people both grow, and when somebody has to answer "who reached what" with evidence.

The case for splitting them starts when the questions outnumber the workflows. At that point, writing workflows is a tax on curiosity, and the per-person identity question stops being theoretical.

## What does running them as one tool cost you?

Three things, and each one shows up as a question you cannot answer.

**Whose permissions ran.** Over MCP, a connected tool call acts as the person whose grant it was made with. Where the app on the other end should see the person, the tools must run on that person's own connections: their All tools toolbox, a toolbox built on their own connections, or a template they stamp with their own connection for each connector. A toolbox shared with a team runs each entry on its delegator's connection instead, which is a deliberate choice, not an accident. A workflow on a Fixed credential has no equivalent choice available.

**Who the audit log names.** When an automation calls through one member's MCP grant, each connected-tool row records that member as the actor and the grant's OAuth client. The console names the client, flagged as self-reported unless it is one of the seven clients Elaichi recognizes by their redirect addresses. An n8n cloud host cannot earn a verified mark. So an automation's calls are attributable to a person, but the client name on the row is the client's own claim about itself. The shape of what a row holds is set out in [what each audit log records](/blog/audit-log-comparison-mcp-tools/).

**What offboarding touches.** Removing or suspending a member revokes their MCP grants in that organization, and their clients fail on the next call. Reactivating them does not restore the grants; they consent again. A credential stored inside a workflow is not covered by any of that, and it keeps working until somebody remembers it exists. That gap is the subject of [offboarding AI access](/blog/offboarding-when-the-agent-holds-access/).

## How do you set the split up?

Leave the automation platform exactly as it is. You are not migrating anything.

For the ad hoc half, each person connects their AI client to https://api.elaichi.ai/mcp and approves their own grant on Elaichi's consent screen. The consent screen shows a checkbox for each scope the client requested: read, create and change, run your connected tools, delete. Delete is never pre-ticked, even when the client asks for it. Ticking create or delete locks read on, marked "Always on", because write and delete imply read.

When "Run your connected tools" is ticked, consent has a second step: all the person's tools, or only the toolboxes they pick. "Only the ones I pick" names one to 50 stored toolboxes they can use, re-checked on every call. That is the narrowest shape available at consent time, and it is worth using for a client that only needs to read two apps.

On the Elaichi side, restrictions decide which connectors and tools a role or a member may reach: restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. Within each layer, blocks beat allows, a trade-off worked through in [choosing an allowlist or a blocklist](/blog/allowlist-vs-blocklist-mcp-tools/). A role or restriction change takes effect within about two minutes, because a member's resolved permissions and restrictions are cached briefly and every change writes a new epoch. Grant revocation, member removal and suspension are the exceptions: those are effective on the next call.

If you want the per-person side read-only, there is no consent checkbox for it. "Run your connected tools" covers running every tool in a connected app, deleting included, and "Delete data and remove access" covers only Elaichi's own deletes. To hold a client to reads, pick toolboxes of read tools at consent, or block the write and delete tools with a restriction.

## One more honest caveat

Elaichi's MCP sign-in supports only the authorization-code grant with PKCE, plus refresh. There is no device-code or client-credentials grant, so a new grant always needs a person to approve the consent screen in a browser. Nothing lets a client obtain one unattended.

That is a design choice that follows from the per-person model, and it is also a constraint. If your plan was to hand an unattended scheduler its own Elaichi identity with no person behind it, that is not the shape on offer. Keep that work where it already runs.

For the governance side of the per-person half, [MCP governance: who may do what, in which app](/blog/mcp-governance/) goes deeper on roles and restrictions. For a direct comparison of the two product categories rather than the two jobs, see [n8n AI agents per-user permissions and audit](/blog/n8n-ai-agents-per-user-permissions/). The catalog itself is at [/connectors/](/connectors/).

## FAQ

### Should scheduled workflows and AI assistant tool calls run through the same tool?

Usually not, because they answer different questions. A scheduled workflow has fixed steps, a fixed trigger and no person behind it, so a stored credential is the honest model. An AI assistant tool call is chosen after a person asks something, so it should run under that person's own permissions and be attributable to them. One tool covers both only when the AI work amounts to a handful of recurring summaries, in which case building them in the automation platform you already run is the right answer.

### Does an automation platform give each employee their own app permissions?

It depends on the platform and the plan. In n8n, a Fixed credential is the default type and is used regardless of who runs the workflow; n8n's own docs say this can expose one person's access and data to everyone else (checked October 2026, https://docs.n8n.io/administer/manage-credentials/end-user-credentials). n8n's mechanism for per-user accounts is end-user credentials, which resolve to the connected account of whoever triggers the workflow, but they need an Enterprise plan, are in Preview, and support OAuth-based credential types only.

### Who does the audit log name when an automation calls Elaichi?

The member whose MCP grant the call was made with. Each connected-tool row in Elaichi's audit log records that member as the actor plus the grant's OAuth client, and the console names the client. The name is flagged as self-reported unless the client is one of the seven Elaichi recognizes by their registered redirect addresses: Claude, ChatGPT, Cursor, Grok, Perplexity, Mistral and Devin. An n8n cloud host cannot earn a verified mark.

### Can an Elaichi MCP client get access without a person signing in?

No. Elaichi's MCP sign-in supports only the authorization-code grant with PKCE, plus refresh. There is no device-code or client-credentials grant, so a new grant always needs a person to approve the consent screen in a browser signed in to Elaichi. Work that genuinely has no person behind it, such as a nightly sync, belongs in an automation platform instead.

### How fast does a restriction change reach an AI client?

Within about two minutes. A member's roles, teams, permissions and resolved restrictions are cached briefly, and every role, membership, team, restriction and grant change writes a new epoch that each location has to see. Revoking a grant, removing or suspending a member, revoking a share and disconnecting an account are the exceptions: those take effect on the client's next call.

## Read next

- [n8n AI agents per-user permissions and audit](/blog/n8n-ai-agents-per-user-permissions/) — n8n AI agents per-user permissions come down to whose credential a run holds: what n8n documents, and what Elaichi's MCP endpoint requires.
- [Scheduled AI agent tasks, governed in advance](/blog/scheduled-ai-agent-tasks-safely/) — Scheduled AI agent tasks run with nobody present to approve, so the controls that count are set first: role restrictions, frozen arguments, a narrowed grant.
- [AI gateway vs MCP gateway: which one do you need?](/blog/ai-gateway-vs-mcp-gateway/) — AI gateway vs MCP gateway: one governs your apps' calls to models, the other which tools each person's AI client may call, and on whose account.