# Relvato (remote · app.relvato.com)

Website monitoring: add sites, configure and run monitors, read health, review results, apply fixes.

- Trust score: 88/100 (high trust)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-17

## Components

- remote · `app.relvato.com`: 88/100 (this document), [markdown](https://verifymcp.io/servers/com-relvato-relvato/api-mcp.md), [page](https://verifymcp.io/servers/com-relvato-relvato/api-mcp)

## Channel facts

- Endpoint: `https://app.relvato.com/api/mcp`
- Transports: `streamable-http`
- Auth: `required`
- Version: `3.2.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-17.

- **Endpoint Security**: 100/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC is configured correctly; the domain's records validate against the full chain to the root.
  - The authorisation server supports Client ID Metadata Documents, the current MCP client-registration mechanism.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 73/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 7853 tokens (~135/item across 58 items; 58 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 63/100
  - Stability observed for 19 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 97/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 91% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 59 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 60/100
  - Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28.

## Install

### How do I install the Relvato MCP server?

Relvato is a hosted endpoint at https://app.relvato.com/api/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http com-relvato-relvato 'https://app.relvato.com/api/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "com-relvato-relvato": {
      "url": "https://app.relvato.com/api/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-relvato-relvato": {
      "type": "http",
      "url": "https://app.relvato.com/api/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.com-relvato-relvato]
url = "https://app.relvato.com/api/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-relvato-relvato": {
      "type": "remote",
      "url": "https://app.relvato.com/api/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-relvato-relvato --url 'https://app.relvato.com/api/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-relvato-relvato:
    url: "https://app.relvato.com/api/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "com-relvato-relvato": {
      "Transport": "http",
      "Url": "https://app.relvato.com/api/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-relvato-relvato -t streamable-http -u 'https://app.relvato.com/api/mcp'
```

### Other

```json
{
  "mcpServers": {
    "com-relvato-relvato": {
      "type": "http",
      "url": "https://app.relvato.com/api/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-17 (score 88, 0)

- [security] The server rewrote its instructions, which are the text every model session reads
- [functional] Server version: 3.2.0 → 3.3.0
- [functional] New tool “bring_back_run”
- [cosmetic] “update_site_settings” added an optional parameter “aiTriage”

### 2026-10-16 (score 88, +1)

No change was recorded against any check on this day. Stability & Change Management went from 57 to 60. That category is still filling its 30-day observation window: 17 days of observed history at the previous scan, 18 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-14 (score 87, +1)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “apply_fix” rewrote its description, which is the text the model reads
- [security] Tool “start_safe_update” rewrote its description, which is the text the model reads

### 2026-10-13 (score 86, +1)

- [security improvement] DNSSEC: fail → pass

### 2026-10-12 (score 85, +1)

- [security] Tool “apply_fix” rewrote its description, which is the text the model reads
- [security] Tool “start_quarantine” rewrote its description, which is the text the model reads
- [security] Tool “start_safe_update” rewrote its description, which is the text the model reads

### 2026-10-10 (score 84, +1)

- [security] Tool “flag_visual_change_as_problem” rewrote its description, which is the text the model reads
- [security] Tool “get_run” rewrote its description, which is the text the model reads
- [security] Tool “get_site_health” rewrote its description, which is the text the model reads

### 2026-10-07 (score 83, +1)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “start_monitoring_for_goals” rewrote its description, which is the text the model reads
- [security] Tool “update_check_settings” rewrote its description, which is the text the model reads
- [security] Tool “verify_site” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 6481 → 7402
- [functional] Server version: 3.1.0 → 3.2.0
- [functional] New tool “add_heartbeat”
- [functional] New tool “list_heartbeats”
- [functional] New tool “update_heartbeat”
- [cosmetic] “update_check_settings” added an optional parameter “uptime”
- [cosmetic] “pause_monitor_group” reworded the description of “group”
- [cosmetic] “trigger_scan” reworded the description of “group”
- [cosmetic] “verify_site” reworded the description of “method”

### 2026-10-05 (score 82, 0)

- [security] Tool “update_check_settings” rewrote its description, which is the text the model reads
- [cosmetic] “update_check_settings” added an optional parameter “accessibilityPages”

## MCP tools (58)

### `list_sites` (~27 tokens)

List sites

List the websites in this Relvato account, with whether each is ready to run monitors.

### `add_site` (~167 tokens)

Add a site

Start monitoring a website. Returns the site and the setup step the owner must complete before any monitor runs: connect the WordPress plugin, or verify the domain (the only option for non-WordPress sites). If the account already has a site on the same domain, that site is returned instead of a duplicate. How ownership is proven: https://www.relvato.com/docs/verify-site-ownership

Input parameters:

- `name` (string): Display name (defaults to the domain)
- `platform` (string, required): "wordpress" for WordPress/WooCommerce (deepest monitors via the Relvato plugin); "other" for any other site or AI-built app (public-page monitors, domain verification).
- `url` (string, required): The site's address, e.g. https://example.com

### `verify_site` (~147 tokens)

Verify site setup

Check whether the site's ownership is proven: probes the WordPress plugin connection and/or looks for the domain-verification DNS TXT record / meta tag, or (method gsc / bing) asks Google Search Console / Bing Webmaster Tools. Returns the updated setup state. Docs: https://www.relvato.com/docs/verify-site-ownership

Input parameters:

- `method` (string): Domain verification only: check just this method (default: DNS and meta tag). gsc / bing ask Google Search Console / Bing Webmaster Tools whether the account connected to the site (in the dashboard)…
- `siteId` (string, required): The site id

### `start_monitoring_for_goals` (~95 tokens)

Set up monitors for goals

The onboarding shortcut: pick what matters and Relvato adds the monitors that cover it on the current plan (plus uptime, SSL, errors, maintenance mode and structure). Goals: flows (checkout and sign-in), security, search, design, compliance (law compliance — accessibility today), speed, domain, custom, ai.

Input parameters:

- `goals` (array, required)
- `siteId` (string, required): The site id

### `list_checks` (~55 tokens)

List available monitors

The monitors that can be added to a site: key, what it catches, whether the current plan allows it, whether it's recommended for this site, and whether it's already added.

Input parameters:

- `siteId` (string, required): The site id

### `add_checks` (~128 tokens)

Add monitors

Add monitors to a site by key (from list_checks). Each key reports added / exists / rejected with the reason (plan, active-monitor limit, needs the WordPress plugin). New monitors get a daily schedule on plans that run daily (Pro and up) and a weekly one on Free, plus a re-run when the site changes on Pro and up (WordPress plugin updates, or pushes via the GitHub App).

Input parameters:

- `keys` (array, required): Check keys, e.g. ["uptime", "ssl", "error-scan"]
- `siteId` (string, required): The site id

### `dismiss_recommendation` (~65 tokens)

Dismiss a recommended monitor

Stop recommending a monitor for a site (list_checks marks recommendations), or bring every dismissed recommendation back with restoreAll.

Input parameters:

- `key` (string): The monitor key to stop recommending
- `restoreAll` (boolean)
- `siteId` (string, required): The site id

### `calibrate_site` (~58 tokens)

Re-read the store

WordPress / WooCommerce: have Relvato read the store again (a product to buy, checkout type, guest checkout, currency) after the store changed. Runs in the background.

Input parameters:

- `siteId` (string, required): The site id

### `verify_vitals_beacon` (~53 tokens)

Verify the real-user beacon

Check that the real-user Web Vitals beacon is on the site (its homepage, or data already arriving). get_site_settings has the snippet to install.

Input parameters:

- `siteId` (string, required): The site id

### `site_overview` (~127 tokens)

Site overview

Plain-language health verdict for a site: what needs attention (real issues vs likely false positives), each monitor with its latest run and schedule, setup state, recommended monitors not yet added, and the account's run usage. On WordPress 6.9+ it also lists the site's AI abilities (WordPress Abilities API) from the latest exposure scan: which plugin registered each, whether AI assistants (MCP Adapter) or REST clients can use it, which ones anyone can run without signing in, and which can delete data.

Input parameters:

- `siteId` (string, required): The site id

### `get_site_health` (~118 tokens)

Get a site's health over time

How a site has been doing: the share of monitors passing now (the Overview's "Monitors passing") and each of the last 30 days, the trend over 28, 90 or 182 days, each monitoring group's briefing (what needs attention, its likely cause and fix), and — on paid plans — uptime from Relvato's own probes (availability % and incidents over 30 days).

Input parameters:

- `range` (number): Trend length in days (default 28)
- `siteId` (string, required): The site id

### `get_performance` (~85 tokens)

Get a site's performance

A site's speed: the performance summary, lab Core Web Vitals, real visitors' LCP / INP / CLS (p75, last 7 days against the 28 before, per page type and device), what slows it (the elements, images and scripts behind slow visits) and the top fixes with steps.

Input parameters:

- `siteId` (string, required): The site id

### `get_check` (~140 tokens)

Get a monitor's settings

One monitor in full: on/off, when it runs (schedule, time zone, re-runs on WordPress updates, random extra runs, and whether the plan allows them), its own settings (the visual monitor's pages with their keys, masks, devices, browsers and threshold; the checkout's product, coupon, shipping and field answers; extra pages to scan; …), which settings sections update_check_settings accepts for it, the findings the user ignored, an AI-authored monitor's goal, status, question and recipe steps, and its latest run.

Input parameters:

- `checkId` (string, required): The monitor's id (from site_overview or add_checks)

### `list_runs` (~168 tokens)

List runs

Recent runs, newest first, optionally for one site, one monitor or one status. Each has the monitor (checkId, checkName, and its key in `journey`), status, trigger, timing and its error / warning; get_run has the detail. For older runs pass `before` (the startedAt of the last run you got).

Input parameters:

- `before` (string): Only runs started before this time (ISO 8601): the next page
- `checkId` (string): Only runs of this monitor
- `limit` (number): Max runs, 1-100 (default 25)
- `siteId` (string): Only runs for this site id
- `status` (string): Only runs with this status (a failure the user resolved counts as passed)

### `get_run` (~148 tokens)

Get run details

One run in detail: status, error and warnings (each with its key for ignore_finding; ignored ones marked; one Relvato never fixes carries noFix — why, and what to do instead), each step, visual comparisons (each with its comparisonId, links to the screenshot, the baseline and the diff that work for 10 minutes, and whether a decision on it can be undone), metrics, the one-click fix the run proposes if any, and Relvato AI's suggestion once requested. Large metrics are compacted, never the findings: daily series become summaries and what was left out is listed in metricsTrimmed.

Input parameters:

- `runId` (string, required): The run id

### `get_fix_prompt` (~114 tokens)

Get the fix brief for a run

For a run that failed or found a problem: the same brief Relvato's own AI answers when the user clicks "Suggest a fix" — the site's detected stack, what the monitor verifies, what changed on the site just before, the exact error and findings, whether it was already failing earlier, and for Google / Bing Search the evidence that rules causes out. Use it as context to explain the likely cause and fixes; applying a fix stays with the user.

Input parameters:

- `runId` (string, required): The run id

### `get_updates` (~76 tokens)

Get a site's WordPress updates

WordPress sites: the safe auto-update policy and its recent windows (what was updated, rolled back or skipped, and why), plugin versions held back after a rollback, safe updates or deactivations Relvato made and their outcome, and the hardening settings that are on.

Input parameters:

- `siteId` (string, required): The site id

### `get_safe_update` (~43 tokens)

Get a safe update's progress

Follow a safe update or deactivation: applying → verifying → passed, or reverted with the monitors that broke.

Input parameters:

- `changeId` (string, required): From start_safe_update

### `get_quarantine` (~79 tokens)

Get quarantine mode

Quarantine mode (WordPress, paid plans): 48 hours of hourly security runs after a cleanup, with plugin updates paused. Whether it's available, on, until when, every change it saw (expected or not), which monitors it watches, the runs it would use, and past sessions.

Input parameters:

- `siteId` (string, required): The site id

### `get_activity_log` (~143 tokens)

Get the WordPress activity log

WordPress sites: who did what — sign-ins and failed sign-ins (with the network, not the full address), accounts and roles, application passwords, plugin / theme / core updates, setting and file edits, PHP errors and failed emails — newest first, within the plan's history (7 to 365 days).

Input parameters:

- `days` (number): How far back (up to the plan's history)
- `filter` (string)
- `limit` (number): Max events, 1-300 (default 100)
- `search` (string): Only events mentioning this (a username, a plugin)
- `siteId` (string, required): The site id

### `get_notifications` (~51 tokens)

Get notifications

The dashboard's notifications: failing monitors, a disconnected or outdated WordPress plugin, a silent real-user beacon, domain and ownership problems, safe updates that need a look, paused Slack or webhook alerts, and billing.

### `get_site_settings` (~109 tokens)

Get a site's settings

A site's Settings tab as values: what update_site_settings may change (name, request pacing, spacing between runs, firewall retry delay, flaky-monitor recovery streak, plugin rollback, counting Relvato's own visits in real-user data), what only the dashboard changes (browser identity, proxy, firewall allowlist token — never its value — GitHub, Google / Bing connections), the WordPress plugin's version, and the real-user beacon snippet.

Input parameters:

- `siteId` (string, required): The site id

### `get_alert_settings` (~100 tokens)

Get alert settings

Who is told about what: how often (instant, daily / weekly digest), the minimum severity, each channel (email, Slack, webhook — whether the plan includes it, whether it's set up, paused, and `on` = alerts actually go out on it), which sites are muted and which monitor types go to which channel (only channels that are on). Never includes webhook URLs or secrets. Changing them is done by the user in Alert settings.

### `get_status_pages` (~64 tokens)

Get status pages and client reports

Public status pages (title, public link, sites, on/off) and monthly client reports per site (on/off, how many recipients, last sent), plus the report branding. Never a report's private link or recipients' addresses. Edited in the dashboard's Agency page.

### `list_heartbeats` (~128 tokens)

List a site's heartbeats

A site's heartbeats — cron jobs, backups and scheduled tasks that check in by requesting their own URL: each one's state (new = waiting for its first ping, up, down), schedule (period + grace, in seconds), last ping, when the next is due at the latest, whether the plan covers it, recent missed or failed check-ins and pings, plus the account's heartbeats used / allowed. Full-access connections also get each ping URL (it's what the job requests; anyone with it can send pings).

Input parameters:

- `siteId` (string, required): The site's id

### `update_check` (~279 tokens)

Update a monitor

Turn a monitor on or off, or change when it runs: its schedule (up to weekly on Free, daily on Pro, hourly on Business, every 15 minutes on Agency), re-runs when the WordPress site changes (plugin, theme, core or WooCommerce updates; Pro and up) and random extra runs (Business and up). Only the fields you pass change. Its own settings (pages, URLs, checkout details) are changed with update_check_settings or update_visual_monitor.

Input parameters:

- `at` (string): Daily/weekly run time, HH:MM (24h)
- `checkId` (string, required): The monitor's id (from site_overview or add_checks)
- `dow` (number): Weekly only: weekday, 0 = Sunday … 6 = Saturday
- `enabled` (boolean): Turn the monitor on or off
- `events` (array): WordPress sites only: re-run when these change. [] = none. A monitor's built-in triggers (e.g. the admin roster's role changes) are kept.
- `random` (object|null): Random extra runs (times per days), with an off or weekly schedule; null turns them off
- `schedule` (string): Recurring schedule
- `tz` (string): IANA timezone for `at`, e.g. Europe/Berlin

### `pause_monitor_group` (~202 tokens)

Pause a monitoring group

Pause one monitoring group on a site for 1 hour, 24 hours or until resumed (maintenance, a redesign, a migration). The group's monitors that are on are switched off and remembered; when the time is up, or with resume_monitor_group, exactly those are switched back on, as far as the plan allows. Pausing a group that's already paused changes when it resumes. Pausing Security while the site is in quarantine stays in the dashboard. Tell the user which monitors stop watching and for how long, and get their go-ahead first. site_overview lists paused groups.

Input parameters:

- `duration` (string, required): How long: 1 hour, 24 hours, or until resumed
- `group` (string, required): The monitoring group: uptime = uptime, heartbeats and port monitors; flow = user flows; security; design; performance; seo; domain; compliance = legal compliance (accessibility)
- `siteId` (string, required): The site id

### `resume_monitor_group` (~81 tokens)

Resume a monitoring group

Resume a paused monitoring group now: the monitors its pause switched off go back on (a monitor the plan no longer allows stays off, with the reason in keptOff). A group that isn't paused is left as it is.

Input parameters:

- `group` (string, required): The paused group (site_overview pausedGroups)
- `siteId` (string, required): The site id

### `update_visual_monitor` (~276 tokens)

Change the visual monitor's pages

Edit the visual regression monitor: add pages (a built-in one by key, or a page of your own by its address on the site, e.g. "/pricing"; up to 10 of your own), rename or re-point a page of your own, change any page's masks (CSS selectors painted over before comparing, for clocks, carousels, ads), remove pages, and set devices, browsers, full-page capture, the change threshold (percent) and the AI review. A page whose masks or address change gets a new baseline: its next run captures one for the user to approve. At most 40 screenshots a run (pages × devices × browsers). get_check lists the current pages and their keys.

Input parameters:

- `add` (array)
- `aiReview` (boolean): Let AI review a change before it alerts (default on)
- `browsers` (array)
- `checkId` (string, required): The visual regression monitor's id
- `devices` (array)
- `fullPage` (boolean): Capture the whole page (default) or only the first screen
- `remove` (array): Keys of pages to stop checking
- `thresholdPercent` (number): How much of a page may change before it counts, 0-50 (default ~1)
- `update` (array)

### `update_check_settings` (~480 tokens)

Change a monitor's settings

Change a monitor's own settings. Each monitor takes only its sections (get_check lists them as editable.sections): checkout (checkout monitors), devices (flow and page monitors), errorScan, brokenLinks, accessibilityPages (accessibility), uptime (the URL, text that must / must not appear, accepted statuses, timeout, alert after N minutes, maintenance windows, an API endpoint's method / body / JSON rules), aiOutput, browseUrl (storefront), shopUrl / productUrl (prices), dkimSelectors (email authentication), structurePages (structure drift), webVitalsDevices (Core Web Vitals). Every address must be a full URL on the site's own domain. A section you pass replaces that section; the rest stays. Turning it on or off and its schedule: update_check. The visual monitor: update_visual_monitor.

Input parameters:

- `accessibilityPages` (array): Accessibility: extra pages to test on top of the key pages (full URLs on the site, up to 20). A new page's issues are reviewed on its first scan, not failed
- `aiOutput` (object): The site's own AI feature: its endpoint (full URL on the site), a fixed prompt, and what the answer must (not) contain
- `brokenLinks` (object): Extra pages to crawl, address fragments to skip, and whether external links are checked too
- `browseUrl` (string): Storefront: the shop page (blank = the calibrated one)
- `checkId` (string, required): The monitor's id
- `checkout` (object): Checkout monitors
- `devices` (array): Flow and page monitors
- `dkimSelectors` (array): Email authentication: your mail provider's DKIM selectors (up to 10)
- `errorScan` (object): Extra pages to scan (full URLs on the site) and error texts to ignore
- `productUrl` (string): Prices: a sample product
- `shopUrl` (string): Prices: the shop page
- `structurePages` (array): Structure drift: pages to fingerprint
- `uptime` (object): Uptime: what the probes check and when they alert. The whole section is replaced: fields left out go back to their defaults (except maintenance, kept unless sent)
- `webVitalsDevices` (array): Core Web Vitals: devices to measure

### `add_custom_check` (~233 tokens)

Create a custom monitor

Describe in plain words what to verify on a page (e.g. "the Pro plan shows a price", "search for 'shoes' returns results") and Relvato's AI writes a monitor for it, in a minute or two. Follow it with get_check: status goes authoring → proposed (show the user its rationale and steps, then approve_custom_check) or needs-input (answer with reauthor_custom_check) or failed (with advice). Read-only by default; interactive: true lets it click and type (search, filters, forms). Plan-gated; counts toward the active-monitor limit.

Input parameters:

- `authenticated` (boolean): WordPress sites: run logged in as Relvato's verification user
- `goal` (string, required): What must be true on that page, in plain words
- `interactive` (boolean): Allow clicking and typing on the live page
- `name` (string): A name for the monitor (defaults to the goal)
- `siteId` (string, required): The site id
- `url` (string, required): The page to check: a full URL on the site

### `edit_custom_check` (~114 tokens)

Change a custom monitor

Give a custom monitor a new goal, page, name or mode. Its current recipe is dropped and the AI writes a new one, which needs approving again before the monitor runs.

Input parameters:

- `authenticated` (boolean)
- `checkId` (string, required): The custom monitor's id
- `goal` (string, required): What must be true on that page
- `interactive` (boolean)
- `name` (string): A new name
- `url` (string, required): The page to check: a full URL on the site

### `reauthor_custom_check` (~85 tokens)

Rewrite a custom monitor's recipe

Have the AI write a custom monitor's recipe again: answer its question (status needs-input) with `answer`, or retry after it failed or went stale. The monitor stops running until the new recipe is approved.

Input parameters:

- `answer` (string): Your reply to the AI's question (get_check custom.question)
- `checkId` (string, required): The custom monitor's id

### `approve_custom_check` (~104 tokens)

Approve a custom monitor

Approve a custom monitor's proposed recipe (status proposed) so it runs and alerts from now on. Show the user its rationale and steps first (get_check). A recipe in interactive mode clicks or types on the live site: approve it only after the user agrees, with ack: true.

Input parameters:

- `ack` (boolean): Required for an interactive recipe: the user agreed it may act on the live site
- `checkId` (string, required): The custom monitor's id

### `update_site_settings` (~338 tokens)

Change a site's settings

Change a site's operational settings. Only the fields you pass change. Browser identity, the proxy, the firewall token, GitHub and search-engine connections, and deleting the site stay in the dashboard.

Input parameters:

- `aiTriage` (string): Relvato AI triage of failed runs: label = each failure labelled needs attention / likely noise / repeat; hold = also hold back the instant alert of a confident likely-noise failure (never checkout, s…
- `challengeRetryMs` (number|null): Wait before retrying a run a firewall challenged, 0-3600000 ms; null = 10 minutes, 0 = never
- `jobSpacingMs` (number|null): Pause between this site's runs, 0-900000 ms; null/0 = none
- `name` (string): Display name
- `pacingMs` (number|null): Pause between a run's requests, 0-60000 ms; null = automatic
- `pluginRollback` (boolean): WordPress: roll a plugin update back when it breaks a monitor
- `recoverStreak` (number|null): Clean runs before a flaky monitor alerts again, 2-10; null = 5
- `rumIncludeOwnChecks` (boolean): Count Relvato's own visits in real-user Web Vitals
- `siteId` (string, required): The site id

### `update_alert_settings` (~173 tokens)

Change alert timing and severity

Change how often alerts are sent (instant and/or a daily or weekly digest), when the digest goes out, the minimum severity, and whether every run is emailed. Only the fields you pass change. Who gets alerts (the address, Slack, webhooks), muting sites or monitor types, and turning email alerts off stay in the dashboard.

Input parameters:

- `digestTime` (string): HH:MM (24h) for the daily / weekly digest
- `digestWeekday` (number): Weekly digest day, 0 = Sunday … 6 = Saturday
- `everyRun` (boolean): Email every run, not only problems
- `frequency` (array)
- `minSeverity` (string)
- `timezone` (string): IANA time zone for the digest, e.g. Europe/Berlin

### `add_heartbeat` (~355 tokens)

Add a heartbeat

Create a heartbeat for a job the user runs (cron job, backup script, scheduled task, CI job). Returns its ping URL: the job requests it when it succeeds (e.g. `your-job && curl -fsS -m 10 --retry 3 <pingUrl>`), and `<pingUrl>/fail` to report a failure (a POST body is kept with the ping). No ping within period + grace, or a failure, alerts the user at once; a new heartbeat waits for its first ping and never alerts before it. Adds the site's Heartbeats monitor with the first one. Plan limits per account: Free 2, Pro 20, Business 100, Agency 500.

Input parameters:

- `cron` (string): Instead of a period: the job's cron expression (five fields, e.g. "0 3 * * *" or "*/15 * * * 1-5"; @daily, @hourly … work too). A ping is then due by each time it fires plus the grace
- `graceSec` (number): How late a ping may be before it counts as missed, in seconds (60 to 604800 = 7 days; default 3600)
- `name` (string, required): What the job is, e.g. "Nightly backup"
- `periodSec` (number): How often the job runs, in seconds (60 to 2678400 = 31 days; default 86400 = daily). Ignored when `cron` is set
- `siteId` (string, required): The site's id
- `tz` (string): The cron expression's IANA time zone, e.g. Europe/Bucharest (default UTC)

### `update_heartbeat` (~209 tokens)

Update a heartbeat

Rename a heartbeat, change its period or grace, or pause / resume it. Only the fields you pass change. Paused: pings are still recorded but nothing is judged or alerted (an open outage ends without a "back" alert); resumed, it waits for its next ping. Deleting a heartbeat stays in the dashboard.

Input parameters:

- `cron` (string): A cron expression to use instead of the period ("" switches back to the period)
- `graceSec` (number): Grace time in seconds (60 to 604800)
- `heartbeatId` (string, required): The heartbeat's id (from list_heartbeats or add_heartbeat)
- `name` (string): New name
- `paused` (boolean): true pauses it, false resumes it
- `periodSec` (number): How often the job runs, in seconds (60 to 2678400); switches a cron schedule back to a period
- `tz` (string): The cron expression's IANA time zone

### `trigger_scan` (~193 tokens)

Run monitors now

Run a site's enabled monitors now — or one group of them (group), or one monitor with checkId, even if it's turned off. Each run counts toward the monthly run quota. Runs go one at a time and take from seconds to a few minutes each, so all of a site's monitors usually take several minutes: the result's estimatedMinutes and tellUser say how long, so tell the user to expect a wait. Returns the runIds to follow with get_run or list_runs; cancel_queued_runs stops the ones that haven't started.

Input parameters:

- `checkId` (string): Run only this monitor
- `group` (string): Run only this group's enabled monitors (as the dashboard's Run group): uptime = uptime, heartbeats and port monitors; flow = user flows; security; design; performance; seo; domain; compliance = legal…
- `siteId` (string, required): The site id

### `cancel_queued_runs` (~78 tokens)

Cancel queued runs

Stop a site's runs that are queued but haven't started (after a big trigger_scan, or before maintenance). Cancelled runs can't be brought back: start them again with trigger_scan. The run that's already going finishes; nothing already recorded is deleted. Get the user's go-ahead first.

Input parameters:

- `siteId` (string, required): The site id

### `request_ai_fix` (~86 tokens)

Ask Relvato AI for a fix

Ask Relvato's AI to suggest a fix for a run that failed or found a problem (the dashboard's "Suggest a fix"). It answers in a minute or two: read it as aiFix on get_run. Plan-gated. get_fix_prompt gives the same brief for you to reason with yourself, without waiting.

Input parameters:

- `runId` (string, required): The run id

### `apply_fix` (~185 tokens)

Apply a run's proposed fix

WordPress sites: apply the one-click fix a run proposes (get_run proposedFix: e.g. clear a stuck maintenance file, turn indexing back on, roll back the plugin update that broke it) through the Relvato plugin, then re-run the monitor to confirm. Only that exact fix can be applied. Tell the user what it changes (proposedFix.why and undo) and get their go-ahead first. undo: true reverts the last fix applied on the site. With Relvato plugin 1.77.0+ Relvato never changes the site remotely: the answer is applyInWordPress, a link where an administrator applies it in WordPress — give it to the user.

Input parameters:

- `runId` (string, required): The run that proposes the fix
- `undo` (boolean): Revert the last fix applied on this site instead

### `start_safe_update` (~178 tokens)

Safely update or deactivate a plugin

WordPress sites: for a vulnerable or outdated plugin a run found (get_run warnings with a plugin), update it (or deactivate it) through the Relvato plugin, re-run the monitors that were passing, and undo it if any of them breaks. Counts as runs. Follow it with get_safe_update. Get the user's go-ahead first. With Relvato plugin 1.77.0+ the change is made in WordPress by an administrator (answer: applyInWordPress, a link to give the user); Relvato verifies it, and if it breaks a monitor Relvato alerts the user to undo it there.

Input parameters:

- `action` (string, required)
- `plugin` (string, required): The plugin's slug (the finding's subject.slug)
- `runId` (string, required): The run that found the plugin

### `start_quarantine` (~100 tokens)

Start quarantine mode

After a hack or a cleanup (WordPress, paid plans): run the security monitors every hour for 48 hours, pause plugin updates (with Relvato plugin 1.77.0+ that pause is a tick box in WordPress → Relvato), and alert on every unexpected change. Uses runs (get_quarantine says how many). Stopping it early stays in the dashboard.

Input parameters:

- `siteId` (string, required): The site id

### `extend_quarantine` (~32 tokens)

Extend quarantine mode

Keep quarantine mode on for another 48 hours from now.

Input parameters:

- `siteId` (string, required): The site id

### `send_test_alert` (~52 tokens)

Send a test alert

Send a test alert on one channel (email, slack or webhook) to check it arrives. Slack and webhooks are on paid plans and must be set up in the dashboard.

Input parameters:

- `channel` (string, required)

### `resume_webhook` (~36 tokens)

Resume webhook alerts

Turn webhook alerts back on after Relvato paused them for repeated failed deliveries (fix the endpoint first; send_test_alert checks it).

### `report_false_positive` (~92 tokens)

Report a false positive

Tell Relvato's team a run's result is wrong (it failed or warned about something that's fine). Sends the run's details and your note to Relvato's support team; it changes nothing on the run. To stop being told about a finding, use ignore_finding.

Input parameters:

- `note` (string): What's wrong with the result (optional)
- `runId` (string, required): The run id

### `ignore_finding` (~100 tokens)

Ignore a finding

Stop a finding (a warning on a run, by its key from get_run) from counting on this monitor: it stays on the run, marked ignored, but no longer alerts or fails later runs. Undo with unignore_finding. Only do this when the user says the finding is expected.

Input parameters:

- `key` (string, required): The finding's key (get_run warnings[].key)
- `runId` (string, required): The run the finding is on

### `unignore_finding` (~75 tokens)

Stop ignoring a finding

Make an ignored finding count again (get_check lists a monitor's ignored findings with their keys; get_run marks them on a run).

Input parameters:

- `checkId` (string, required): The monitor
- `key` (string, required): The finding's key
- `runId` (string): Optional: apply it to this run right away

### `bring_back_run` (~90 tokens)

Bring back a set-aside failure

Relvato AI triage (a site on level "aside") set this failed run aside as likely noise — get_run shows aiTriage.setAside. Make it count as a failure again: in the bell, the digest and site health. No alert is re-sent. Use it when the user says the failure is real.

Input parameters:

- `runId` (string, required): The set-aside run

### `accept_visual_change` (~75 tokens)

Accept a visual change

The visual monitor found a page that changed on purpose (a redesign, new content): make this run's screenshot the new baseline for that page, device and browser. Undo with undo_visual_review. Only when the user confirms the change is intended.

Input parameters:

- `comparisonId` (string, required): From get_run visualComparisons[].comparisonId

### `ignore_visual_change` (~73 tokens)

Ignore a changed area

Ignore the area that changed on this comparison from now on (a clock, a rotating banner): it's added to the baseline's ignored regions. Undo with undo_visual_review. A mask (update_visual_monitor) is often the better fix.

Input parameters:

- `comparisonId` (string, required): From get_run visualComparisons[].comparisonId

### `flag_visual_change_as_problem` (~73 tokens)

Flag a visual change as a problem

The AI review let a visual change pass, but it's actually broken: mark it a failure. The run counts as failed in Relvato and shows as needing attention (notifications, Monitors passing); no message is sent.

Input parameters:

- `comparisonId` (string, required): From get_run visualComparisons[].comparisonId

### `undo_visual_review` (~46 tokens)

Undo a visual decision

Undo the last accept or ignore on this page, device and browser: the earlier baseline comes back.

Input parameters:

- `comparisonId` (string, required): From get_run visualComparisons[].comparisonId

### `accept_structure_change` (~100 tokens)

Accept a structure change

The structure monitor found a page whose layout changed on purpose: adopt this run's structure as the new baseline for that page (pageKey), or for every changed page on the run (all: true). Undo with undo_structure_review.

Input parameters:

- `all` (boolean): Every changed page on the run
- `pageKey` (string): The page (get_run metrics.pages[].pageKey)
- `runId` (string, required): The structure monitor's run

### `ignore_structure_change` (~80 tokens)

Ignore a structure change

Ignore specific element changes on a page from now on (signatures from get_run metrics.pages[].added / removed / countChanges[].sig), e.g. a widget that comes and goes. Undo with undo_structure_review.

Input parameters:

- `pageKey` (string, required): The page
- `runId` (string, required): The run
- `signatures` (array, required)

### `undo_structure_review` (~43 tokens)

Undo a structure decision

Undo the last accept or ignore on a page of the structure monitor.

Input parameters:

- `pageKey` (string, required): The page
- `runId` (string, required): The run

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-relvato-relvato/api-mcp#diagnostics

## Score history

- 2026-10-17: 88
- 2026-10-16: 88
- 2026-10-15: 87
- 2026-10-14: 87
- 2026-10-13: 86
- 2026-10-12: 85
- 2026-10-10: 84
- 2026-10-07: 83
- 2026-10-05: 82
- 2026-10-04: 82
- 2026-10-03: 81
- 2026-10-02: 79
- 2026-10-01: 79
- 2026-09-30: 79
- 2026-09-29: 78
- 2026-09-28: 75

## Common questions

### What is the Relvato MCP server?

Relvato is an MCP server listed in the public MCP registry as com.relvato/relvato. Website monitoring: add sites, configure and run monitors, read health, review results, apply fixes. This page covers its hosted endpoint (https://app.relvato.com/api/mcp).

### Is the Relvato MCP server safe to use?

Relvato scores 88 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Relvato MCP server expose?

Relvato exposes 58 tools: list_sites, add_site, verify_site, start_monitoring_for_goals, list_checks, and 53 more. Their descriptions and schemas cost roughly 7,204 tokens of context every time the server is loaded.

### Does the Relvato MCP server require authentication?

Yes. Relvato asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.

### Is the Relvato MCP server still maintained?

Relvato is still listed as active in the MCP registry. We last reached this channel on 17 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://app.relvato.com/api/mcp
- Repository: https://github.com/Relvato/relvato-mcp
- Website: https://www.relvato.com/developers
- Changelog RSS feed: https://verifymcp.io/servers/com-relvato-relvato/api-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-relvato-relvato/api-mcp.json
- HTML version of this page: https://verifymcp.io/servers/com-relvato-relvato/api-mcp