Visual Sentinel

Change a monitor's visual check settings

vs_monitors_update_visual

DestructiveIdempotent

Turn visual checks on or off and change their region and settings: change threshold, summary threshold and daily or weekly summary email, interval, viewport, areas to ignore, and video and GIF handling. Only the fields sent change. Sign-in for a page behind a login is entered in the dashboard.

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": {
      "id": "<id>"
    },
    "name": "vs_monitors_update_visual"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Monitor id.
`visualConfig`	No	Visual check settings. threshold: percent of the page that must change before an alert (0 to 100). summaryThreshold: a smaller percent that sends no alert but lists the change in a summary email (null turns summaries off; it must be below threshold). summaryCadence: "weekly" or "daily" summary email. checkInterval: seconds between visual checks (900 to 86400). Also viewport { width, height }, fullPage, excludeSelectors (CSS selectors to ignore), pauseVideos, hideVideoEmbeds and hideGifs. Sign-in for a page behind a login is entered in the dashboard.
`visualRegion`	No	Where visual checks run: EU (default) or ASIA.
`visualEnabled`	No	true turns on visual checks (screenshots compared with the baseline).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 25, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations declare destructiveHint=true, idempotentHint=true and openWorldHint=true, and the description adds a genuinely non-obvious behavioral fact: the update is a partial merge where only supplied fields change, which matches the idempotent hint. The dashboard-only caveat for login-gated pages is also useful context not present in the schema. It stops short of warning what changing thresholds can do to alert volume, which matters for a destructive mutation.

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?

Two sentences, front-loaded with the action and then the field list, with the partial-update rule placed immediately after. Dense but every clause carries information; only the repeated enumeration of settings slightly overlaps the schema.

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?

With four parameters, a deep nested object, full schema coverage and no output schema, the description covers the action, the merge semantics and the one out-of-band limitation (login credentials via dashboard). It does not say whether the updated monitor is returned or how failures are reported, a minor gap given the destructive hint.

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 100% and the nested visualConfig description already documents threshold, summaryThreshold, summaryCadence and checkInterval in detail. The prose largely restates those field names rather than adding new meaning, so it earns the baseline 3 for a fully documented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 ('Turn visual checks on or off and change their region and settings') and enumerates the field families it governs. It clearly scopes the tool to visual-check settings, though it never distinguishes itself from close siblings like vs_monitors_update_basics or vs_monitors_bulk_update, leaving an agent to infer where visual settings end.

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

Usage Guidelines3/5

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

The line 'Only the fields sent change' gives a useful partial-update operating rule, but there is no explicit when-to-use guidance, no mention of prerequisites (e.g. the monitor's check method needing to be visual), and no routing to alternatives. Usage is implied rather than stated.

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

All Visual Sentinel 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.