Relvato
by app.relvato.com in Developer tools
Website monitoring: uptime, checkout, SEO (Search Console, Bing), security, speed, DNS, compliance.
https://app.relvato.com/api/mcp- Tools
- 58
- open to any client
- Uptime
- 100%
- last 30 days
- Response time
- 616 ms
- 1.2 s slowest 5%
- Last check
- Passed
- 4 h ago, next in 2 h
This listing's own text contains instructions aimed at AI agents (see the security scan below). We withhold that text from agents and never recommend this service.
Reliability
Status and outage history · Atom feed · Watch with other listings
How to connect
Add it to any MCP client that supports remote servers.
{
"mcpServers": {
"relvato": {
"type": "http",
"url": "https://app.relvato.com/api/mcp"
}
}
}58 tools
- list_sites
List the websites in this Relvato account, with whether each is ready to run monitors.
- add_site
Start monitoring a website. Returns the site and its setup: until the owner proves ownership (connect the WordPress plugin, or verify the domain — the only option for non-WordPress sites), trigger_scan can run the public monitors by hand 3 times a day (setup.manualRuns)…
- verify_site
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…
- start_monitoring_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…
- list_checks
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. Before the site's ownership is proven, runsNow says which can run now (started by hand) and which after…
- add_checks
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). Once the site's ownership is proven, new monitors get a daily schedule on plans that run daily (Pro and up) and…
- dismiss_recommendation
Stop recommending a monitor for a site (list_checks marks recommendations), or bring every dismissed recommendation back with restoreAll.
- calibrate_site
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.
- verify_vitals_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.
- 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…
- get_site_health
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…
- get_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.
- get_check
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…
- 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…
- get_run
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…
- get_fix_prompt
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…
- get_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.
- get_safe_update
Follow a safe update or deactivation: applying → verifying → passed, or reverted with the monitors that broke.
- get_quarantine
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.
- get_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…
- 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
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…
- 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…
- get_status_pages
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
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…
- update_check
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…
- pause_monitor_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…
- resume_monitor_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.
- update_visual_monitor
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…
- update_check_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…
- add_custom_check
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…
- edit_custom_check
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.
- reauthor_custom_check
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.
- approve_custom_check
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.
- update_site_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.
- update_alert_settings
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…
- add_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…
- update_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…
- trigger_scan
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…
- 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…
Security scan
1 finding
- Asks the agent to hide things from the user in instructions
oring_for_goals say scheduleStarts), so never tell the user a site is monitored, watched daily or will alert them until it's proven. After s
Recent checks
| When | Result | HTTP | Time |
|---|---|---|---|
| 4 h ago | Passed | 200 | 695 ms |
| 15 h ago | Passed | 200 | 549 ms |
| 27 h ago | Passed | 200 | 292 ms |
| 39 h ago | Passed | 200 | 207 ms |
| 2 days ago | Passed | 200 | 315 ms |
Show 10 older checks
| 3 days ago | Passed | 200 | 1.0 s |
| 3 days ago | Passed | 200 | 717 ms |
| 4 days ago | Passed | 200 | 289 ms |
| 4 days ago | Passed | 200 | 265 ms |
| 5 days ago | Passed | 200 | 412 ms |
| 6 days ago | Passed | 200 | 392 ms |
| 6 days ago | Passed | 200 | 506 ms |
| 7 days ago | Passed | 200 | 1.3 s |
| 7 days ago | Passed | 200 | 237 ms |
| 8 days ago | Passed | 200 | 546 ms |