Loadster

Create Monitor

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 "Read+Write+Execute" access level; below that level the tool is absent, 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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>",
      "name": "<name>",
      "scriptId": "<scriptId>",
      "frequency": "<frequency>",
      "engineIds": "<engineIds>"
    },
    "name": "create_monitor"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	The monitor name.
`tags`	No	Tag names; a name the team doesn't have yet becomes a new tag. Omit for no tags.
`scriptId`	Yes	The id of the Script in this project the Monitor plays each Cycle.
`engineIds`	Yes	The ids of the monitoring locations the Cycles run from, as list_monitoring_locations reports them; at least one is required. Monitoring locations are their own set, not the load test regions list_engines offers, and an unknown id is refused with an error naming the valid ones.
`frequency`	Yes	How often a Cycle runs, in milliseconds: 60000 (one minute) to 86400000 (one day).
`projectId`	Yes
`thresholds`	No	The acceptable-metric limits a Cycle is judged against, each optional within the object: responseTimeAverageMin/Max, responseTimeTotalMin/Max, cycleDurationMin/Max, timeToFirstByteMax, firstContentfulPaintMax, largestContentfulPaintMax, and totalBlockingTimeMax in milliseconds; cumulativeLayoutShiftMax as the unitless Web Vitals score; performanceScoreMin as the 0-100 floor. A limit left out of the object is not checked.
`failureThreshold`	No	Consecutive failed Cycles before an Incident opens (1 to 128; default 1).
`recoveryThreshold`	No	Consecutive passing Cycles before an open Incident closes (1 to 128; default 1).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

changedInput schema / properties / thresholds / description

Previous value: -"The acceptable-metric limits a Cycle is judged against, each optional within the object: responseTimeAverageMin/Max, responseTimeTotalMin/Max, cycleDurationMin/Max, timeToFirstByteMax, firstContentfulPaintMax, largestContentfulPaintMax, and totalBlockingTimeMax in milliseconds; cumulativeLayoutShiftMax as the unitless Web Vitals score; performanceScoreMin as the 0-100 floor. A limit left out is not checked; omit the whole object to check none."New value: +"The acceptable-metric limits a Cycle is judged against, each optional within the object: responseTimeAverageMin/Max, responseTimeTotalMin/Max, cycleDurationMin/Max, timeToFirstByteMax, firstContentfulPaintMax, largestContentfulPaintMax, and totalBlockingTimeMax in milliseconds; cumulativeLayoutShiftMax as the unitless Web Vitals score; performanceScoreMin as the 0-100 floor. A limit left out of the object is not checked."

Changed1 schema field changedOct 28, 2026

changedInput schema / properties / tags / description

Previous value: -"Tag names to organize the Monitor. Prefer the names other Monitors already carry, as list_monitors reports them — a name that doesn't exist yet becomes a new tag, so don't invent tags the user didn't ask for. Omit for no tags."New value: +"Tag names; a name the team doesn't have yet becomes a new tag. Omit for no tags."

First observedSep 9, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the agent knows this is a non-destructive, non-idempotent mutation. The description adds genuinely beyond that: the Fuel/billing consequence of enabling, the access-level gate, and the fact that the returned summary carries a Dashboard link. However, it does not state what happens on validation failure (e.g., duplicate names) or whether repeated calls create duplicates despite idempotentHint=false.

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-loaded with the core action and initial state, then prerequisites. No filler sentences, though the Fuel/billing sentence is dense and slightly longer than necessary for the agent's decision. Overall well-structured rather than bloated.

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?

For a 9-parameter mutation with nested thresholds and no output schema, the description covers the creation lifecycle, enablement path, and points to the returned summary's link. The remaining gap is result-shape specifics, but without an output schema that is acceptable. Nearly complete.

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

Parameters3/5

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

Schema description coverage is 89%, so the schema already documents projectId-adjacent fields, engineIds semantics, frequency ranges, thresholds, and failure/recovery thresholds in detail. The description adds only a pointer to the 'monitoring' topic for choosing frequency and thresholds, which does not add syntax or constraint detail beyond the schema. Baseline 3 applies.

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 Monitor in a project') plus the initial state ('initially disabled'), which distinguishes it cleanly from create_script, update_monitor, and enable_monitor. An agent knows exactly what object is produced.

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 names the follow-up tool (enable_monitor), the access level required ('Read+Write+Execute'), what happens below that level (tool absent, user enables via Dashboard link), and directs the agent to read the 'monitoring' topic before choosing frequency or thresholds. When-to-use, prerequisites, and alternatives are all covered.

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.