Loadster

Delete a file attached to a script.

delete_script_asset

Disable a Monitor, stopping its scheduled Cycles and the Fuel or plan usage they bring; disabling closes the Monitor's open Incidents. Idempotent. Re-enable it with enable_monitor at the "Read+Write+Execute" access level; below that level the tool is absent, and the user re-enables it in the Dashboard at the link the returned summary carries.

disable_monitor

Duplicate a script, optionally with a new name and into another project the token can access. Returns the copy's summary.

duplicate_script

Get the recursive schema for one command type, so you can build a valid command object. Some fields carry a 'notes' string describing accepted keys that aren't reflectable, such as element action options and locator attributes.

get_command_schema

Get a single dataset's shape — name, row and column counts, tag names, dashboard link — plus a leading window of its rows: the first five in table order by default, more with offset and limit. Compare rowOffset and the rows returned against rowCount to see how much you are not looking at. Loadster serves every row to bots, but a user's imported data may still start with a header-looking row — don't assume either way; ask before treating or removing it.

get_dataset

List the Loadster manual's topics with their keys and URLs, or read up to 3 topics' text by key. Pass one key as topic, or up to 3 keys as topics. Omit both to list every topic.

get_documentation

Get a small, valid worked example script for a bot type to use as a starting point.

get_example

Get a single Incident: when it opened and closed, every notification that went out with its delivery outcome, the status events recorded on it, and the ids of the Cycles that opened and closed it. To reconstruct what happened, read those Cycles with get_monitor_cycle_detail, and cross-read the Monitor's configuration and its Script so the diagnosis names the concrete step, URL, or threshold at fault rather than a vague symptom. The 'monitoring' topic covers advising on thresholds or noise.

get_incident

Get a finished Load Test's Test Report — aggregate totals, the error and advice picture behind the Dashboard's advice tile, per-Population outcomes, and each engine's average and peak CPU; an unfinished test answers with an error naming its status. The advice buckets and detection flags are heuristics, not a diagnosis of this test: where the totals, percentiles, per-URL counts and Populations contradict a bucket or a flag, or show something it never names, say so and follow the data. Before advising the user, read the get_documentation topic 'analyzing-test-results' and cross-read the Scenario and the played Scripts, so your advice names concrete elements — a specific URL, Population, bot count, or script step — instead of repeating the error buckets back.

get_load_test_report

Get a Load Test's live status, as the Dashboard's live test view shows it: stage, elapsed time, Bots started, running, peak and planned per Population, Iterations, response time percentiles, throughput, errors by type, and each engine's region, online state and, while the test runs, current CPU percentage. Use it to tell the user how a test in progress is going, and to tell an overloaded engine from a slow target. Call it no more often than every 10 seconds; the numbers do not move faster than that. Once the test is over, the status says so in its note; stop polling and read the Test Report with get_load_test_report.

get_load_test_status

Get a finished Load Test's response times per URL, slowest first by the total time all hits to the URL took: hits, average, minimum and maximum response time, and average time to first byte, in milliseconds. Use it to name the slow pages behind the percentiles in get_load_test_report. Compare urlOffset and the URLs returned against totalUrls to see how much you have not read; page on with offset.

get_load_test_url_timings

Get a single Monitor's full configuration and dashboard link. Configuration only — a Monitor's steps are its Script's commands, so read them with get_script. To start a disabled Monitor, call enable_monitor at the "Read+Write+Execute" access level; below that level the tool is absent, and the user enables it in the Dashboard at the link. The 'monitoring' topic covers what a Monitor's configuration should be.

get_monitor

Get one Cycle in full: status, failure message, the engine it ran from, timestamps, and every metric the Monitor's thresholds judge. Its scriptRunId is a played run like any other — pass it with the project id to get_play_status for per-step results and get_step_detail for the exact request and response that failed — and it names the scriptId it checked, so cross-read the Script and point advice at a concrete step or URL. Works with a cycle id from list_monitor_cycles or from an Incident's cycle references. The 'monitoring' topic covers what the thresholds should be.

get_monitor_cycle_detail

