Skip to main content
Glama

Create monitor

create_monitor

Create a monitor for an http, tcp, ping, dns, tls_cert, domain_expiry or heartbeat check. The check is run once before anything is saved and the result is shown to the user along with every setting it would apply; where the client can show a prompt, nothing is created unless they approve; otherwise the monitor is created on the token's scope and the trial result comes back with it. Bind it to alerts as you create it: pass channel_ids from list_notification_channels (this needs the channels:read scope), and if the org has no channel yet, say so rather than leaving a monitor that pages nobody. Leave regions unset unless the user named where they want the check to run from — omitted, it probes from the operator's default set, which is already the intended coverage; naming more regions than the plan allows is refused outright. Request headers and a request body can be set, but a credential must be referenced rather than pasted: write Bearer {{ my_key }} and call list_variables for the keys this org has. A URL carrying a username or password is refused, and browser flows cannot be created here — add those in the app. Not read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesWhat the operator will see in lists and alerts.
tagsNoAt most 50, each at most 50 characters.
checkYes
regionsNoProbe regions to run the check from, as ids from `list_regions`. Omit unless the user named the places they want covered: omitting takes the regions `list_regions` flags `default_selected`, which is the coverage the operator chose, capped at the plan's region cap and falling back to the control plane's own region when nothing is flagged. A vantage point can be offered without being on by default, so the full catalog is not the thorough answer. Rejected for a heartbeat, which is pinged rather than probed, and a set larger than a `max_regions` `list_regions` reports is refused outright, not trimmed to fit.
group_nameNoOperator-side grouping label.
channel_idsNoChannel ids from `list_notification_channels` to alert. Omitting them creates a monitor that pages nobody, which is worth saying out loud rather than leaving for an outage to reveal. The channels themselves are set up in the app, since they hold the tokens and addresses.
interval_secsNoSeconds between checks, held to the plan's floor and the check kind's own floor. Omit it to get the cadence the app's own picker opens this kind at, which is well above the hard minimum for the slow-moving kinds: a certificate is checked twice a day, a domain registration daily.
region_policyNoDetection quorum across probe regions.
notify_recoveryNoWhether recovery is announced. Defaults to true.
alert_confirmationsNoConsecutive failing checks before the monitor alerts. Minimum 1, defaults to 2.
renotify_interval_secsNoSeconds before the first reminder while an outage stays unacknowledged; each further reminder waits twice as long, up to a day. 0 turns reminders off; otherwise at least 60. Defaults to 3600.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
nameYes
probeNoThe trial run's outcome, which the operator saw before approving. Absent for a heartbeat, which has nothing to probe.
alertsYesThe channels this monitor will alert, by name, or `nobody` when nothing reaches it. One covered by a channel's tag rule rather than a binding is marked `by tag`. A channel that cannot deliver says so here.
addressYesWhat the check watches, as stored.
regionsYesProbe regions the monitor was assigned, which is the operator's default set when `regions` was omitted. Empty for a heartbeat.
interval_secsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations are sparse (only readOnly=false, idempotent=false, destructive=false), so the description carries the burden of behavioral disclosure. It excellently covers the trial-run-before-save behavior, the conditional approval prompt, the creation on token scope when no prompt is possible, refusal behaviors (credential in URL, too many regions, browser flows), and credential reference requirements. It does not explicitly mention rate limits or whether the operation is idempotent, but the annotations already signal idempotent=false, and the trial-run behavior is thoroughly described.

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?

The description is a single dense paragraph that front-loads the primary purpose and then layers important caveats. Every sentence earns its place, but the length is substantial and could be lightly structured (e.g., bullet points) to aid scanning. Still, there is no fluff; the density is justified by the number of important behavioral caveats.

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?

Given the complexity of this tool (11 parameters, 7 check types, multiple behavioral constraints), the description plus the rich schema covers everything an agent needs: creation semantics, approval flow, alert binding, region policy, credential handling, and exclusions. The output schema exists and the parameter schema is 91% covered, so the description need not enumerate return values or every parameter. The combination is complete enough for correct invocation.

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?

Schema description coverage is 91%, so the schema already documents most parameters well. The description adds semantic value on top of the schema by clarifying the channel_ids consequence ('paging nobody'), the regions default-selected behavior, the credential-reference rule, and the browser-flow exclusion. It doesn't need to repeat every parameter because the schema covers them; the marginal additions are meaningful.

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 clearly states the verb ('Create') and the resource ('a monitor'), enumerates the supported check types (http, tcp, ping, dns, tls_cert, domain_expiry, heartbeat), and differentiates from siblings like update_monitor and create_monitors. It also specifies a key behavioral scope — the trial run before saving and approval-based creation — which sharply distinguishes this from a naive 'create' tool.

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?

The description provides explicit guidance on when to use the tool and how to behave in specific scenarios: pass channel_ids from list_notification_channels, warn when the org has no channels, leave regions unset unless the user named locations, use list_variables for credential references, refuse URLs with embedded credentials, and direct browser flows to the app. This is exemplary usage guidance.

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.