Skip to main content
Glama

Update Monitor

update_monitor
Destructive

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe new monitor name.
tagsNoTag 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.
scriptIdYesThe id of the Script in this project the Monitor plays each Cycle.
engineIdsYesThe 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.
frequencyYesHow 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 is not checked; omit the whole object to check none.
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. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses the replace semantics: omitted thresholds are cleared, omitted tags are removed, and everything outside the listed fields is untouched. This gives the agent a precise model of side effects and prevents surprise data loss.

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

Conciseness5/5

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

Three dense sentences, front-loaded with the action and field list, then the critical clearing behavior, then the non-scope safety boundary. No filler, no repetition of the title, and every sentence earns its place.

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 10-parameter mutating tool with nested objects and no output schema, the description is complete: it identifies what is replaced, what is cleared if omitted, what to do before calling, and what is guaranteed not to change. An agent has enough information to decide when to call it and how to construct the request.

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?

Even with 80% schema coverage, the description adds critical update-specific meaning not fully captured by the schema: omitted threshold/tag behavior and the need to send the full intended configuration. The schema's per-parameter details are already strong, and the tool description fills the omission/replacement gaps.

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?

The description leads with 'Replace an existing Monitor's exposed configuration' and enumerates the exact fields: name, Script, frequency, engine ids, failure and recovery thresholds, tags, and acceptable-metric thresholds. The word 'existing' distinguishes it from create_monitor, and the statement that it never changes whether the Monitor is enabled separates it from disable_monitor.

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?

It explicitly directs the caller to 'read the current configuration with get_monitor first and send everything that should remain' because omitted thresholds are cleared and omitted tags are removed. It also states the when-not: it cannot stop a running Monitor, start a stopped one, or alter notification policies or maintenance windows, so it should not be chosen for those intents.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.