Let an LLM Run Your Automation

Veilus’s MCP server lets an LLM agent, such as Claude Code, Cursor or Claude Desktop, do a whole automation job from one request. It can import your proxies, create profiles to match them, open a profile and look around the target site, write a Playwright script, and test it. Once you’ve approved the script, it can run it on many profiles or on a schedule.

The local API, and so MCP, needs a paid plan or the trial.

Setup

Turn on the local API. Open API & MCP in the app sidebar and click Turn on port. It only listens on your own computer.
Create a token. Under Tokens, name it after the tool that will use it (for example claude-code) and click Create token. Copy it right away: it’s shown only once. Naming tokens per tool lets you revoke one later without affecting the others.
Connect your LLM tool. Under Connect an LLM, copy the snippet for Claude Code, or the JSON block for Cursor and Claude Desktop. See MCP Server for the exact commands.

The Veilus plugin for Claude Code

If you use Claude Code, the Veilus plugin adds four skills that walk through the job step by step and stop for your decisions:

claude plugin marketplace add veilus/claude-plugin
claude plugin install veilus@veilus

Restart Claude Code, then type /veilus: to see the skills.

Skill	What it does
`/veilus:campaign`	The whole job: asks what it needs, prepares proxies and profiles, then uses the three skills below
`/veilus:script`	Learns the site in a real profile, writes a script, trial-runs it on up to 3 profiles, fixes it, then asks you to approve it
`/veilus:schedule`	Sizes a schedule to your computer, shows you the plan as a table, and creates it after you agree
`/veilus:run`	Runs the script now, watches the run, explains failures per profile, and reports

The plugin needs a Veilus version newer than 0.2.1. Without the plugin, any MCP client can do the same work. Describe the job and the agent picks the tools.

One request, start to finish

Once connected, describe the whole job in your own words, for example:

Import these 10 proxies, test them, and create one profile per proxy with the timezone matching the proxy. Then open the first profile, go to https://example.com/login, figure out the login form, and write a Veilus script that logs in with USERNAME and PASSWORD and prints the account name. Test it on up to 3 profiles and tell me when it’s ready for me to approve.

And after you’ve approved the script:

Run the login script on all 10 profiles, 3 at a time, then every day at 09:00. Show me which profiles failed.

Here’s what the agent does, step by step:

Import proxies. import_proxies turns your proxy lines into a pool and reports bad lines by line number. test_proxy checks each proxy: alive or dead, latency, exit IP, and that IP’s country and timezone.
Create matching profiles. create_profiles with that pool gives each new profile its own proxy slot, and generates the profile’s timezone and language to match where the proxy exits. A profile whose proxy has no known location isn’t created; it’s listed as failed instead.
Learn the site. launch_profile opens a profile, then the page tools drive it: navigate to a URL, snapshot to list the page’s elements, click, type, press_key and scroll to work through it, and wait_for_element to wait for the next page. If an action opens a JavaScript alert, confirm or prompt, the tool answers it straight away (Cancel unless the agent asks for OK with dialog: "accept") and says which dialog it was. To fill a file upload field, set_file attaches a file from ~/.veilus/data/uploads; it refuses any file outside that folder, so copy the file there first. This is how the agent learns what the site looks like before writing any code.
Write the script. save_script saves a Playwright (TypeScript) script into Veilus Flow. The tool’s description carries the script rules, so you don’t need to repeat them, and a script that breaks them is refused with line numbers.
Test it. run_script runs the script on up to 3 profiles while it isn’t approved yet, and get_run_result reads back each profile’s exit code and output. If something is wrong, the agent fixes the script and saves it again, until it works.
You approve it, in the app, not through the agent. See Approving the script. This is the step that lets the script run for real.
Run it for real. run_batch runs the approved script on many profiles at once (get_capacity helps pick how many in parallel), and create_schedule runs it repeatedly: every N minutes or seconds, daily, weekly, or on a cron expression. Both refuse a script you haven’t approved.
Check the results. list_runs shows recent runs with their status and profile counts. get_run_result has the per-profile detail. stop_profile closes a profile’s browser when the agent is done with it.

