MCP Tools Reference

MCP Tools Reference

These are the tools an AI assistant can call once connected to Sentinel's MCP server, all scoped to your current team. You don't call them directly; your assistant picks the right tool from your natural-language request. This reference documents what each one accepts and returns. The read tools below are available on any plan with API access; the write tools at the end require full API access (Pro or Business).

Read tools

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), verbose (include full detail; default compact), limit (default 25, max 100), offset (for pagination), all optional
• Returns: pagination fields (total, offset, limit, returned, has_more, next_offset). Each monitor is compact by default (id, url, status, 7-day avg_response_time_ms); with verbose=true it also includes name, type, check interval (seconds), and 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 25, max 100), offset (for pagination), all optional
• Returns: pagination fields (total, offset, limit, returned, has_more, next_offset) plus, 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

Write tools (Pro & Business)

These change your account and require full API access; a read-only token is refused. Your assistant will ask you to approve each call, and deletes are flagged as destructive.

create_monitor

Create a new monitor. The type must be supported by your plan.

• Inputs: monitor_type (http/ping/port/heartbeat/cron), url, friendly_name, check_interval (minutes, 0.5 to 60, defaults to 1), port, check_types, monitored_regions (defaults to all regions), and heartbeat/cron fields

update_monitor

Update an existing monitor (type is fixed; only fields you pass change).

• Inputs: monitor_id (required), plus any of the create fields

delete_monitor

Permanently delete a monitor and its history. Irreversible.

• Inputs: monitor_id (required)

pause_monitor / unpause_monitor

Stop or resume checks and alerts for a monitor.

• Inputs: monitor_id (required)

trigger_check

Run an on-demand check of an existing monitor now and return the result.

• Inputs: monitor_id (required)

create_incident

Log a manual incident against a monitor.

• Inputs: monitor_id (required), started_at (required), status (open/resolved, required), root_cause

update_incident

Change an incident's status and/or root cause; resolving sets the end time and duration.

• Inputs: incident_id (required), status (open/resolved, required), root_cause

resolve_incident / acknowledge_incident

Mark an incident resolved (sets end time + duration), or log an acknowledgment.

• Inputs: incident_id (required)

delete_incident

Permanently delete an incident. Irreversible.

• Inputs: incident_id (required)