Mutator

Create a new automation as a DRAFT, optionally with its steps already wired. It is never activated and never runs: a draft has no active version, the scheduler only fires active automations, and nothing here can activate one. The person opens it, reads it, and turns it on. An invalid graph is still saved — the problems come back as `issues` for you to fix and save again, rather than the whole call failing. Report what you built and what is left to decide; do not describe it as live.

Read how published content performed over a window of days — the same report the dashboard shows. Use it to answer what worked and to suggest what to run next.

Read one automation in detail: status, its schedule if it has one, and its own spending limits. Use it before starting a run to check the automation is active and what a run may cost.

Read one run with its per-step detail, so a failure can be traced to the step that caused it. Runs are asynchronous: a run still marked running has not finished, so poll rather than assume.

Report the workspace's daily and monthly spending ceilings and how much of each is already committed. Generation runs on Mutator's own accounts and is paid for in credits, and the ceilings still apply, so check this before starting anything that generates — a run that would pass a ceiling is refused before any provider is contacted.

Always empty. Approvals were removed on 20 September 2026: a run publishes nothing, and a post is made by a person picking a file, an account and a time in Mutator. Tell the person that, rather than reporting an empty queue as if something were wrong. Use mutator_get_run to report what a run made.

List every automation in the workspace with its id, name and status (draft, active or paused). Start here when the user refers to an automation by name and you need its id.

List the brands in the workspace. Every automation belongs to one, so this is the first call when creating anything: mutator_create_automation needs a brandId from here. The brand carries the voice an automation writes in — audience, tone, call to action.

List the accounts and providers this workspace has connected, with the id a publishing step needs. A publish step points at a connection, not at a platform name — there is no 'post to TikTok' field, only 'post to this account, which happens to be TikTok'. Read this before wiring one, because a publish step with no connection is refused at activation rather than saved and forgotten.

The content formats this product actually knows, and the niches they suit. Use one of these when building — do not invent a format. There is no trend, virality or discovery data anywhere in Mutator: nothing here knows what is performing on any platform this week, and a niche only ORDERS this list, it never filters it. If a user asks for 'viral formats in my niche', these are the formats, ordered by fit, and the word viral is not something this tool can stand behind.

List recent runs of one automation, newest first, with status, whether each was a dry run, and what it cost. Use it to answer 'did it work' and 'what did it cost'.

The complete vocabulary of steps, with the settings each one takes. An automation is a graph of these joined by edges. Read this before building one: the step list is closed, and a graph naming a type that is not here is refused. Most settings have defaults, so a step can usually be sent with an empty config and still run.

Replace an automation's steps with the ones given, saved as a DRAFT. An active automation keeps running its current version until a person activates the draft, so editing something live is safe. Problems come back as `issues` rather than failing the call — read them and save a corrected graph.

Set when an automation would run, saved switched OFF. Turning a schedule on requires an already-active automation, so this can only ever prepare one — the settings survive until a person activates it. A schedule runs an automation AT MOST ONCE A DAY: it holds a single time, and frequency chooses which days rather than how many times within one. Two posts a day is not a schedule setting: it is one daily run producing two items, with maxPostsPerDay on the publishing step.

Start a run of an automation. Defaults to a DRY RUN, which skips publishing but not generation: it makes the same paid generation calls a real run makes, costs the same credits or provider charges, and counts against the same spend limits. So start one only when the user wants a run, and leave it dry unless they have asked for a real run in this conversation. A real run still publishes nothing on its own: anything it generates goes to the workspace's library, and is posted only when a person schedules it in Mutator. Requires an idempotencyKey; replaying the same value returns the original run instead of starting a second one, so retry with the same key rather than a new one.

Confirm the API key works and report which Mutator workspace it reaches and what it may do. Call this first when the connection is new or a later call fails with an authorization error.