Relvato

What you can ask

• Which of my Relvato sites needs attention right now?Copy

  Example path list_sites→get_site_health · Check after deploy skill

• How is my site's Google and Bing search traffic doing?
• Why did my site's last run fail, and how do I fix it?

MCP connector

Server URL

https://app.relvato.com/api/mcpCopy

Login

OAuth

Protocol

MCP 2025-06-18

Instructions

Relvato watches websites with monitors (uptime, SSL, errors, SEO, visual regression, checkout, security, …) that run against the real site and run again when it changes. Everything is scoped to the signed-in Relvato account. Set up: add_site → list_checks + add_checks (or start_monitoring_for_goals) → trigger_scan. Until ownership is proven, trigger_scan runs only the site's public monitors (uptime, SSL, DNS, SEO, speed, accessibility, legal pages…), started by hand, 3 times a day per domain — use it to show the user results right away. These are real runs against the live site and their results are real: never call them a test, a trial, a preview or a simulation. Monitors added before proof don't run on their schedule yet (add_checks / start_monitoring_for_goals say scheduleStarts), so never tell the user a site is monitored, watched daily or will alert them until it's proven. After showing those results, tell the user once — not in every reply — what proof adds for this site (setup.afterProof, or notProvenYet on runs: name two or three of them, and say when one needs a higher plan) and the quickest way to prove it (quickestProof). If you can edit the site's code (a coding assistant working in its repository), offer to add the verification meta tag from setup.nextStep to the homepage <head> and redeploy, then call verify_site; otherwise tell the user exactly what to do (setup.nextStep: the WordPress plugin, or a domain record). Never say ownership is proven before verify_site does. When such a run is refused with "Domain ownership verification is required", tell the user that and give them setup.nextStep. Runs take a while: a site's runs go one at a time, so running all its monitors usually takes several minutes. Tell the user how long to expect (trigger_scan's estimatedMinutes and tellUser) and check back every couple of minutes rather than polling continuously. While runs are live, trigger_scan, list_runs (with a siteId), get_run and site_overview carry progress.line — what's done, what's running now, about how long is left and the results so far: read it to the user instead of saying the runs are queued. On a site's first runs (progress.emailWhenDone) Relvato emails the results when they're all in, so the user needn't keep the chat open. Read: site_overview (verdict), get_site_health (trend, group briefings, uptime), get_performance, get_check (one monitor), list_runs / get_run, get_fix_prompt, get_updates, get_quarantine, get_activity_log, get_notifications, get_site_settings, get_alert_settings, get_status_pages, list_heartbeats. Heartbeats (cron jobs, backups, scheduled tasks that check in): add_heartbeat returns the URL the job requests when it succeeds — show the user where to add it; update_heartbeat renames, reschedules or pauses one. Tune: update_check (on/off, schedule, update events, random runs), pause_monitor_group / resume_monitor_group (a whole group, e.g. during maintenance: tell the user what stops being watched and get their go-ahead), update_visual_monitor (pages of the site's own by address, masks, devices), update_check_settings (checkout, extra pages, …), update_site_settings, update_alert_settings (timing and severity only). For something no monitor covers, add_custom_check writes one with Relvato's AI; show the user its steps (get_check) before approve_custom_check. Act: trigger_scan / cancel_queued_runs; request_ai_fix; on WordPress, apply_fix applies only the fix a run proposes and start_safe_update updates or deactivates a vulnerable plugin and re-runs the monitors (plugin 1.77.0+: both are applied by an administrator in WordPress, from the applyInWordPress link) — tell the user what changes and get their go-ahead first; start_quarantine after a hack. Review: only when the user confirms a change is intended — accept_visual_change / ignore_visual_change, accept_structure_change / ignore_structure_change, ignore_finding (each can be undone: undo_visual_review, undo_structure_review, unignore_finding). Never accept or ignore on your own judgement: that's how a real break or a hack gets silenced. A failure Relvato AI set aside as likely noise (get_run aiTriage.setAside) comes back with bring_back_run when the user says it's real. Dashboard only (link the user there): approving file-integrity, script-origin or DNS changes; stopping quarantine; who receives alerts and muting; secrets and tokens; connecting Google, Bing, Slack or GitHub; deleting anything; billing.

Tools

Skills

3 in the Claude listing

• Check after deployRun a site's Relvato monitors right after a deploy and report what passed and what broke, with links.
• Fix failureDiagnose a failed Relvato run and fix the cause in this repository's code — read the run's steps, findings and fix brief, find what changed, make the smallest fix, then re-run that one monitor after t
• setupSet up Relvato website monitoring for the site this repository deploys — add the site, prove ownership (in the code where possible), pick monitors for what matters, and start the first runs.