MCP Tools Reference

MCP Tools Reference

These are the tools an AI assistant can call once connected to Sentinel's MCP server. Every tool is read-only and scoped to your current team. You don't call these directly — your assistant picks the right tool from your natural-language request — but this reference documents exactly what each one accepts and returns.

get_uptime_summary

At-a-glance health for the team — the "is anything down?" answer in one call.

• Inputs: none
• Returns: counts of monitors up / down / degraded / paused / pending (always reconcile to the total), an all_operational flag (availability only — true when nothing is down or degraded), a separate has_open_incidents flag, the lists of down and degraded monitors, and any open incidents

get_attention_items

A prioritized roundup of everything needing attention — the "anything I should know this morning?" answer.

• Inputs: ssl_within_days (default 14), domain_within_days (default 30), regression_threshold_pct (default 50) — all optional
• Returns: monitors down and degraded, SSL certificates and domains expiring soon, response-time regressions (recent vs prior-week average), open incidents, plus an attention_count and all_clear headline

list_monitors

List the team's monitors with their current status and recent response time.

• Inputs: search (URL contains), status (e.g. online/offline), type (http/ping/port/heartbeat/cron), sort (response_time to rank slowest first), limit (default 50, max 100) — all optional
• Returns: per monitor — id, url, name, type, status, check interval (seconds), 7-day average response time (avg_response_time_ms), last checked

get_monitor

Full detail for one monitor, including configuration and every enabled sub-check.

• Inputs: monitor_id (required)
• Returns: status, per-type config (http/port/heartbeat/cron), sub_checks (SSL cert, DNS records, domain/WHOIS, keyword, JSON assertions, latest Lighthouse scores), per-region response times (or ping/port results), and recent incidents

list_incidents

Incident (outage) history for the team.

• Inputs: monitor_id, status, start_date, end_date (ISO dates), limit (default 50, max 100) — all optional
• Returns: per incident — monitor, status, started/resolved times, duration, root cause

list_status_pages

The team's public status pages.

• Inputs: search, limit — optional
• Returns: per page — name, slug, custom domain + verification status, and the underlying monitor's status

list_expiring_certificates

SSL certificates and domain registrations expiring within a window — "any certs or domains expiring soon?".

• Inputs: within_days (default 30, max 365), type (ssl, domain, or all) — all optional
• Returns: two lists (SSL and domains), soonest-first — url, issuer/registrar, expiry date, days until expiry, and an expired flag

get_performance_history

Trends over time for a monitor.

• Inputs: monitor_id (required), days (default 30, max 90)
• Returns: daily response-time trend (avg/min/max plus DNS/TCP/TLS/TTFB phases) and Lighthouse score history per strategy (performance/accessibility/SEO/best-practices + Core Web Vitals)

get_dns_history

The DNS record timeline for a monitor — reveals when records changed.

• Inputs: monitor_id (required), record_type (e.g. A/MX/TXT), limit (default 20, max 100)
• Returns: snapshots newest-first — record type, records, baseline flag, recorded-at

check_url

An on-demand global probe of any URL — no monitor required. Useful for "is it up everywhere?" before committing to monitoring.

• Inputs: url (required), regions (subset of active regions), timeout_seconds (default 15, max 30)
• Returns: an overall verdict (up / down / partial / unknown) and per-region status, HTTP code, and latency