loadster

Name: loadster
Author: loadster

Load testing and synthetic monitoring for websites, web apps, and APIs.

От сообществаРаботаетБез входаГлобальныйБесплатноМожет изменять данные

Что умеет

Get Screenshot: Fetch a screenshot captured during a play as a viewable image. Use the screenshotKey from a step in get_play_status.
Get Command Schema: 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
Get Example: Get a small, valid worked example script for a bot type to use as a starting point.

Какие данные видит

Нужен ли аккаунт

Не нужен: сервер работает без входа

Load testing and synthetic monitoring for websites, web apps, and APIs. Run tests with Playwright, Browser Bots, and Protocol Bots. Agents using the MCP can create and play test scripts, prepare load tests, analyze test results, set up monitors, and more.

Список инструментов сервера (55)

Технические названия из tools/list. Нужны только разработчикам.

get_screenshot	Fetch a screenshot captured during a play as a viewable image. Use the screenshotKey from a step in get_play_status.
get_command_schema	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_example	Get a small, valid worked example script for a bot type to use as a starting point.
get_scripting_api	List the scripting API scopes (bot, http, browser, ...) available in code blocks, or fetch one scope's members with their signatures and docs.
get_variable_schema	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.
list_command_types	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.
validate_script	Structurally 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.
append_dataset_rows	Add 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	Create 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.
delete_dataset	Delete a dataset from a project.
get_dataset	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.
list_datasets	List the datasets in a project with their id, name, and row/column counts (without the full value table).
update_dataset	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.
list_engines	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.
submit_feedback	Send the Loadster team your account of how a task on this surface went. Call it once your task is complete and you have played or otherwise verified the result, whether the task succeeded or not. The team reads this feedback and fixes what the surface got wrong, so write what worked, what was missing or confusing, and what you had to work around. Feedback is at most 2000 characters; a longer submission is rejected rather than truncated.
get_documentation	List the Loadster manual's topics with their keys and URLs, or read up to 3 topics' text by key.
create_monitor	Create 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.
delete_monitor	Delete 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.
disable_monitor	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.
get_incident	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_monitor	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_cycle_detail	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_monitoring_summary	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.
list_incidents	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_monitor_cycles	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_monitoring_locations	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_monitors	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.
update_monitor	Replace 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.
get_load_test_report	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.
list_load_tests	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.
update_load_test_notes	Replace 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.
create_scenario	Create 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.
delete_scenario	Delete a scenario from a project. The scripts its populations referenced are left alone.
get_scenario	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.
list_scenarios	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.
update_scenario	Replace 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.
create_script	Create 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_script	Delete a script from a project.
delete_script_asset	Delete a file attached to a script.
duplicate_script	Duplicate a script, optionally with a new name and into another project the token can access. Returns the copy's summary.
get_play_status	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_script	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_asset	Read a script asset's content as base64.
get_script_revision	Get a specific past revision of a script, including its commands, so you can inspect or diff it.
get_step_detail	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.
import_script	Import an open-source load test (JMeter .jmx, k6 .js, or Locust .py) into an existing script, converting it to Loadster commands. Returns action items to review. For OpenAPI/Swagger or Postman, read the spec yourself and build commands with create_script instead.
list_projects	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_script_assets	List the files attached to a script (request bodies, upload files, Playwright support files). Each path is the key a command references.
list_script_revisions	List a script's past revisions (newest first) with version, save time, author, and step count.
list_scripts	List the scripts in a project with their id, name, bot type, step count, and current revision version (without the full command list).
play_script	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.
put_script_asset	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.
restore_script_revision	Restore a script to a past revision, saving that revision's commands as a new revision.
stop_script	Stop a running play. Errors if the run does not exist; once the stop takes effect, get_play_status reports the run as stopped.
update_script	Replace 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.