UGC automation that runs from your agent.

Briefs go in, finished vertical ads come out, and nobody opens a generator in between. This is the full pattern: the tools, the clients, the batching and the schedule.

claude code

You

Weekly refresh: three new hooks for each of the two live products, same creator as last week.

get_credit_balance{}

↳ balance sufficient for 6 runs

Agent

I have last week's inputs, so I will hold the creator and the aspect fixed and vary only the opening line.

run_workflow{ "workflowId": "ugc-ad-v4", "inputs": { "aspect": "9:16", ... } }

↳ 6 executions queued

get_execution{ "executionId": "exe_2d18f" }

↳ status completed, output week-32-hook-01.mp4

Agent

Six cuts are in the sheet with their hooks next to them. Nothing is live until you mark a row approved.

A scheduled run. Tool names are the ones the server really exposes.

The shape of a UGC automation

Three stages, and the generation call is the smallest of them. Most of the saving is either side of it.

Collect the briefs
A spreadsheet of products, a batch of URLs or a content calendar. The agent reads the source directly, so nothing gets retyped into a script box.
Write and run the variants
It drafts one hook per row, checks the workflow inputs, queues a run per variant and polls until the files are ready. This is the part that used to be an afternoon of tabs.
Deliver and record
The output URLs go back where you will look for them, and what ran with which inputs is written down as text next to them.

The last stage is the one people skip and the one that pays off. When the brief, the inputs and the resulting URL live in the same row, a creative test becomes something you can query later rather than something you half remember. More on what to record per format is on the UGC video ads page.

The seven tools, and what each one is for

Small enough to learn in a sitting. Six of the seven are reads, which is what makes the planning free.

An agent starts with list_workflows to see what you published, then get_workflow to read one pipeline's inputs. That second call is what lets it fill a brief in properly: it learns the workflow takes a product, a script, an avatar and an aspect ratio, so it asks about anything you left blank instead of guessing.

list_templates and list_models cover the next two questions. Templates are pipelines you could duplicate as a starting point, and models tell you which image, video and voice engines are available, which matters because model choice is the main lever on how real the output looks.

Then the pair that does the work. run_workflow starts a run and returns an execution id, and get_execution polls that id until the output URL is there. Generation is not instant, so a well behaved agent queues the whole batch first and polls afterwards.

get_credit_balance is the one people forget. Calling it before a batch turns a run that dies halfway into a run that never starts.

tools

list_workflows ....... find the pipelines you published
get_workflow ......... read one pipeline's inputs and steps
list_templates ....... browse pipelines you could duplicate
list_models .......... see which image, video and voice models are available
get_credit_balance ... check the budget before committing to a batch
run_workflow ......... start a run  (this is the one that spends)
get_execution ........ poll a run and collect its output URL

Only run_workflow spends credits. The other six are free at any volume.

Connect it from where you already work

The server is one HTTP endpoint, so the setup is a config entry rather than an integration project.

The same JSON works in more than one client, because the shape belongs to the protocol rather than to any product. Drop it in, approve the connection once, and the generation tools appear next to everything else your agent can reach.

What differs is only where the file lives. Claude Code and Cursor are where you build and test the instruction. n8n is where it goes once you want it running without you.

.mcp.json

{
  "mcpServers": {
    "wireflow": {
      "type": "http",
      "url": "https://www.wireflow.ai/api/mcp"
    }
  }
}

One HTTP endpoint. You approve access on first call, so there is no key to paste.

Client	How it connects	Best for
Claude Code	A .mcp.json file in the project, or claude mcp add with the http transport. The config can be committed so a team shares it.	Writing and refining the instruction, and running batches by hand while you tune the brief.
Cursor	A mcp.json file, either .cursor/mcp.json in the project or ~/.cursor/mcp.json globally. Remote servers are configured with a url field.	Keeping generation next to the code or content repo the campaign already lives in.
n8n	The MCP Client Tool node, which lets an n8n agent use the tools an external MCP server exposes.	Scheduled and event driven runs: a weekly refresh, or an ad generated whenever a row lands in a sheet.

Compiled from each client's own public documentation in August 2026. Client support for MCP moves quickly, so check the current docs before you plan a rollout around any row.

We are not affiliated with Claude Code, Cursor and n8n. Product names are used to describe what those products do. This site is built by the team behind wireflow.ai, so wireflow is our own product and we say so wherever it appears.

Batching variants without opening a tab

This is the case that justifies the whole setup. One brief is a wash. Twelve is not close.

Creative testing is a volume game with a low hit rate, so the useful unit is not an ad, it is a set. Twelve rows become twelve runs from one instruction, and the agent handles the awkward parts: holding every input except the hook identical so the test is fair, and writing each URL back beside the brief that produced it.

