Skip to main content
Glama
Sign In

Loadster

by com.loadster
OverviewDiscussionsAdmin

Update Monitor

update_monitor
Destructive

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 "Read+Write+Execute" access level; below that level the tool is absent, and the user enables it in the Dashboard at the returned link.

Input Schema

NameRequiredDescriptionDefault
nameNoThe new monitor name.
tagsNoTag names; a name the team doesn't have yet becomes a new tag. Omit to keep the current tags; send [] to clear them.
scriptIdNoThe id of the Script in this project the Monitor plays each Cycle.
engineIdsNoThe 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.
frequencyNoHow often a Cycle runs, in milliseconds: 60000 (one minute) to 86400000 (one day).
monitorIdYes
projectIdYes
thresholdsNoThe 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.
failureThresholdNoConsecutive failed Cycles before an Incident opens (1 to 128; default 1).
recoveryThresholdNoConsecutive passing Cycles before an open Incident closes (1 to 128; default 1).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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."
    • changedInput schema / required
      Previous value: -[
-  "projectId",
-  "monitorId",
-  "name",
-  "scriptId",
-  "frequency",
-  "engineIds"
-]New value: +[
+  "projectId",
+  "monitorId"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / tags / description
      Previous value: -"Tag names; a name the team doesn't have yet becomes a new tag. Omit or send [] to remove all tags."New value: +"Tag names; a name the team doesn't have yet becomes a new tag. Omit to keep the current tags; send [] to clear them."
  3. Changed1 schema field changed
    • 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 or send [] to remove all tags."
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing precise patch semantics: omitted fields retain stored values, lists are replaced wholesale rather than merged, and the thresholds object is replaced atomically so an omitted limit is cleared and {} clears everything. It also scopes the destructive surface, stating the update never alters enabled state, notification policies, or maintenance windows — consistent with destructiveHint=true without contradicting it.

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 field list and the replacement rule, which is the highest-value information. It runs long and the final enable_monitor/access-level sentence is dense, but nearly every sentence carries non-obvious mutation semantics rather than filler.

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

Completeness5/5

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

For a destructive, non-idempotent mutation with a nested object and no output schema, the description covers everything an agent needs: what changes, what is preserved, what is destroyed, the prerequisite read, and the correct sibling for the enable path. No meaningful gap remains.

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

Parameters5/5

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

Schema coverage is already 80%, but the description adds semantics the schema cannot express: optionality/keep-vs-replace behavior per field, whole-list replacement for tags and engineIds, and the replace-and-clear semantics of the nested thresholds object. That is genuine meaning beyond the structured fields, especially for the nested object.

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?

Specific verb+resource ("Update an existing Monitor's exposed configuration") followed by an enumeration of every mutable field, so the agent knows exactly the scope of change. It also distinguishes itself from create_monitor and delete_monitor by framing the operation as a partial edit of an existing resource.

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 to get_monitor before changing thresholds and to enable_monitor for starting a disabled Monitor, including the access-level condition under which enable_monitor is even available. It also states what should NOT be attempted here (enable/disable, notification policies, maintenance windows), which is exactly the when-not guidance the dimension asks for.

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

All Loadster toolsInspect
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.

Resources