Loadster

com.loadster/loadster-mcpVersion 2.2.1

Load testing and synthetic monitoring platform: test with Playwright, Browser Bot, or Protocol Bots.

Status

Responds356 msNov 14, 2026, 14:04 UTCAnswered our handshake without sign-in.

Registry data may be out of date

We could not refresh it, so this page shows the last copy.

Last checked: Nov 14, 2026, 14:04 UTC
Latency: 356 ms
Remotes responding: 1 of 1
Sign-in: No sign-in
Hosting: Hosted outside the EU (detected)
Registry data as of: Nov 14, 2026, 22:14 UTC

Data from the official MCP Registry, checked by run.zero. How we check

Connect

Streamable HTTP

https://api.loadster.com/mcpResponds356 msNov 14, 2026, 14:04 UTC

No sign-in

Claude Code

claude mcp add --transport http loadster-mcp https://api.loadster.com/mcp

Claude Desktop and claude.ai

1
2
3

Settings > Connectors > Add custom connector
Name: loadster-mcp
Remote MCP server URL: https://api.loadster.com/mcp

Cursor

{
  "mcpServers": {
    "loadster-mcp": {
      "url": "https://api.loadster.com/mcp"
    }
  }
}

VS Code

code --add-mcp '{"name":"loadster-mcp","type":"http","url":"https://api.loadster.com/mcp"}'

Built your own server? run.zero hosts MCP servers on European infrastructure.

Host your own MCP server on run.zero

Tools

62 tools

Tools of Loadster
	Description		Read-only	Idempotent	Open world
