Loadster

Disable a Monitor, stopping its scheduled Cycles and their fuel burn; disabling closes the Monitor's open Incidents. Idempotent, and the only enabled-state transition this surface offers — re-enabling is the user's act 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, 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.

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, and per-Population outcomes; 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 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. Whether a Monitor runs is the user's call: enabling happens in the Dashboard at the link, never through this surface. 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 — an empty launchBlockers means the user can launch it as it stands. 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, and row/column counts (without the full value table).

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 loadEngineId 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 finished Load Tests, newest first, a window of summary rows at a time. A Load Test is a run of a Scenario at scale by many bots; the user launches one from the Dashboard, it appears here once it finishes, and nothing on this surface launches, stops, or deletes one. Read one 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.

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. An empty list means the connected team has no projects yet: nothing on this surface creates one, so ask the user to create a project in the Dashboard, then call this again.

list_projects

List the scenarios in a project with their id, name, version, population count, peak bots, and total duration in milliseconds — 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; a user launches it from the Dashboard.

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, and current revision version (without the full command list).

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

Stop a running play. Errors if the run does not exist; once the stop takes effect, get_play_status reports the run as stopped.

stop_script

Optional. Sends a note about this tool surface to the Loadster team, who read it to fix what the surface got wrong. Nothing requires it and no task depends on it. A note is about the tools themselves: what worked, what was missing or confusing, what needed a workaround. It should not carry conversation data: the user's prompts, their credentials, or anything from their account. Feedback is at most 2000 characters; a longer submission is rejected rather than truncated.

submit_feedback

Replace an existing dataset's name and values — the values given become the entire table, so send the complete table including every row you want to keep. To add rows, call append_dataset_rows instead.

update_dataset