Skip to main content
Glama

Enterno.io Site Diagnostics

monitor_update

Idempotent

Change a monitor. Only the arguments sent change; null or "" clears an optional setting. Changing check_type resets the settings the new type does not use. A new url that would send the stored request headers, body or UDP payload to another host is refused (secret_host_change_unconfirmed) unless confirm_secret_host_change is true. While the owner's stored request headers stay, only the owner may change url, request_method or request_body (secret_scope_change_forbidden); anyone else sends request_headers anew or clears them.

Input Schema

NameRequiredDescriptionDefault
urlNoTarget. http/ssl/api: a URL (https:// is assumed); other types: a host. Private, reserved and unresolvable hosts are refused.
nameNoDisplay name. null or "" clears it.
noteNoPrivate note; "" empties it.
portNoport monitors: TCP port (default 80). udp monitors: UDP port, required.
tagsNoUp to 10 tags.
keywordNohttp only: text the body must (or must not) contain. null or "" clears it. Refused for api monitors, which do not check it: use assert_body there.
cache_bustNohttp/api: add enterno_nocache=<random> to the request URL on every check, so a CDN or cache cannot answer with a stored copy (default false). The stored url stays as it is. Refused for a url whose query carries a known signature or CDN token parameter. Does not guarantee the origin answers: a cache that ignores the query string still can.
check_typeNoDefault http on create. Switching type resets the settings the new type does not use.
group_nameNoGroup of the monitor, as «Set group» in the cabinet: up to 50 letters, digits, spaces, "_" and "-"; "" takes it out of its group. Business plan and above (plan_required otherwise).
monitor_idYesMonitor id from monitor_list
udp_expectNoudp monitors: bytes a reply must contain to count; null or "" accepts any reply.
udp_formatNoudp monitors: how udp_payload and udp_expect are written (default text; hex for binary protocols).
assert_bodyNoapi monitors: text the response must contain. null or "" clears it.
udp_packetsNoudp monitors: packets sent per check (default 3).
udp_payloadNoudp monitors, required: the datagram sent on every check, 1-512 bytes, as text or hex (udp_format). Never returned by these tools.
keyword_modeNo
notify_emailNo
request_bodyNoapi monitors: request body. Never returned by these tools. null or "" clears it.
assert_statusNoapi monitors: expected status, overriding expected_code. null clears it.
check_regionsNoRegion codes; those the plan does not include fall back to ru-msk.
expected_codeNoExpected HTTP status (default 200); 0 = any 2xx/3xx. 1-99 are refused.
request_methodNoapi monitors only.
udp_timeout_msNoudp monitors: wait for each reply, ms (default 1000).
dns_watch_typesNodns_change monitors: record types to watch (default A, MX, NS).
notify_telegramNo
request_headersNohttp/api: headers sent with every check. Write-only: never returned. {} or null clears them.
request_timeoutNohttp/api: seconds for the whole request, redirects included (default 15).
assert_body_caseNoapi monitors: whether assert_body must match letter case (default false: «OK» also matches «ok»). Ignored by other types.
follow_redirectsNohttp/api: whether a check follows redirects (at most 5, each hop checked before it connects). null: the type's rule — an http monitor follows unless it has request_headers, an api monitor does not. A monitor with request_headers or an api request_body follows only to the same host and port (or http to https): a redirect elsewhere is the answer.
interval_minutesNoCheck interval. Create raises it to the plan floor; update refuses a value below it.
udp_max_loss_pctNoudp monitors: share of packets that may go without a valid reply while the monitor stays up (default 50). At least one valid reply is always required.
show_on_status_pageNo
heartbeat_grace_minutesNoheartbeat monitors only: minutes a ping may be late before the monitor is down (default 0). Refused for other types.
confirm_secret_host_changeNoSet true only when the owner agrees that a new url may send this monitor's stored request headers, body or UDP payload to another host (or to the same host over plain http). Without it such a change is refused with secret_host_change_unconfirmed and nothing is written. Only the monitor's owner (a team monitor: the team's owner) may confirm; anyone else gets secret_host_change_forbidden. Each confirmation is recorded in the audit log and the owner gets an email about it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare this as non-read-only, idempotent, open-world and non-destructive. The description adds substantial behavioral context beyond those hints: partial-update behavior, reset behavior on check_type changes, secret_host_change_unconfirmed refusal, owner-only scope changes, audit logging and owner email notification.

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 front-loaded, dense and mostly free of waste. Its final sentence is long and packs several permission and secret-scope rules together, but each sentence carries operationally important information.

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 a 34-parameter update tool with no output schema, the definition covers the critical operational details an agent needs: partial updates, null-clearing behavior, type-switch resets, secret-host confirmation, owner restrictions and audit/email side effects. The detailed input schema handles individual parameter constraints.

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?

With 88% schema description coverage, parameter documentation is already strong. The description still adds useful cross-parameter meaning: only supplied arguments change, null or "" clears optional settings, check_type resets settings unused by the new type, and changing url can trigger secret-host protections around stored headers, body or UDP payload.

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 opens with a specific verb and resource: "Change a monitor." This clearly identifies an update operation and distinguishes it from sibling tools such as monitor_create, monitor_get, monitor_list, monitor_pause and monitor_resume.

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

Usage Guidelines4/5

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

It explains key update semantics: only sent arguments change, null/"" clears optional settings, and check_type changes reset incompatible settings. It also states when secret-host changes are refused or allowed, though it does not explicitly route the agent to sibling tools for create/get/pause/resume.

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.