Relvato
Website monitoring: list sites and checks, run scans, read results and fix prompts.
Should I use this
Quality & Safety
Based on automated analysis of tool definitions and protocol compliance.
Context Cost
This is the approximate number of tokens consumed each time the server's tools are loaded into a model's context. Higher counts reduce the attention available for other tasks.
Install
One-Click Install
Add this to your `claude_desktop_config.json` file:
{
"mcpServers": {
"relvato": {
"url": "https://app.relvato.com/api/mcp"
}
}
}Remote endpoints
https://app.relvato.com/api/mcpstreamable-httpWhat it can do
Tool inventory
Tools (12)
🟢list_sites
List the websites in this Relvato account, with whether each is ready to run checks.
Input Schema
{
"type": "object",
"properties": {},
"additionalProperties": false
}🟡add_site(url, name, platform)
Start monitoring a website. Returns the site and the setup step the owner must complete before any check 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 Schema
{
"type": "object",
"properties": {
"url": {
"type": "string",
"description": "The site's address, e.g. https://example.com"
},
"name": {
"type": "string",
"description": "Display name (defaults to the domain)"
},
"platform": {
"type": "string",
"enum": [
"wordpress",
"other"
],
"description": "\"wordpress\" for WordPress/WooCommerce (deepest checks via the Relvato plugin); \"other\" for any other site or AI-built app (public-page checks, domain verification)."
}
},
"required": [
"url",
"platform"
],
"additionalProperties": false
}🟢verify_site(siteId, method)
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. Returns the updated setup state. Docs: https://www.relvato.com/docs/verify-site-ownership
Input Schema
{
"type": "object",
"properties": {
"siteId": {
"type": "string",
"description": "The site id"
},
"method": {
"type": "string",
"enum": [
"dns",
"meta"
],
"description": "Domain verification only: check just this method (default: both)"
}
},
"required": [
"siteId"
],
"additionalProperties": false
}🟢site_overview(siteId)
Plain-language health verdict for a site: what needs attention (real issues vs likely false positives), each check with its latest run and schedule, setup state, recommended checks not yet added, and the account's run usage.
Input Schema
{
"type": "object",
"properties": {
"siteId": {
"type": "string",
"description": "The site id"
}
},
"required": [
"siteId"
],
"additionalProperties": false
}🟢list_checks(siteId)
The checks 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 Schema
{
"type": "object",
"properties": {
"siteId": {
"type": "string",
"description": "The site id"
}
},
"required": [
"siteId"
],
"additionalProperties": false
}🟡add_checks(siteId, keys)
Add checks to a site by key (from list_checks). Each key reports added / exists / rejected with the reason (plan, active-check limit, needs the WordPress plugin). New checks run on their default triggers: a weekly (some daily) schedule, plus a re-run when the site changes (WordPress plugin updates, or pushes via the GitHub App).
Input Schema
{
"type": "object",
"properties": {
"siteId": {
"type": "string",
"description": "The site id"
},
"keys": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1,
"maxItems": 30,
"description": "Check keys, e.g. [\"uptime\", \"ssl\", \"error-scan\"]"
}
},
"required": [
"siteId",
"keys"
],
"additionalProperties": false
}🟡update_check(checkId, enabled, schedule, at, tz, ...)
Turn a check on or off, or change its schedule. Only the fields you pass change. Schedules faster than daily need a paid plan.
Input Schema
{
"type": "object",
"properties": {
"checkId": {
"type": "string",
"description": "The check id (from site_overview or add_checks)"
},
"enabled": {
"type": "boolean",
"description": "Turn the check on or off"
},
"schedule": {
"type": "string",
"enum": [
"off",
"weekly",
"daily",
"6h",
"hourly",
"fastest"
],
"description": "Recurring schedule"
},
"at": {
"type": "string",
"description": "Daily/weekly run time, HH:MM (24h)"
},
"tz": {
"type": "string",
"description": "IANA timezone for `at`, e.g. Europe/Berlin"
},
"dow": {
"type": "number",
"description": "Weekly only: weekday, 0 = Sunday … 6 = Saturday"
}
},
"required": [
"checkId"
],
"additionalProperties": false
}🟢trigger_scan(siteId, checkId)
Run a site's enabled checks now — or one check with checkId, even if it's turned off. Each run counts toward the monthly run quota. Returns the runIds to follow with get_run.
Input Schema
{
"type": "object",
"properties": {
"siteId": {
"type": "string",
"description": "The site id"
},
"checkId": {
"type": "string",
"description": "Run only this check"
}
},
"required": [
"siteId"
],
"additionalProperties": false
}🟢list_runs(siteId, limit)
Recent runs, newest first — optionally for one site. Each has the check (checkId, its key as journey, checkName), status, trigger, timing and its error / warning; get_run has the detail.
Input Schema
{
"type": "object",
"properties": {
"siteId": {
"type": "string",
"description": "Only runs for this site id"
},
"limit": {
"type": "number",
"description": "Max runs, 1-100 (default 25)"
}
},
"additionalProperties": false
}🟢get_run(runId)
One run in detail: status, error and warnings (ignored ones marked), each step, visual comparisons, metrics, and the dashboard link where the user can review or accept changes. Large metrics are compacted, never the findings: daily series become summaries and what was left out is listed in metricsTrimmed.
Input Schema
{
"type": "object",
"properties": {
"runId": {
"type": "string",
"description": "The run id"
}
},
"required": [
"runId"
],
"additionalProperties": false
}🟢get_fix_prompt(runId)
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 check 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 Schema
{
"type": "object",
"properties": {
"runId": {
"type": "string",
"description": "The run id"
}
},
"required": [
"runId"
],
"additionalProperties": false
}🟢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 check 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.
Input Schema
{
"type": "object",
"properties": {},
"additionalProperties": false
}Community
Evidence