Loadster

Create Scenario

create_scenario

Create a scenario in a project — saving costs nothing and starts nothing. Launch it with launch_load_test at the "Read+Write+Execute" access level; below that level the tool is absent, and the user launches it from the Dashboard 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.

Input Schema

Name	Required	Description
`name`	Yes	The scenario name.
`tags`	No	Tag names; a name the team doesn't have yet becomes a new tag. Omit for no tags.
`projectId`	Yes
`populations`	Yes	The Populations, in order. Each needs a name, the scriptId of a script in this project, and stages — { target, duration, ramp } segments that run for duration milliseconds and reach target bots by the end, each starting from where the previous stage left off. Optional per population: id (send back the id get_scenario reported to keep a population's identity), engineId (an id from list_engines; defaults to the account's default region; loadEngineId is its deprecated alias), iterations, iterationsPerUser, aggressionMultiplier, and playbackOptions with connectionBps (bits per second), hostnameOverrides, and variableOverrides. Read get_documentation topic 'load-test-scenarios' for what stages and ramps do; list_engines carries the account's stage bounds and bot caps.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 30, 2026

changedInput schema / properties / populations / description

Previous value: -"The Populations, in order. Each needs a name, the scriptId of a script in this project, and stages — { target, duration, ramp } segments that run for duration milliseconds and reach target bots by the end, each starting from where the previous stage left off. Optional per population: id (send back the id get_scenario reported to keep a population's identity), loadEngineId (an id from list_engines; defaults to the account's default region), iterations, iterationsPerUser, aggressionMultiplier, and playbackOptions with connectionBps (bits per second), hostnameOverrides, and variableOverrides. Read get_documentation topic 'load-test-scenarios' for what stages and ramps do; list_engines carries the account's stage bounds and bot caps."New value: +"The Populations, in order. Each needs a name, the scriptId of a script in this project, and stages — { target, duration, ramp } segments that run for duration milliseconds and reach target bots by the end, each starting from where the previous stage left off. Optional per population: id (send back the id get_scenario reported to keep a population's identity), engineId (an id from list_engines; defaults to the account's default region; loadEngineId is its deprecated alias), iterations, iterationsPerUser, aggressionMultiplier, and playbackOptions with connectionBps (bits per second), hostnameOverrides, and variableOverrides. Read get_documentation topic 'load-test-scenarios' for what stages and ramps do; list_engines carries the account's stage bounds and bot caps."

addedInput schema / properties / populations / items / properties / engineId
```
Added value: +{
+  "type": "string"
+}
```

Changed1 schema field changedOct 28, 2026

addedInput schema / properties / tags

Added value: +{
+  "description": "Tag names; a name the team doesn't have yet becomes a new tag. Omit for no tags.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

First observedSep 9, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing that the save is non-triggering, the exact refusal conditions (unknown engineId, too-short stage, exceeded bot/population caps) and that refusals name the limit. It also clarifies the subtle launchBlockers semantics — that blockers do not prevent the save and should be reported rather than worked around. Missing only rate/idempotency-style context, though idempotentHint=false already signals repeated calls create duplicates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the critical fact (no cost, no execution) and then layers permission, failure modes, and blocker semantics in a logical order. Some sentences are long and pack multiple clauses, but essentially every sentence carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the three things an agent most needs for a non-idempotent create with no output schema: authorization, validation failure behavior, and how to interpret the returned summary (launchBlockers). It never describes the returned scenario object itself, which is a modest gap for a create tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Top-level description covers none of the required parameters directly, but it adds real constraints the schema doesn't: engineId must be one list_engines offers, stage length has a minimum, and the stage/ramp semantics are delegated to a named documentation topic. With 75% schema coverage doing the field-level work, this is a solid complement rather than a repeat.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Create a scenario in a project") and immediately bounds the effect with "saving costs nothing and starts nothing," which separates it from launch_load_test and update_scenario. An agent can identify the operation and its side-effect profile from the first clause alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent elsewhere for the launch step ("Launch it with launch_load_test") and states the access level required, plus what happens below that level (tool absent, user launches from Dashboard). This is genuine when-to-use/when-not guidance rather than implied context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Loadster tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Create Scenario

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources