GitHub
server ทางการของ GitHub ให้ AI อ่านและจัดการโค้ด issue และ pull request ในบัญชีของคุณได้ ใช้ผ่านคลาวด์ของ GitHub หรือรันในเครื่องด้วย Docker ก็ได้
คำอธิบายจากผู้ทำ (ภาษาอังกฤษตามต้นฉบับ)
Website monitoring: uptime, checkout, SEO (Search Console, Bing), security, speed, DNS, compliance.
สามเรื่องนี้ไม่รวมเป็นคะแนนเดียว เพราะความเห็น การวัด และความนิยม เป็นคนละเรื่องกัน
ตัวนี้ยังไม่ได้เรียบเรียงเป็นภาษาไทย ด้านล่างคือข้อเท็จจริงที่เราอ่านจาก registry
เลือกโปรแกรม AI ที่คุณใช้ แล้วคัดลอกค่าตั้งไปวาง
Authorizationค่าที่ติดป้ายความลับคือกุญแจของบัญชีคุณ อย่าส่งให้ใคร และอย่าวางในแชต
ต้องเตรียมก่อน
คุณใช้แอปไหน
เลือกแอปด้านบน เราจำไว้ให้ ครั้งหน้าปุ่มจะขึ้นว่า “ติดตั้งลง …”
ที่อยู่นี้ต้องใส่ key ใน header ของคำขอ ซึ่งเมนูเพิ่ม connector ใส่ให้ไม่ได้ ใช้ Claude Code, Cursor หรือ VS Code แทน
พิมพ์คำสั่งนี้ใน Terminal
claude mcp add --transport http relvato https://app.relvato.com/api/mcp --header 'Authorization: Bearer {api_key}'เติมค่าที่เว้นว่างไว้ก่อนรัน
วางในไฟล์ .cursor/mcp.json ของโปรเจกต์ หรือ ~/.cursor/mcp.json
{
"mcpServers": {
"relvato": {
"url": "https://app.relvato.com/api/mcp",
"headers": {
"Authorization": "Bearer {api_key}"
}
}
}
}เบราว์เซอร์จะถามก่อนเปิดแอป จากนั้นแอปแสดงค่าตั้งให้ตรวจแล้วกดยืนยัน ช่อง key เว้นว่างไว้ให้คุณใส่เอง
วางในไฟล์ .vscode/mcp.json ของโปรเจกต์
{
"servers": {
"relvato": {
"type": "http",
"url": "https://app.relvato.com/api/mcp",
"headers": {
"Authorization": "Bearer {api_key}"
}
}
}
}เบราว์เซอร์จะถามก่อนเปิดแอป จากนั้นแอปแสดงค่าตั้งให้ตรวจแล้วกดยืนยัน ช่อง key เว้นว่างไว้ให้คุณใส่เอง
ที่อยู่นี้ต้องใส่ key ใน header ของคำขอ ซึ่งเมนูเพิ่ม connector ใส่ให้ไม่ได้ ใช้ Claude Code, Cursor หรือ VS Code แทน
ตัวเลือกเก็บในคุกกี้บนเครื่องนี้ ไม่ต้องมีบัญชี
Authorization ความลับ HTTP headerค่าตั้งนี้สร้างจากข้อมูลใน registry ของผู้ทำ ถ้าไม่ตรงกับ README ให้เชื่อ README
ชื่อและคำอธิบายเครื่องมือตามที่ server ตอบมาเมื่อ 7 พ.ย. 2569 ผู้ทำเป็นคนเขียน ไม่ใช่เรา แสดงเป็นข้อความล้วน
list_sitesList the websites in this Relvato account, with whether each is ready to run monitors.
add_siteStart 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); schedule
verify_siteCheck 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.re
start_monitoring_for_goalsThe 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),
list_checksThe 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 proo
add_checksAdd 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 a
dismiss_recommendationStop recommending a monitor for a site (list_checks marks recommendations), or bring every dismissed recommendation back with restoreAll.
calibrate_siteWordPress / 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_beaconCheck 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_overviewPlain-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 abili
get_site_healthHow 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 R
get_performanceA 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_checkOne 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
list_runsRecent 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
get_runOne 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
get_fix_promptFor 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 earlie
get_updatesWordPress 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_updateFollow a safe update or deactivation: applying → verifying → passed, or reverted with the monitors that broke.
get_quarantineQuarantine 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_logWordPress 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 36
get_notificationsThe 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_settingsA 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 iden
get_alert_settingsWho 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
get_status_pagesPublic 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_heartbeatsA 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,
update_checkTurn 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 an
pause_monitor_groupPause 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 th
resume_monitor_groupResume 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_monitorEdit 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,
update_check_settingsChange 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 no
add_custom_checkDescribe 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 ste
edit_custom_checkGive 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_checkHave 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_checkApprove 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_settingsChange 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_settingsChange 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 turnin
add_heartbeatCreate 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 `), and ` /fail` to report a failure (a POST body is kept with the ping). No ping
update_heartbeatRename 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 i
trigger_scanRun 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 severa
cancel_queued_runsStop 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
request_ai_fixAsk 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.
apply_fixWordPress 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.
start_safe_updateWordPress 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. Ge
start_quarantineAfter 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)
extend_quarantineKeep quarantine mode on for another 48 hours from now.
send_test_alertSend 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.
resume_webhookTurn webhook alerts back on after Relvato paused them for repeated failed deliveries (fix the endpoint first; send_test_alert checks it).
report_false_positiveTell 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.
ignore_findingStop 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.
unignore_findingMake an ignored finding count again (get_check lists a monitor's ignored findings with their keys; get_run marks them on a run).
bring_back_runRelvato 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.
accept_visual_changeThe 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.
ignore_visual_changeIgnore 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.
flag_visual_change_as_problemThe 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.
undo_visual_reviewUndo the last accept or ignore on this page, device and browser: the earlier baseline comes back.
accept_structure_changeThe 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.
ignore_structure_changeIgnore 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.
undo_structure_reviewUndo the last accept or ignore on a page of the structure monitor.
เราตรวจจากข้อมูลที่ใครก็เปิดดูได้ ยังไม่ได้อ่านโค้ด ข้อที่ไม่เกี่ยวกับตัวนี้ไม่นับในตัวหาร · ตรวจเมื่อ 8 พ.ย. 2569
ชื่อใน registry ยืนยันโดเมน relvato.com แล้ว (registry ตรวจความเป็นเจ้าของโดเมน)
ยังไม่ได้อ่านข้อมูล repo จาก GitHub
ยังไม่ได้อ่านข้อมูล repo จาก GitHub
ตอบกลับใน 428 ms (HTTP 200)
ไม่ต้องล็อกอิน
อ่านคำอธิบายเครื่องมือ 58 ตัวแล้ว ไม่พบคำสั่งแอบแฝงถึง AI
เทียบกับทุก server ที่ยังใช้งานในหมวดนี้ทั้งทะเบียน ดาวนับเฉพาะเมื่อผู้ลงทะเบียนเป็นเจ้าของ repo
จากการตรวจเบื้องต้นของเรา ผ่าน 3 จาก 3 ข้อที่ตรวจได้ เรายังไม่ได้อ่านโค้ด ก่อนใส่กุญแจหรือ token ให้ดูว่า server ขอสิทธิ์อะไร และเลือกกุญแจที่ทำได้เท่าที่จำเป็น
ต้องใส่ค่าเหล่านี้: Authorization
รันบนคลาวด์ของผู้ทำ ต่อผ่านอินเทอร์เน็ตได้เลย ไม่ต้องลงโปรแกรม แต่ข้อมูลที่ส่งให้จะผ่านเซิร์ฟเวอร์ของผู้ทำ
repo บน GitHub มีการแก้โค้ดล่าสุด – และส่งรุ่นล่าสุด (3.5.1) เข้า registry 14 วันที่ผ่านมา
โปรแกรมที่รองรับ MCP เช่น Claude Desktop, Claude Code, Cursor และ VS Code ตัวนี้ต่อผ่าน URL จึงใช้กับโปรแกรมที่รับ remote MCP ได้ เช่น ChatGPT ที่เปิดโหมดนักพัฒนา
ในหมวดเดียวกันมี GitHub, Desktop Commander, Cloudflare MCP
server หมวดเดียวกันจากผู้ทำคนอื่น เรียงตามดาว
อ่านการ์ด:★ ดาว GitHubiสามเสา: รีวิว · ผลตรวจ · การใช้งานiอัปเดต = วันที่ส่งรุ่นล่าสุดเข้า registryi
server ทางการของ GitHub ให้ AI อ่านและจัดการโค้ด issue และ pull request ในบัญชีของคุณได้ ใช้ผ่านคลาวด์ของ GitHub หรือรันในเครื่องด้วย Docker ก็ได้
MCP server for terminal commands, file operations, and process management
Cloudflare MCP servers
ส่วนนี้คัดจาก repo ของผู้ทำตามต้นฉบับ PopNx MCP ไม่ได้ตรวจหรือรับรองเนื้อหา ตัด HTML รูปภาพ และสคริปต์ออกแล้ว ลิงก์จะพาออกนอกเว็บ
Relvato MCP server
Website monitoring your AI agent can run: add a site, set up and tune its monitors, run them, explain what broke and fix it with you.
Developer docs · Official MCP Registry · relvato.com
Relvato is a website monitoring platform. Its monitors cover uptime and SSL; user flows like sign-up, login, cart and checkout; security (vulnerable plugins, signs of a hack, changed files, new admins); Core Web Vitals and real-user speed; visual regressions and broken links; SEO and AI search, including your Google Search Console and Bing Webmaster Tools numbers; domain, DNS and email records; and legal compliance (cookie consent, accessibility). They run in a real browser on any website, go deepest on WordPress & WooCommerce, and run again every time the site changes.
This is Relvato's hosted Model Context Protocol server. There's nothing to install or run: point your MCP client at the URL and sign in to Relvato, or use a Relvato API key. This repository holds the connection details, the registry entry (server.json) and the Claude plugin (.claude-plugin/, skills/). The server itself runs at Relvato.
| Endpoint | https://app.relvato.com/api/mcp |
| Transport | Streamable HTTP (stateless JSON-RPC over POST) |
| Auth | Sign in (OAuth 2.1: PKCE, Client ID Metadata Documents, resource indicators), or an API key: Authorization: Bearer rlv_… |
| Registry name | com.relvato/relvato |
Sign-in works in clients that identify themselves with a Client ID Metadata Document (CIMD): Claude (claude.ai, Desktop, and Claude Code 2.1.81 or later), ChatGPT and VS Code. Relvato doesn't offer dynamic client registration, so a client that can only register itself that way (Cursor for now, the Gemini CLI, Docker's MCP gateway), or that has no sign-in at all (DeepSeek Harness), uses an API key instead.
In a client that supports it, add the endpoint with nothing else. The first time the client uses it, it opens Relvato's sign-in:
Discovery follows the MCP authorization spec. A 401 points to /.well-known/oauth-protected-resource/api/mcp, and the authorization server is https://clerk.relvato.com (client_id_metadata_document_supported; no registration endpoint). The scopes are relvato:read, relvato:write and user:org:read.
For scripts, for clients that can't sign in (no CIMD support), or for your personal workspace while you're in an organization:
Authorization: Bearer rlv_… (or x-api-key: rlv_…). A key is shown once. Keep it out of files you commit.Settings → Connectors → Add custom connector. Enter the URL https://app.relvato.com/api/mcp, then Connect and sign in.
The plugin (recommended): the server plus six skills, three for any conversation about your sites and three for working from a code repo.
claude plugin marketplace add Relvato/relvato-mcp
claude plugin install relvato@relvato
Then run /mcp, choose plugin:relvato:relvato, then Authenticate. The skills:
| Skill | What it does | |
|---|---|---|
/relvato:site-health [site] | Reports how a site is doing across all its monitors (uptime, user flows, security, speed, SEO, design, domain, compliance) and what needs attention first. Reads results only. | |
| `/relvato:search-traffic [site] [google\ | bing]` | Explains the site's Google Search Console and Bing Webmaster Tools numbers against its usual: clicks, impressions, position, pages in the index, the pages and queries losing ground, crawl errors and sitemaps, plus SEO integrity and AI answer engines. |
/relvato:security-review [site] | Reviews the security monitors: vulnerable plugins, signs of a hack, changed files, new admins, exposed files and new scripts, in order of urgency, and what to do first. | |
/relvato:setup [url] | Adds the site this repo deploys, proves ownership (it can add the verification meta tag to your code), picks monitors for what matters and starts the first runs. | |
/relvato:check-after-deploy [site] [group] | Runs the site's monitors after a deploy, says how long they'll take, and reports what passed and what broke, with links. Only runs when you type it, since runs use your monthly quota. | |
/relvato:fix-failure [run] | Reads a failed run and its fix brief, finds the cause in the code (including what changed since it last passed), makes the smallest fix with your OK, then re-runs that monitor. |
Already added Relvato on claude.ai? With a Claude subscription, that connector shows up in Claude Code too. The skills work with either connection.
The plugin has no code of its own: it adds Relvato's hosted MCP server (https://app.relvato.com/api/mcp) and these skills, which are written instructions for Claude. Claude sends your requests to that server only, after you sign in to Relvato. Starting runs counts toward your plan's monthly runs, so the skills ask before they start any.
Just the server:
claude mcp add --transport http relvato https://app.relvato.com/api/mcp
Then run /mcp, choose relvato, then Authenticate. With an API key instead:
claude mcp add --transport http relvato https://app.relvato.com/api/mcp --header "Authorization: Bearer rlv_your_key"
In ~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project), with an API key. Cursor doesn't support Client ID Metadata Documents yet, so it can't use Relvato's sign-in:
{
"mcpServers": { "relvato": { "url": "https://app.relvato.com/api/mcp", "headers": { "Authorization": "Bearer rlv_your_key" } } } }
Once Cursor supports CIMD, the URL alone will be enough: Cursor will offer to sign in.
In .vscode/mcp.json. VS Code offers to sign in:
{
"servers": { "relvato": { "type": "http", "url": "https://app.relvato.com/api/mcp" } } }
With an API key, VS Code can ask for it once and store it securely, so it never sits in the file:
{
"inputs": [ { "type": "promptString", "id": "relvato-key", "description": "Relvato API key (rlv_…)", "password": true } ], "servers": { "relvato": { "type": "http", "url": "https://app.relvato.com/api/mcp", "headers": { "Authorization": "Bearer ${input:relvato-key}" } } } }
Install the extension from its own repository, Relvato/relvato-gemini (it moved there in 3.5.2; if you installed it from this repository, run gemini extensions uninstall relvato first):
gemini extensions install https://github.com/Relvato/relvato-gemini
It asks for your Relvato API key (create one) and keeps it in your system keychain; it never sits in a file. To change it later: gemini extensions config relvato. The Gemini CLI can't use Relvato's sign-in (it supports only dynamic client registration, which Relvato doesn't offer), so the extension uses the key.
Without the extension, add the server to ~/.gemini/settings.json:
{
"mcpServers": { "relvato": { "httpUrl": "https://app.relvato.com/api/mcp", "headers": { "Authorization": "Bearer rlv_your_key" } } } }
Add the dsh-plugin-relvato bundle to a profile, with your API key in RELVATO_API_KEY (your environment or ~/.dsh/.env):
dsh plugin --profile web add dsh-plugin-relvato
It's on npm; github:Relvato/dsh-plugin-relvato installs it straight from GitHub.
dsh's MCP client sends headers and has no sign-in, so it uses the key. The tools appear as mcp__relvato__ .
In cline_mcp_settings.json (MCP Servers → Configure), with an API key:
{
"mcpServers": { "relvato": { "type": "streamableHttp", "url": "https://app.relvato.com/api/mcp", "headers": { "Authorization": "Bearer rlv_your_key" } } } }
Agents that set servers up themselves can follow llms-install.md.
Add a remote HTTP (streamable HTTP) server with the endpoint above. If the client supports MCP sign-in with Client ID Metadata Documents (CIMD), that's all. Otherwise (including clients that only do dynamic client registration) add an Authorization: Bearer rlv_… header. In the common mcp.json format:
{
"mcpServers": { "relvato": { "type": "http", "url": "https://app.relvato.com/api/mcp", "headers": { "Authorization": "Bearer rlv_your_key" } } } }
58 tools, grouped by job in the order tools/list sends them. read tools work with any connection; full access tools need a full-access key, or a sign-in that allowed changes.
| Tool | What it does | Access needed |
|---|---|---|
list_sites | List the account's websites and whether each is ready to run monitors. | read |
add_site | Add a website and get its setup step: connect the WordPress plugin, or verify the domain. Until then it can run the public monitors by hand, 3 times a day (real runs on the live site). | full access |
verify_site | Check that setup step: the plugin connection, or the domain-verification DNS record or meta tag. | full access |
start_monitoring_for_goals | Pick what matters (checkout, security, search, speed, …) and get the monitors that cover it on your plan. | full access |
list_checks | The monitors you can add to a site: what each catches, whether your plan includes it, and which are recommended. Before ownership is proven: which can run now (started by hand), and what proof adds. | read |
add_checks | Add monitors to a site; each one reports added, already there, or why not. Their schedule starts once ownership is proven. | full access |
dismiss_recommendation | Stop recommending a monitor for a site, or bring dismissed recommendations back. | full access |
calibrate_site | WooCommerce: read the store again (a product to buy, checkout type, currency) after it changed. | full access |
verify_vitals_beacon | Check the real-user Web Vitals beacon is installed. | full access |
| Tool | What it does | Access needed |
|---|
| site_overview | Plain-language health verdict: what needs attention, every monitor with its latest run and schedule, plan usage and, on WordPress, the
ตัดมาแค่ช่วงต้น อ่านต่อใน repo