Get the Monitoring Summary for a project: the aggregate health picture across its Monitors over a period, defaulting to the last 7 days, with per-Monitor and per-day aggregates for trends (times in seconds; performance score 0-100). Drill down instead of asking for more: list_incidents for what opened and closed in the period, list_monitor_cycles for one Monitor's individual Cycles. Read the 'monitoring' topic before interpreting uptime or health for the user.

get_monitoring_summary

Get the current state of a play, with per-step results and log that fill in as it progresses, optionally waiting for it to finish. After play_script, call this with waitSeconds instead of sleeping between polls; the results are complete once running is false. Each step's has-flags (hasBody, hasLog, and their siblings) say which get_step_detail parts would return something for that step, so drill down only where a flag is true. On a Playwright run the whole runner log belongs to the command step that ran the spec file — hasLog points there. A step's screenshotKeys are in capture order; a Playwright step lists the script's own page.screenshot calls in order, with the runner's final screenshot of the test last.

get_play_status

Get a single scenario including its Populations, plus a dashboard link and its launch readiness: the account's fuelBalance; launchBlockers, where an empty list means it can launch as it stands; and estimatedFuelLow and estimatedFuelHigh, the low and high ends of the Fuel estimate the Dashboard shows. The estimate is present whenever the test would burn Fuel, which is every test on an account without a plan, and on one with a plan, any test the plan does not cover; launch_load_test then runs the whole test on Fuel. Without an estimate, it runs on the account's plan and burns no Fuel. get_documentation topic 'faqs/plan-or-fuel' explains when a plan or Fuel applies. A field left out of a population is at its default: iterations and iterationsPerUser unlimited, aggressionMultiplier 1.0, and bandwidth unthrottled. Read get_documentation topic 'load-test-scenarios' for what the stages and ramps actually do.

get_scenario

Fetch a screenshot captured during a play as a viewable image. Use the screenshotKey from a step in get_play_status.

get_screenshot

Get a single script including its full command list and variables, plus a dashboard link. The variables are the script's dataset bindings — the ${...} references in its commands resolve through them.

get_script

Read a script asset's content as base64.

get_script_asset

Get a specific past revision of a script, including its commands, so you can inspect or diff it.

get_script_revision

List the scripting API scopes (bot, http, browser, ...) available in code blocks, or fetch one scope's members with their signatures and docs.

get_scripting_api

Read the payloads get_play_status leaves out — response bodies, headers, captured values, console messages, network activity, page HTML, logs — for one or more steps of a play, choosing the parts per call. Ask for several steps at once: a failing request and the earlier step that captured the token it used is one call. Use this instead of adding a validator or code block to the script just to echo a response back to yourself. Parts are bot-type-shaped, and asking for a part a run has no source for returns an error naming what it does have.

get_step_detail

Get the schema for binding a script variable to a dataset, including the accepted update and selection strategies. A variable is a named row cursor bound to one whole dataset by dataSetId: on each pull it holds an entire row, advancing per occurrence, per iteration, or per bot ('vuser') depending on updateStrategy, with rows taken sequentially or randomly per selectionStrategy. Reference it as ${name} in command fields or bot.getVariable('name') in Playwright code. After changing bindings or references, run validate_script to cross-check them.

get_variable_schema

Import an open-source load test (JMeter .jmx, k6 .js, or Locust .py) into an existing script, converting it to Loadster commands. An import may create script assets, datasets, and a scenario; replace=true also replaces the script's existing commands and variables. Returns action items to review. For OpenAPI/Swagger or Postman, read the spec yourself and build commands with create_script instead.

import_script

List the command (step) types available for a bot type, with a description and the bot types each applies to. Use this before authoring commands.

list_command_types

List the datasets in a project with their id, name, row/column counts, and tag names (without the full value table). Tags are shared across the team: to tag an item, reuse a name the list tools already report, and create a new tag only when the user asks for one.

list_datasets

List everywhere a population can run, with the customer's own limits a scenario is written against. Each entry's id is what a population's engineId names — never invent one. Type CLOUD is a single Loadster cloud region, WILDCARD is a pattern ('north-america-*', '*') that lets Loadster pick a region inside it when the test launches, and PRIVATE is one of the customer's own Loadster Engines, the only kind that can reach a host on their network. The per-population caps and stage bounds are enforced when a scenario is saved; capacities, locked regions, and the per-region and per-engine caps matter only at launch and never stop a save. While limits.freeTrialCustomer is true, an entry with locked true can be saved onto but not launched from, so put a trial's populations on an entry with locked false and keep the scenario's peak within limits.maxFreeTrialBotsPerTest.

