append_dataset_rows
ChatGPTAdd rows to the end of an existing dataset, sending only the new rows — the rows already in the table stay as they are, so there is no need to read them first. Every row must have as many columns as the table already has; a row that doesn't is rejected and nothing at all is written. Appending to an empty dataset takes the column count from the first row.
create_dataset
ChatGPTCreate a new dataset in a project. Loadster treats every row as data and addresses columns by zero-based index — a header row would be fed to bots like any other row, so don't add one when authoring values. Unless the user explicitly asked for a dataset, confirm with them before creating one.
create_monitor
ChatGPTCreate a Monitor in a project — always disabled, and nothing on this surface can enable one. An enabled Monitor consumes fuel on its schedule, unattended, so enabling is the user's act in the Dashboard, at the link the returned summary carries. Read the 'monitoring' topic before choosing a frequency or thresholds.
create_scenario
ChatGPTCreate a scenario in a project — saving costs nothing and starts nothing, so hand the user the dashboard link and let them launch it. The save is refused for a loadEngineId list_engines doesn't offer, a stage shorter than the minimum, or more bots or populations than the account allows, and the refusal names the limit. The summary's launchBlockers are reasons the user could not launch it right now; they never stop the save, so tell the user about a blocker instead of rewriting the scenario to avoid it. The 'load-test-scenarios' topic covers what the stages and ramps actually do.
create_script
ChatGPTCreate a new script in a project. Read the relevant get_documentation topics and use the schema tools first to build valid commands for the bot type. Like every write on this surface, returns a summary — the server-assigned facts and a dashboard link — never the object you sent; the matching get tool reads it back.
delete_dataset
ChatGPTDelete a dataset from a project.
delete_monitor
ChatGPTDelete a Monitor from a project. Its Incidents are deleted with it and it is removed from any status pages; the Script it played is left alone. To stop a Monitor running without losing it, use disable_monitor instead.
delete_scenario
ChatGPTDelete a scenario from a project. The scripts its populations referenced are left alone.
delete_script
ChatGPTDelete a script from a project.
delete_script_asset
ChatGPTDelete a file attached to a script.
disable_monitor
ChatGPTDisable 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.
duplicate_script
ChatGPTDuplicate a script, optionally with a new name and into another project the token can access. Returns the copy's summary.
get_command_schema
ChatGPTGet 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_dataset
ChatGPTGet 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_documentation
ChatGPTList the Loadster manual's topics with their keys and URLs, or read up to 3 topics' text by key.
get_example
ChatGPTGet a small, valid worked example script for a bot type to use as a starting point.
get_incident
ChatGPTGet 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_load_test_report
ChatGPTGet 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_monitor
ChatGPTGet 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_cycle_detail
ChatGPTGet 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_monitoring_summary
ChatGPTGet 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_play_status
ChatGPTGet 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_scenario
ChatGPTGet 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_screenshot
ChatGPTFetch a screenshot captured during a play as a viewable image. Use the screenshotKey from a step in get_play_status.
get_script
ChatGPTGet 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_asset
ChatGPTRead a script asset's content as base64.
get_script_revision
ChatGPTGet a specific past revision of a script, including its commands, so you can inspect or diff it.
get_scripting_api
ChatGPTList the scripting API scopes (bot, http, browser, ...) available in code blocks, or fetch one scope's members with their signatures and docs.
get_step_detail
ChatGPTRead 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_variable_schema
ChatGPTGet 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.
import_script
ChatGPTImport 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.
list_command_types
ChatGPTList 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_datasets
ChatGPTList the datasets in a project with their id, name, and row/column counts (without the full value table).
list_engines
ChatGPTList 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_incidents
ChatGPTList 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_load_tests
ChatGPTList 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_monitor_cycles
ChatGPTList 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_monitoring_locations
ChatGPTList 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_monitors
ChatGPTList 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_projects
ChatGPTList 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_scenarios
ChatGPTList 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_script_assets
ChatGPTList the files attached to a script (request bodies, upload files, Playwright support files). Each path is the key a command references.
list_script_revisions
ChatGPTList a script's past revisions (newest first) with version, save time, author, and step count.
list_scripts
ChatGPTList the scripts in a project with their id, name, bot type, step count, and current revision version (without the full command list).
play_script
ChatGPTStart 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.
put_script_asset
ChatGPTUpload 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.
restore_script_revision
ChatGPTRestore a script to a past revision, saving that revision's commands as a new revision.
stop_script
ChatGPTStop a running play. Errors if the run does not exist; once the stop takes effect, get_play_status reports the run as stopped.
submit_feedback
ChatGPTOptional. 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.
update_dataset
ChatGPTReplace 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_load_test_notes
ChatGPTReplace the notes on a finished Load Test's Test Report — the only writable thing on a Load Test. Ask the user before writing: notes belong to the user, and advising on a test never requires writing them. The text sent becomes the report's entire notes, so first read the current notes with get_load_test_report and preserve the user's content in what you send.
update_monitor
ChatGPTReplace an existing Monitor's exposed configuration: name, Script, frequency, engine ids, failure and recovery thresholds, tags, and the acceptable-metric thresholds. An omitted threshold is cleared and omitted tags are removed, so read the current configuration with get_monitor first and send everything that should remain. Everything outside those fields is untouched: an update never changes whether the Monitor is enabled, and never touches its notification policies or maintenance windows, so a config edit cannot stop a running Monitor, start a stopped one, or unhook the user's alerting.
update_scenario
ChatGPTReplace an existing scenario's name and Populations — the populations given become the whole scenario, so to change one, send the others alongside it, each with the id get_scenario reported, or they are dropped and the ones you send are new populations. The same save rules and summary as create_scenario apply.
update_script
ChatGPTReplace an existing script's name, type, commands, and variables, creating a new revision. Every replace on this surface is a full replacement, not a merge, and every write against a user's existing data needs their explicit confirmation first.
validate_script
ChatGPTStructurally validate a list of commands for a bot type before saving or playing, reporting any issues by command index. Pass the script's variables as well and it also cross-checks the bindings against the ${...} and bot.getVariable reads in the commands, warning about a read nothing supplies, a binding nothing reads, and a per-occurrence variable read more than once in an iteration. Warnings never make a script invalid and never stop a save — all three are legal scripts.