Two rules keep a batch honest. Vary one thing at a time, because a set where the creator, the script and the model all changed teaches you nothing. And put the variable in the row rather than in the prompt, so next month is the same instruction against a different file.

Failures are normal at this volume. Have the agent report which rows failed and retry only those, rather than rerunning the set and paying twice.

batch run

$ claude -p "read briefs.csv, generate a 9:16 UGC ad for every
   row, write the video URLs back to the file"

  reading briefs.csv .................. 12 rows
  get_credit_balance .................. sufficient for 12 runs
  run_workflow ........................ 12 queued
  get_execution ....................... 11 completed, 1 failed
  retrying row 7 ...................... completed
  writing URLs back to briefs.csv ..... done

  12 ads, no dashboard opened.

Putting it on a schedule

Unattended generation, attended approval. That split is what makes a schedule safe to leave running.

Once a batch runs cleanly by hand, the same instruction can fire on a timer. An n8n schedule trigger or a cron job both work, because the instruction is text either way. Creative then arrives on a Monday already generated, and the only step left is choosing what ships.

Point it at a source that changes on its own: a content calendar, a list of live products, or the hooks that performed last week.
Cap the batch size in the instruction. An automation that can queue unbounded runs is a billing incident waiting for a bad input file.
Deliver into a review surface, never into a live campaign, and log the inputs beside each output so a winner can be traced back to its script and model.

Why the agent, and not a better dashboard

A dashboard could add bulk upload and a scheduler and still miss the reason this pattern works.

The reason is that the generator stops being a destination. All of the above happens in the window where the rest of the work already happens, so the agent that read the product page is the agent that wrote the hook, ran the generation and filed the result. Nothing is exported, pasted, or lost between two tools that do not know about each other.

A dashboard, however good, is a place you go, and that is a fixed cost per ad which does not fall with volume. A tool call has almost no fixed cost, which is why the same instruction works for one ad and for fifty, and why nobody has to be awake for the fifty. Most products in this category are still on the other side of that line, which the Arcads and MakeUGC comparisons go into.

What to keep out of the automation

The pattern is worth having because it moves labour, not because it moves judgement.

Whether the hook is any good

An agent will write twenty openings and generate all of them. Which one earns the first two seconds is still a judgement call, and it is the one that moves the numbers.

Claims about the product

Anything a synthetic creator says on camera is a claim your business made. Keep the claim lines in a reviewed source the agent quotes from, rather than improvised.

Disclosure and platform rules

Generated performers need labelling where the platform or the law asks. That is a policy decision with a person's name on it, not a step in a graph.

The final spend gate

Read tools are free, so let the agent plan freely. Keep a confirmation in front of the run that turns a plan into a bill, at least until you trust the pattern.

The honest version of this pitch is that automation raises how much you can test, not how good your taste is. The free AI UGC page covers how far you get before spending, and the agency page covers running this across several clients at once.

Questions people ask about UGC automation

What does UGC automation actually mean?

It means the whole path from a brief to a finished ad file runs without anyone clicking through a generator. Briefs go in, hooks get written, the generation runs, the URLs come back recorded, and a person reviews the result rather than assembling it. The generation step is the easy part; the automation is everything around it.

What is a UGC agent?

It is any assistant that can call a UGC generator as a tool rather than describing how to use one. In practice that means an MCP client such as Claude Code, Cursor or an n8n workflow, pointed at a server that exposes generation tools. It reads the available workflows, fills in their inputs from your brief, and hands the files back.

Do I need to write code to automate UGC?

No, and that is the change MCP made. Connecting a hosted server is a few lines of JSON in a config file, and after that the instruction is written in plain language. You only reach for code when you want it running unattended, and even then a scheduled prompt does most of it.

How do I stop an agent from spending credits I did not approve?

Six of the seven tools are reads and cost nothing, so an agent can plan a whole batch for free. Have it call get_credit_balance and state the run count before it starts, and keep tool approval on for run_workflow so nothing bills without a confirmation.

Can this run on a schedule with nobody watching?

Yes. A cron job or an n8n schedule trigger can fire the same instruction weekly and drop the resulting URLs into a sheet for review. The pattern that works is unattended generation with attended approval, so creative arrives ready to judge rather than arriving live.

Does automating it make the ads worse?

Only if you automate the taste as well as the labour. The volume is what lets you test more hooks, and testing more hooks is the thing that raises the average. Keep a person choosing what ships and automation raises your output without lowering your standard.

Wire up the first batch

Connect the endpoint and run one brief by hand. Once that is clean, the same instruction runs against a whole file.