Values you mention for a run (like USERNAME above) reach the script as environment variables named VEILUS_VAR_<NAME>, read with process.env.VEILUS_VAR_USERNAME. For values that differ per profile, such as one account per profile, the agent can put them in a dataset with create_dataset and assign_dataset, or store them on a profile with set_profile_variables. Both reach only approved scripts; see the safety notes below.

Approving the script

A script an agent saves is not approved until you approve it. An unapproved script can still be tested through run_script (up to 3 profiles), but schedules and batch runs only accept approved scripts.

To approve one:

Open Veilus Flow and find the script. Agent scripts carry an MCP badge, and Pending approval lists the ones waiting for you.
Read the changes since the last approved version, or click Show full source. This is a real Node program that will run with your user’s permissions. Review it the way you’d review code someone else wrote.
Click Approve this script.

When the agent saves the script again, it goes back to Pending approval and needs another look. If you edit the script yourself in the app and save, that version counts as approved, because you wrote it.

Once approved, the script can run on many profiles at once or on a schedule. More on reviewing, editing and versions: Scripts.

Script rules

Every script save_script accepts follows the same rules, so it works inside Veilus’s profiles instead of launching its own browser. From the tool’s own description:

Connect with chromium.connectOverCDP(`http://127.0.0.1:${process.env.VEILUS_DEBUG_PORT}`).
No chromium.launch / launchPersistentContext.
Use browser.contexts()[0], not newContext().
No setUserAgent / setViewportSize: identity belongs to the profile.
Errors must exit non-zero: main().catch((e) => { console.error(e); process.exit(1); }).
Import only playwright and Node built-ins.
End main() with await browser.close(). It only disconnects from the profile’s browser and lets the script exit; without it the run hangs.

Read input from process.env.VEILUS_VAR_<NAME> (UPPER_SNAKE_CASE), and print what you need to see with console.log. That output is what the agent reads through get_run_result.

A minimal correct script

import { chromium } from "playwright";

async function main() {
  const browser = await chromium.connectOverCDP(
    `http://127.0.0.1:${process.env.VEILUS_DEBUG_PORT}`,
  );
  const context = browser.contexts()[0];
  const page = context.pages()[0] ?? (await context.newPage());

  const url = process.env.VEILUS_VAR_TARGET_URL ?? "https://example.com";
  await page.goto(url);
  console.log(`title: ${await page.title()}`);

  await browser.close();
}

main().catch((e) => {
  console.error(e);
  process.exit(1);
});

What an agent can and can’t do

A few rules are built in so an agent working for you stays inside safe limits:

Create and stop, never delete. No tool deletes profiles, proxy pools, scripts or schedules. Deleting stays in the app, with you. An agent can turn a schedule off with set_schedule_enabled, which keeps the schedule and its history.
Existing proxies aren’t overwritten by accident. assign_proxy_pool refuses the whole call if any of the profiles already has a proxy, unless the agent passes force: true. It also doesn’t change the profiles’ timezone, so a proxy in another country will stop the profile from launching. New profiles should get their proxies through create_profiles instead.
Rate limit on expensive calls. Each token can make at most 30 expensive calls per 60 seconds: launching a profile, running a script, creating profiles, importing proxies, a batch run, or running a schedule now. Past that, calls are refused with a “retry after” time until the window frees up.
evaluate_js is not a sandbox. It runs JavaScript in the profile’s page with the full rights of that logged-in page: it can read cookies and send requests as you. Only let an agent you trust use it on accounts that matter.
Stored values reach only approved scripts. Profile variables saved with set_profile_variables and dataset rows go to batch runs, schedules, and run_script once you’ve approved the script. A test run of an unapproved script gets only the variables passed to that one call, so an unreviewed script never sees the secrets you stored.
Scripts run with your permissions. An agent-written script is a normal Node program. It can do anything a script you wrote yourself could do. Read what the agent saved before you approve it, the same way you’d review a pull request.