Health Export MCP vs Website monitoring API & MCP server
A side-by-side look at the Health Export MCP and Website monitoring API & MCP server MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Health Export MCP for monitoring work as a local process; choose Website monitoring API & MCP server for monitoring over a hosted endpoint. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Health Export MCP when
- You need dedicated capabilities in the Monitoring domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You have the keys it needs:
HEALTH_DATA_DIR. - You want tools like
get_mcp_status, list_metrics, get_health_metrics.
Choose Website monitoring API & MCP server when
- You need dedicated capabilities in the Monitoring domain.
- You prefer a remote HTTP/SSE transport.
- Its auth model fits you: API key required.
- You want tools like
list_sites, add_site, verify_site.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Monitoring | Monitoring |
| Quality signal | 67/100 · Great | 54/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Remote HTTP/SSE |
| Auth | No auth required | API key required |
| Pricing | Free | Freemium |
| Required env vars | HEALTH_DATA_DIR | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 8 | — |
| Directory activity | 10 views 0 installs 0 upvotes | 3 views 1 installs 0 upvotes |
| Tools | 14 | 58 |
| Full listing | View Health Export MCP | View Website monitoring API & MCP server |
Tools & capabilities
Health Export MCP tools 14
get_mcp_statusHealth check: data source, how many metrics/workouts are available, which optional context files exist, and the most recent data date. Call this first to confirm the bridge is connected.list_metricsList every available Apple Health metric with its unit, day count, and date range. Use this to discover metric names before querying.get_health_metricsGet values for a metric (or all metrics) over an optional date range, with an aggregate (avg/sum/min/max/latest). The core data-retrieval tool. Every result carries a `coverage` block giving the metric's real firstDate/lastDate/days: check it before trusting a long window, and note that `aggregate` is always computed over the full range even when `points` are rolled up. Single-metric answers also list any logged point events inside the window as segmentBoundaries.get_trendsCompare the most recent N-day window against the prior N days for a metric: change, percent change and direction (up/down/flat). Also returns `daysAvailable` and `windowSatisfied`: if windowSatisfied is false the file does not hold enough history for the window you asked for, and the comparison is over less data than requested. Logged point events inside the compared span are listed as segmentBoundaries.compare_periodsCompare a metric between two arbitrary date periods (A vs B): each aggregate plus the change and percent change. Pass periodA/periodB explicitly, or pass anchor {eventId, days} to build both periods around a logged event (the before/after question, with the event day excluded from both sides).get_structured_exportReturn clean structured JSON for the chosen metrics/date range. Paginated: the result carries `nextCursor` when more metrics remain; pass it back as `cursor` for the next page. Prefer naming the metrics you need and a date range; calling it bare over a full history is a lot of data.get_intradayThe current hour-by-hour window from the iOS app's HOURLY automations (health-intraday.json, app 1.4+): each metric's hourly points plus its latest value. The file is REPLACED on every hourly run, so this is a live within-day view, not history; use get_health_metrics for day-level questions. Returns available:false with setup guidance when no hourly automation has delivered yet.query_health_dataNatural-language convenience: pass a question and get routed structured results. Prefer the specific tools above when you can, and call list_metrics first to see how much history exists, since this tool answers over whatever the file holds.list_eventsLogged context events from health-events.json: medication starts, habit changes, doctor visits, life events, shift blocks, episodes, travel, and any type a newer app adds. Optional {type, tag, start, end} filters; a range event matches a window it overlaps. Sorted ascending by date. Returns available:false when the file was never exported; absence means nothing was exported, not that nothing happened.get_profileThe context fields the user explicitly opted in to sharing (health-profile.json): conditions, medications, goals, allergies, notes. Returns the fields plus a presentFields list. An absent field was withheld by the user or never enabled; absence must never be read as "none".get_workoutsQuery the workouts cache with {activityType (a name like Running, or a raw HealthKit id like 37), start, end} filters and pagination ({limit} default 50 max 200, {cursor} from a previous nextCursor). Records are returned exactly as stored, including the newer optional keys (avgHeartRate, maxHeartRate, running dynamics, cycling power, intervals, hasRoute) when the app exported them; older caches simply lack those keys and nothing is fabricated. Also returns summary {count, byActivityType} over everything that matched.get_sleep_sessionsClustered sleep sessions from health-sessions.json with {start, end, day} filters. Sessions are attributed to the WAKING day, matching the daily cache's sleep_analysis, so the two surfaces never disagree; a split night appears as multiple sessions with the same day, returned as-is. Timestamps carry the local UTC offset at the time of the sample.- +2 more on the listing page
Website monitoring API & MCP server tools 58
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); scheduled runs, alerts, update/deploy runs and the monitors that act on the site need the proof (setup.nextStep); setup.afterProof says what proof adds for this site on its plan. 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-ownershipverify_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.relvato.com/docs/verify-site-ownershipstart_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), speed, domain, custom, ai. Before the site's ownership is proven the monitors are added but don't run on their schedule yet (scheduleStarts).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 proof; for a site added as "other", withWordPressPlugin lists what the WordPress plugin adds.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 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). Before proof they're added but only run when trigger_scan starts them (scheduleStarts).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 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.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 Relvato's own probes (availability % and incidents over 30 days).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.- +46 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Health Export MCP
{
"mcpServers": {
"io-github-philipad-health-export-mcp": {
"command": "npx",
"args": [
"-y",
"health-export-mcp"
],
"env": {
"HEALTH_DATA_DIR": "YOUR_HEALTH_DATA_DIR_HERE"
}
}
}
}
Website monitoring API & MCP server
{
"mcpServers": {
"website-monitoring-api-mcp-server": {
"command": "npx",
"args": [
"-y",
"website-monitoring-api-mcp-server"
]
}
}
}
Frequently asked questions
Health Export MCP is categorized under Monitoring and uses a local stdio subprocess. Website monitoring API & MCP server belongs to Monitoring and uses a remote HTTP/SSE transport. Pick Health Export MCP for monitoring work and Website monitoring API & MCP server for monitoring.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Health Export MCP is listed as free. Auth: no auth required. Website monitoring API & MCP server is listed as freemium — a free tier with paid plans. Auth: api key required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add io-github-philipad-health-export-mcp and website-monitoring-api-mcp-server as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Health Export MCP has a quality signal of 67/100 (Great) with 10 views, 0 installs and 8 GitHub stars. Website monitoring API & MCP server has 54/100 (Good) with 3 views, 1 installs and 0 GitHub stars.