`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.	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.	No	No	No	No
`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.	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.	No	No	No	No
`create_monitor`Create a Monitor in a project, initially disabled. An enabled Monitor runs on its schedule, unattended. Its Cycles burn Fuel unless the account has a plan that includes monitoring, which covers them up to its limits. Enable it with enable_monitor at the "Launch" access level; below that level a call is refused, and the user enables it in the Dashboard at the link the returned summary carries. Read the 'monitoring' topic before choosing a frequency or thresholds.	Create a Monitor in a project, initially disabled. An enabled Monitor runs on its schedule, unattended. Its Cycles burn Fuel unless the account has a plan that includes monitoring, which covers them up to its limits. Enable it with enable_monitor at the "Launch" access level; below that level a call is refused, and the user enables it in the Dashboard at the link the returned summary carries. Read the 'monitoring' topic before choosing a frequency or thresholds.	No	No	No	No
`create_project`Create a project for the connected team and return its id, name, and dashboard link. 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.	Create a project for the connected team and return its id, name, and dashboard link. 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.	No	No	No	No
`create_scenario`Create a scenario in a project — saving costs nothing and starts nothing. Launch it with launch_load_test at the "Launch" access level; below that level a call is refused, and the user launches it from the Dashboard at the link. The save is refused for an engineId 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 a scenario in a project — saving costs nothing and starts nothing. Launch it with launch_load_test at the "Launch" access level; below that level a call is refused, and the user launches it from the Dashboard at the link. The save is refused for an engineId 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.	No	No	No	No
`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. HTTP is a Protocol Bot script, BROWSER is a Browser Bot script, and PLAYWRIGHT is a Playwright script. "Browser script" is ambiguous: Browser Bot and Playwright are different types, so if the user's wording doesn't say which, ask before creating. Don't create multiple scripts of the same type for one task. Edit and reuse a script you created earlier in the session (same type, created by you, not used in a scenario or monitor elsewhere) instead of making a new one for a probe or a retry. 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.	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. HTTP is a Protocol Bot script, BROWSER is a Browser Bot script, and PLAYWRIGHT is a Playwright script. "Browser script" is ambiguous: Browser Bot and Playwright are different types, so if the user's wording doesn't say which, ask before creating. Don't create multiple scripts of the same type for one task. Edit and reuse a script you created earlier in the session (same type, created by you, not used in a scenario or monitor elsewhere) instead of making a new one for a probe or a retry. 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.	No	No	No	No
`delete_dataset`Delete a dataset from a project.	Delete a dataset from a project.	Yes	No	No	No
`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, which needs the "Launch" access level; below that level the user disables the Monitor in the Dashboard. Never delete a Monitor just to stop it.	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, which needs the "Launch" access level; below that level the user disables the Monitor in the Dashboard. Never delete a Monitor just to stop it.	Yes	No	No	No
`delete_scenario`Delete a scenario from a project. The scripts its populations referenced are left alone.	Delete a scenario from a project. The scripts its populations referenced are left alone.	Yes	No	No	No
`delete_script`Delete a script from a project.	Delete a script from a project.	Yes	No	No	No
`delete_script_asset`Delete a file attached to a script.	Delete a file attached to a script.	Yes	No	No	No
`disable_monitor`Disable a Monitor, stopping its scheduled Cycles and the Fuel or plan usage they bring; disabling closes the Monitor's open Incidents. Idempotent. Disabling, and enabling again with enable_monitor, both need the "Launch" access level; below that level a call is refused, and the user disables or re-enables the Monitor in the Dashboard at the link get_monitor returns.	Disable a Monitor, stopping its scheduled Cycles and the Fuel or plan usage they bring; disabling closes the Monitor's open Incidents. Idempotent. Disabling, and enabling again with enable_monitor, both need the "Launch" access level; below that level a call is refused, and the user disables or re-enables the Monitor in the Dashboard at the link get_monitor returns.	No	No	Yes	No
`duplicate_script`Duplicate a script, optionally with a new name and into another project the token can access. Returns the copy's summary.	Duplicate a script, optionally with a new name and into another project the token can access. Returns the copy's summary.	No	No	No	No
`enable_monitor`Enable a disabled Monitor so its Cycles run on its schedule. Enabling starts a Cycle at once, and the result's startedCycleId names it; startedCycleId is absent when no Cycle started, because the Monitor was already enabled, recent Cycles reached the limit on immediate Cycles, or the start failed. An enabled Monitor runs Cycles unattended until disable_monitor stops it. Its Cycles burn Fuel unless the account has a plan that includes monitoring, which covers them up to its limits; get_documentation topic 'faqs/plan-or-fuel' explains how. Enable only after the user confirms in this conversation. Idempotent: on an enabled Monitor it changes nothing, starts no Cycle, and returns the current state. An unclaimed Trial is refused until the user creates an account.	Enable a disabled Monitor so its Cycles run on its schedule. Enabling starts a Cycle at once, and the result's startedCycleId names it; startedCycleId is absent when no Cycle started, because the Monitor was already enabled, recent Cycles reached the limit on immediate Cycles, or the start failed. An enabled Monitor runs Cycles unattended until disable_monitor stops it. Its Cycles burn Fuel unless the account has a plan that includes monitoring, which covers them up to its limits; get_documentation topic 'faqs/plan-or-fuel' explains how. Enable only after the user confirms in this conversation. Idempotent: on an enabled Monitor it changes nothing, starts no Cycle, and returns the current state. An unclaimed Trial is refused until the user creates an account.	Yes	No	Yes	Yes
`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 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.	No	Yes	Yes	No
`get_dataset`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 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.	No	Yes	Yes	No
`get_documentation`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.	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.	No	Yes	Yes	No
`get_example`Get a small, valid worked example script for a bot type to use as a starting point.	Get a small, valid worked example script for a bot type to use as a starting point.	No	Yes	Yes	No
`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 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.	No	Yes	Yes	No
`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, 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 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.	No	Yes	Yes	No
`get_load_test_status`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 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.	No	Yes	Yes	No
`get_load_test_url_timings`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 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.	No	Yes	Yes	No
`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. To start a disabled Monitor, call enable_monitor at the "Launch" access level; below that level a call is refused, and the user enables it in the Dashboard at the link. The 'monitoring' topic covers what a Monitor's configuration should be.	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 "Launch" access level; below that level a call is refused, and the user enables it in the Dashboard at the link. The 'monitoring' topic covers what a Monitor's configuration should be.	No	Yes	Yes	No
`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 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.	No	Yes	Yes	No
`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.	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.	No	Yes	Yes	No
`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 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.	No	Yes	Yes	No
`get_scenario`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 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.	No	Yes	Yes	No
`get_screenshot`Fetch a screenshot captured during a play as a viewable image. Use the screenshotKey from a step in get_play_status.	Fetch a screenshot captured during a play as a viewable image. Use the screenshotKey from a step in get_play_status.	No	Yes	Yes	No
`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 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.	No	Yes	Yes	No
`get_script_asset`Read a script asset's content as base64.	Read a script asset's content as base64.	No	Yes	Yes	No
`get_script_revision`Get a specific past revision of a script, including its commands, so you can inspect or diff it.	Get a specific past revision of a script, including its commands, so you can inspect or diff it.	No	Yes	Yes	No
`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.	List the scripting API scopes (bot, http, browser, ...) available in code blocks, or fetch one scope's members with their signatures and docs.	No	Yes	Yes	No
`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.	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.	No	Yes	Yes	No
`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.	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.	No	Yes	Yes	No
`import_script`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 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.	Yes	No	No	No
`launch_load_test`Launch a saved Scenario as a Load Test, exactly as stored. Its Populations send real traffic to the user's site. Like the Dashboard's Launch button, it runs on the account's plan when get_scenario shows no Fuel estimate and runs the whole test on Fuel when it shows one. Read the Scenario with get_scenario first, tell the user the Fuel estimate range and the fuelBalance, or that the plan covers it when there is no estimate, and launch only with the user's approval. If the plan can't run the test right now, the refusal gives the reason and burns no Fuel, and the user can try to launch from the Dashboard instead. If the call times out, check list_load_tests before launching again. A Scenario with launchBlockers is refused, and the refusal lists them. Trial, plan, Fuel and other checks apply as in the Dashboard, and a refusal carries their message. The result carries the new Load Test's id, its stage and the Dashboard link; follow it with get_load_test_status and stop it with stop_load_test.	Launch a saved Scenario as a Load Test, exactly as stored. Its Populations send real traffic to the user's site. Like the Dashboard's Launch button, it runs on the account's plan when get_scenario shows no Fuel estimate and runs the whole test on Fuel when it shows one. Read the Scenario with get_scenario first, tell the user the Fuel estimate range and the fuelBalance, or that the plan covers it when there is no estimate, and launch only with the user's approval. If the plan can't run the test right now, the refusal gives the reason and burns no Fuel, and the user can try to launch from the Dashboard instead. If the call times out, check list_load_tests before launching again. A Scenario with launchBlockers is refused, and the refusal lists them. Trial, plan, Fuel and other checks apply as in the Dashboard, and a refusal carries their message. The result carries the new Load Test's id, its stage and the Dashboard link; follow it with get_load_test_status and stop it with stop_load_test.	Yes	No	No	Yes
`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.	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.	No	Yes	Yes	No
`list_datasets`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 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.	No	Yes	Yes	No
`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 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 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.	No	Yes	Yes	No
`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 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.	No	Yes	Yes	No
`list_load_tests`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 "Launch" access level; below that level a call to either is refused 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 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 "Launch" access level; below that level a call to either is refused 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.	No	Yes	Yes	No
`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 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.	No	Yes	Yes	No
`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 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.	No	Yes	Yes	No
`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. 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 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.	No	Yes	Yes	No
`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. 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 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.	No	Yes	Yes	No
`list_scenarios`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 "Launch" access level; below that level a call is refused, 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 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 "Launch" access level; below that level a call is refused, 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.	No	Yes	Yes	No
`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 the files attached to a script (request bodies, upload files, Playwright support files). Each path is the key a command references.	No	Yes	Yes	No
`list_script_revisions`List a script's past revisions (newest first) with version, save time, author, and step count.	List a script's past revisions (newest first) with version, save time, author, and step count.	No	Yes	Yes	No
`list_scripts`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 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.	No	Yes	Yes	No
`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.	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.	No	No	No	Yes
`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.	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.	Yes	No	No	No
`restore_script_revision`Restore a script to a past revision, saving that revision's commands as a new revision.	Restore a script to a past revision, saving that revision's commands as a new revision.	No	No	No	No
`stop_load_test`Stop a Load Test. By default the stop is graceful, as the Dashboard's Stop button does: each bot finishes the iteration it is on before it stops, so the last iterations complete and are reported in full. With immediate set to true the Load Test is killed instead: bots stop mid-iteration, cutting their last iterations short, and the test ends sooner. Stop gracefully unless the user asks to kill the test or the target needs relief now; a Load Test already STOPPING gracefully can still be killed with immediate. A running Load Test moves to STOPPING and then ends; one that has not started yet is canceled either way. A Load Test that has already ended is refused. The result carries its stage after the stop; follow it with get_load_test_status, and read the Test Report with get_load_test_report once it has finished.	Stop a Load Test. By default the stop is graceful, as the Dashboard's Stop button does: each bot finishes the iteration it is on before it stops, so the last iterations complete and are reported in full. With immediate set to true the Load Test is killed instead: bots stop mid-iteration, cutting their last iterations short, and the test ends sooner. Stop gracefully unless the user asks to kill the test or the target needs relief now; a Load Test already STOPPING gracefully can still be killed with immediate. A running Load Test moves to STOPPING and then ends; one that has not started yet is canceled either way. A Load Test that has already ended is refused. The result carries its stage after the stop; follow it with get_load_test_status, and read the Test Report with get_load_test_report once it has finished.	Yes	No	Yes	No
`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.	Stop a running play. Errors if the run does not exist; once the stop takes effect, get_play_status reports the run as stopped.	Yes	No	Yes	No
`submit_feedback`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.	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.	No	No	No	No
`update_dataset`Update an existing dataset. Each of name, values, and tags is optional: a field left out keeps its stored value, so a rename leaves the table alone. Values sent become the entire table, so send the complete table including every row you want to keep; an empty table clears the rows. To add rows, call append_dataset_rows instead.	Update an existing dataset. Each of name, values, and tags is optional: a field left out keeps its stored value, so a rename leaves the table alone. Values sent become the entire table, so send the complete table including every row you want to keep; an empty table clears the rows. To add rows, call append_dataset_rows instead.	Yes	No	No	No
`update_load_test_notes`Replace the notes on a finished Load Test's Test Report — the only thing on a Load Test this surface edits. 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.	Replace the notes on a finished Load Test's Test Report — the only thing on a Load Test this surface edits. 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.	Yes	No	Yes	No
`update_monitor`Update an existing Monitor's exposed configuration: name, Script, frequency, engine ids, failure and recovery thresholds, tags, and the acceptable-metric thresholds. Each is optional: a field left out keeps its stored value, and a list sent replaces the whole list, never merging into it. The thresholds object works the same way: left out, the limits stay as they are; sent, it replaces all of them, so a limit left out of it is cleared and an empty object clears every limit. Read the current configuration with get_monitor before changing the thresholds. 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. To start a disabled Monitor, call enable_monitor at the "Launch" access level; below that level a call is refused, and the user enables it in the Dashboard at the returned link.	Update an existing Monitor's exposed configuration: name, Script, frequency, engine ids, failure and recovery thresholds, tags, and the acceptable-metric thresholds. Each is optional: a field left out keeps its stored value, and a list sent replaces the whole list, never merging into it. The thresholds object works the same way: left out, the limits stay as they are; sent, it replaces all of them, so a limit left out of it is cleared and an empty object clears every limit. Read the current configuration with get_monitor before changing the thresholds. 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. To start a disabled Monitor, call enable_monitor at the "Launch" access level; below that level a call is refused, and the user enables it in the Dashboard at the returned link.	Yes	No	No	No
`update_project`Rename a project and return its id, name, and dashboard link. The project's scripts, scenarios and other contents stay as they are. A name that another project of the team already has is refused. Every write against a user's existing data needs their explicit confirmation first.	Rename a project and return its id, name, and dashboard link. The project's scripts, scenarios and other contents stay as they are. A name that another project of the team already has is refused. Every write against a user's existing data needs their explicit confirmation first.	No	No	Yes	No
`update_scenario`Update an existing scenario. Each of name, populations, and tags is optional: a field left out keeps its stored value. Populations sent replace the whole list, never merging into it, 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 an existing scenario. Each of name, populations, and tags is optional: a field left out keeps its stored value. Populations sent replace the whole list, never merging into it, 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.	Yes	No	No	No
`update_script`Update an existing script. Each of name, type, commands, variables, and tags is optional: a field left out keeps its stored value, an empty list clears that list, and a non-empty list replaces the whole list, never merging into it. A script's type cannot be changed: type, if sent, must match the script's bot type, so to switch types create a new script of the desired type instead. Sending commands or variables saves a new revision; a name or tags alone save no revision. Read the script with get_script before changing it, never rebuild it from list_scripts. Every write against a user's existing data needs their explicit confirmation first.	Update an existing script. Each of name, type, commands, variables, and tags is optional: a field left out keeps its stored value, an empty list clears that list, and a non-empty list replaces the whole list, never merging into it. A script's type cannot be changed: type, if sent, must match the script's bot type, so to switch types create a new script of the desired type instead. Sending commands or variables saves a new revision; a name or tags alone save no revision. Read the script with get_script before changing it, never rebuild it from list_scripts. Every write against a user's existing data needs their explicit confirmation first.	No	No	No	No
`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.	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.	No	Yes	Yes	No

Details

Registry status: Active
Published: Nov 13, 2026
Updated: Nov 13, 2026
Website: https://loadster.com/manual/mcp/⁠ (opens in a new tab)
Repository: https://github.com/loadster/loadster-mcp⁠ (opens in a new tab)
Categories (suggested): Browser automationSuggested categories are assigned automatically from the registry text and may be wrong. Verified operators can correct them.
GDPR: Not declared

Are you the operator? Claim this listing