Automations & skills over MCP
Two neighbouring areas of the connection. automations and workflows cover work that repeats on
its own; skills covers one saved piece of work, run once, on demand.
Wired, but switched off
Your assistant can wire in a timer switch — choose the hour, run the cable, mount the plate. What it cannot do is flip the breaker. An automation it designs arrives complete and completely off. It starts running the day you turn it on, and not a day before.
That's the whole safety story for this area, and it's why creating an automation from a chat window is a reasonable thing to allow.
| Action | Scope | What it does |
|---|---|---|
automations.describe_schema | read | The shape a valid automation has — kinds of trigger, how steps chain, the two run modes. Read before anything is authored. |
automations.propose | create | Authors the automation and hands you a review page, so you see the design before you go near it. |
automations.create | create | Authors the automation straight into your account as an inactive draft. |
workflows.trigger | write | Not available yet. Reserved for firing an existing automation on demand; calling it today returns a clear "not available" message. Run an automation from Nirvai in the meantime. |
skills.run | run | Runs one saved skill in Nirvai's cloud, addressed by its slug. |
What your assistant actually authors
An automation is a small, explicit design: a name, a trigger (manual, or cron with a schedule
and time zone), the agents it may use — existing agents of yours, named by their own ids — and the
steps, each one saying which agent runs, what it's asked to do, and where the flow goes next on
success or failure. An optional execution_mode picks between the quick default and the mode meant
for long or heavy jobs.
nirvai_execute(
alias = "automations.create",
args = { name: "Monday pipeline digest",
trigger: { type: "cron", cron: "0 9 * * 1", timezone: "America/Santiago" },
agents: ["sales-analyst"],
steps: [{ node_idx: 1, from_idx: 0, type: "agent", name: "Summarise",
agent: "sales-analyst",
input_prompt: "Summarise last week's closed and stalled deals." }] },
description = "Draft a Monday morning pipeline digest for review"
)
Both create actions return a draft, inactive. There is no action that can test, activate or schedule one — you do that yourself in Nirvai, where you can also see it run. See Testing & monitoring runs.
Where you finish this
automations.propose gives you a link to /external/automations/…, and that page is deliberately
read-only — a preview of the trigger and the steps, so you can check the logic before it exists.
There is no Create button on it; you finish the automation inside Nirvai.
- You must be signed in, and only you can open the preview — it is not a shareable link.
- Nothing an assistant makes starts running on its own.
automations.createwrites an inactive draft; you activate it yourself in Nirvai. - To change the design, copy the block the page gives you into your chat — the preview has no way to message your assistant back. See the MCP reference.
skills.runinvolves no review page; it runs a skill you already have and returns the result.
Skills: one saved procedure, run in the cloud
A skill is a piece of real code your agents already have available. skills.run runs exactly one
of them — named by its slug, never by display name — on Nirvai's side, with a genuine working folder
underneath it. Files it produces sync back into your session, so your assistant can pick them up in
the next step.
nirvai_execute(
alias = "skills.run",
args = { skill: "bulk-enrich", module: "main", entry: "run",
args: { table_session: "8e0438a3-…" },
tool_ids: [1697], session: "q3-cleanup" },
description = "Enrich this quarter's new accounts with company size"
)
It's the opposite end of the spectrum from a live-app data script, and the contrast is deliberate:
| Live-app data script | skills.run | |
|---|---|---|
| Imports, files, network | None — pure data in, pure data out | A full environment, with a working folder |
| Can change your records | Never | Yes, if the tools it's given allow it |
| What runs | Code written for that app, checked line by line | A known, saved skill, fetched by slug |
| Session | Required | Required — it's what the working folder belongs to |
A live-app script is deliberately caged because it's newly written code. A skill isn't caged in the
same way because it isn't new — it's the same procedure your agents already run, and there is no way
to hand skills.run free-form code instead.
Limits & guarantees
- Drafts only. Creating an automation never activates, tests or schedules it.
- Existing agents only. Steps reference agents you already own; an unknown one is refused before anything is written.
- Calling twice makes two. Automation creation isn't idempotent — a repeat call is a second automation, not an update.
- Runs on Nirvai. Automations execute on Nirvai's side and consume credits, whoever drafted them.
- Known skills only.
skills.runtakes a slug, a module and an entry point — not a body of code. - Scoped by declaration. A skill only reaches the tools and tables named on the call. Credentials resolve on Nirvai's side and never pass through your assistant; secrets are stripped from anything it prints.
- Bounded results. Output comes back as a capped preview plus a downloadable handle. Long runs return as still-running rather than silently hanging — skills are meant to be short.
- Different keys. Drafting needs
create, firing an existing automation needswrite, and running a skill needsrun. See scopes.