list_engines

List a project's Incidents — open ones first, then the most recently closed; unresolved only by default, with includeResolved for incident archaeology over a since/until window and monitorId to ask about one Monitor. An Incident opens when a Monitor's consecutive failing Cycles reach its failure threshold, and closes after enough consecutive passes, or when the Monitor is disabled. Rows are lean; read one Incident's notifications, statuses, and cycle references with get_incident. The 'monitoring' topic covers how Incidents notify.

list_incidents

List a project's Load Tests, a window of summary rows at a time: the ones in progress first, each with its stage, then the finished ones, newest first. A Load Test is a run of a Scenario at scale by many bots; launch_load_test launches one and stop_load_test stops one, at the "Read+Write+Execute" access level; below that level both are absent and the user does it in the Dashboard. Nothing on this surface deletes one. Follow a test in progress with get_load_test_status; read a finished test's Test Report with get_load_test_report.

list_load_tests

List a Monitor's Cycles, newest first — one row per Cycle with its status, timestamps, the engine id it ran from, and headline response times; a Cycle with no status yet is scheduled or still running. Window with since/until and limit to spot patterns — flapping around a threshold, slow drift, failures from one region — then drill into one Cycle's full metrics and failure message with get_monitor_cycle_detail. The 'monitoring' topic explains what each status means.

list_monitor_cycles

List everywhere a Monitor's Cycles can run from. Each entry's id is what a Monitor's engineIds names — never invent one. Type CLOUD is one of Loadster's shared monitoring locations, and PRIVATE is one of the customer's own Loadster Engines, the only kind that can reach a host on their network. Monitoring locations are their own set, not the load test regions list_engines offers. Read this before create_monitor or update_monitor.

list_monitoring_locations

List the Monitors in a project. A Monitor is a scheduled, low-volume check that runs a Script on a frequency to verify health and alert on failure; each execution is a Cycle. Each row is a summary without the thresholds and engine ids; read one Monitor's full configuration with get_monitor. Read get_documentation topic 'monitoring' for how Monitors, Cycles, and Incidents behave. Tags are shared across the team: to tag an item, reuse a name the list tools already report, and create a new tag only when the user asks for one.

list_monitors

List the Loadster projects the current token can access, each with its id and name. Every other tool takes one of these ids. When the team has no projects, the result says so and points at create_project. Prefer an existing project: call list_projects first, and create a new one only if the team has none or the user explicitly asked for one. When unsure, ask the user before creating.

list_projects

List the scenarios in a project with their id, name, version, population count, peak bots, total duration in milliseconds, and tag names — without the populations, fuel estimate, and launch blockers get_scenario reports. A Scenario is a saved load test configuration: a named list of Populations (the Dashboard calls them "bot groups"), each of which runs one script with its own load shape on one engine or region. Saving a scenario costs nothing and runs nothing. Launch it with launch_load_test at the "Read+Write+Execute" access level; below that level the tool is absent, and the user launches it from the Dashboard. Tags are shared across the team: to tag an item, reuse a name the list tools already report, and create a new tag only when the user asks for one.

list_scenarios

List the files attached to a script (request bodies, upload files, Playwright support files). Each path is the key a command references.

list_script_assets

List a script's past revisions (newest first) with version, save time, author, and step count.

list_script_revisions

List the scripts in a project with their id, name, bot type, step count, current revision version, and tag names (without the full command list). Tags are shared across the team: to tag an item, reuse a name the list tools already report, and create a new tag only when the user asks for one.

list_scripts

Start playing a saved script. Returns immediately with a run id and a queued status, since a play can take anywhere from a few seconds (HTTP) to several minutes (browser or Playwright); read the results with get_play_status.

play_script

Upload or replace a script asset from base64 content. Use the path as the key a command references — e.g. set an HTTP command's requestBody to { "key": "<path>" } to give it a request body, or list the path in a browser upload step's files.

put_script_asset

Restore a script to a past revision, saving that revision's commands as a new revision.

restore_script_revision