MCP / AI IntegrationModel Context Protocol server for AI assistants and agents

Overview

WebSignal exposes an MCP (Model Context Protocol) server, allowing AI assistants, copilots, and autonomous agents to interact with your monitoring data programmatically. MCP provides a structured, tool-based interface specifically designed for LLM consumption.

With MCP, your AI assistant works on your monitoring through 28 tools over a standard JSON-RPC protocol over HTTP. 15 of them change something in your account rather than only reading it, which is why a write needs both a plan that allows it and a workspace role that allows it. Every one of them is listed under Tools below, under the service it belongs to, with the description the server itself publishes for it - which is the only description of this tool list that cannot fall behind the list.

Plan requirement: MCP read access requires the Growth plan or above. MCP write access requires the Pro plan or above, and that is all 15 of the tools that change anything - not a subset of them. On Growth, every one of those tools refuses with a message naming the plan, and the read tools keep working.

Connection

PropertyValue
MCP endpointhttps://api.websignal.io/mcp
TransportStreamable HTTP
Protocol version2026-07-28
Discoveryhttps://api.websignal.io/.well-known/mcp.json
OAuth discoveryhttps://api.websignal.io/.well-known/oauth-authorization-server

Authentication

Most MCP tools require OAuth 2.0 Bearer tokens, identical to the REST API. The server supports:

Note: The check_http_availability_latency tool is publicly accessible without authentication (rate-limited to 1 request per minute per IP).

Workspace scoping

Monitors, incidents, and alerts belong to a workspace, so tools that read or change them resolve against exactly one. Send the workspace id in the X-Workspace-Id header on every MCP request:

Authorization: Bearer <access_token>
X-Workspace-Id: 0YYMZFSd5AA

If you omit it, the server falls back to your only workspace when you belong to exactly one, which is what most solo accounts see; anyone who belongs to several should send the header so the agent doesn’t act on the wrong one. Fetch the ids from GET /api/v1/workspaces, and see Workspaces for the role model that governs which tools a member may use.

Quick Start

1. Initialize MCP Session

POST https://api.websignal.io/mcp
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2026-07-28",
    "capabilities": {},
    "clientInfo": {
      "name": "my-client",
      "version": "1.0.0"
    }
  }
}

2. List Available Tools

POST https://api.websignal.io/mcp
Content-Type: application/json
Mcp-Session-Id: <from initialize response>

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list"
}

3. Call a Tool

POST https://api.websignal.io/mcp
Content-Type: application/json
Authorization: Bearer <token>
Mcp-Session-Id: <from initialize response>

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "list_monitors",
    "arguments": {}
  }
}

Tools

incidents

Incident management and querying via MCP protocol

ToolDescription
list_all_incidentsList all incidents for the authenticated user's monitors. Returns an array of incident objects with fields: id, monitorId, monitorName, incidentType (Availability|SslExpiry|Latency|Dns), status (Ongoing|Investigating|Resolved), isClosed, acknowledged, started (ISO 8601), ended (ISO 8601 or null if ongoing), durationFormatted (human-readable), failureReason. Supports pagination via page/pageSize, or date range filtering via startDate/endDate/maxResults. Use list_open_incidents for only active incidents, or get_incident for full details including notes.
list_open_incidentsList only open/unresolved incidents for the authenticated user's monitors. Excludes resolved and closed incidents. Returns the same fields as list_all_incidents: id, monitorId, monitorName, incidentType, status, isClosed, acknowledged, started, ended, durationFormatted, failureReason. Supports pagination via page/pageSize parameters.
get_incidentGet full details for a single incident including notes, acknowledgement info, and type-specific context. Returns: id, monitorId, monitorName, incidentType, status, isClosed, acknowledged, acknowledgedAt, acknowledgedBy, closedBy, started, ended, durationFormatted, failureReason, context (type-specific JSON), and notes array (each with id, note, createdAt, createdBy). Use list_all_incidents or list_open_incidents first to find the incident ID.
get_incident_notesGet all notes for a specific incident, ordered by most recent first. Returns an array of note objects with fields: id, note (text content), createdAt (ISO 8601), createdBy (user identifier), lastModified, modifiedBy. Use get_incident to see notes alongside full incident details.
acknowledge_incidentAcknowledge or unacknowledge an incident. Acknowledging records who acknowledged it and when. Returns the full updated incident object (same fields as get_incident). Cannot modify closed incidents. Set acknowledged=false to unacknowledge. Requires the Pro plan or above: on a lower plan this refuses and changes nothing.
close_incidentClose an incident, marking it as resolved. Sets status to Resolved, records who closed it, and sets the ended timestamp if not already set. Closed incidents cannot be modified further. Returns the full updated incident object (same fields as get_incident). Requires the Pro plan or above: on a lower plan this refuses and changes nothing.
add_incident_noteAdd a note to an incident for tracking investigation progress, root cause analysis, or resolution steps. Returns the created note object with fields: id, incidentId, note, createdAt, createdBy. Cannot add notes to closed incidents. Use get_incident_notes to view existing notes. Requires the Pro plan or above: on a lower plan this refuses and changes nothing.

Auth: Required (Bearer)

monitors

Monitor management and status querying via MCP protocol

ToolDescription
list_monitorsList all monitors for the authenticated user with current status. Returns an array of monitor objects with fields: id, name, url, healthStatus (available|unavailable|degraded|pending, where pending means no check has completed yet), monitoringStatus (enabled|disabled|paused), monitorTypes (array of enabled types: HttpAvailability, SslCertificate, Latency, Dns, TcpUdp, PageAssets), checkInterval (ISO 8601 duration), lastChecked (ISO 8601 or null), created (ISO 8601), lastModified (ISO 8601). Supports optional filtering by status and monitoringStatus parameters. Use get_monitor for full details including latest test result and incident.
get_monitorGet full details for a single monitor including configuration, latest test result, and latest incident. Returns: id, name, url, healthStatus, monitoringStatus, monitorTypes, checkInterval, lastChecked, created, lastModified, numberOfChecksBeforeAlert, reporting (dailyReport, weeklyReport, monthlyReport), latestTestResult (responseTime, statusCode, wasAvailable, started, ended, failureReason or null), latestIncident (id, status, started, ended, failureReason or null if no incidents). Use list_monitors first to find the monitor ID.
get_monitor_uptimeGet uptime percentage for a monitor over a specified time window. Returns: monitorId, monitorName, url, daysBack, periodStart (ISO 8601), periodEnd (ISO 8601), totalChecks, healthyChecks, unhealthyChecks, uptimePercentage (0-100 with 4 decimal places), uptimeFormatted (e.g. '99.95%'). Calculated from actual health check results stored in the database. Use list_monitors first to find the monitor ID.

Auth: Required (Bearer)

monitor-writes

Create, edit, pause, resume and delete monitors via MCP protocol

ToolDescription
create_monitorCREATES a new monitor in the current workspace and starts checking it. This is a write: it adds a monitor that will run checks, count against the workspace's plan allowance, and raise incidents and alerts when it fails. Takes the essentials only - name, url, http method, check interval, expected status codes, extra regions, whether to start enabled. Everything else (SSL, latency, DNS and TCP/UDP sub-checks, request headers, report schedules) takes its default and is configured in the WebSignal app. Refused if the workspace is already at its monitor limit, or if the regions asked for exceed the plan's allowance. Returns the new monitor's id, name, url and monitoring status. Requires the Pro plan or above: on a lower plan this refuses and changes nothing.
update_monitorCHANGES an existing monitor's configuration. This is a write: it edits what is checked and how often, which affects when incidents are raised and alerts sent. Only the values given are changed; anything omitted keeps what the monitor already has, including its sub-checks, headers and report schedules. The monitor must belong to the current workspace; one in another workspace is refused as though it did not exist. Use list_monitors or get_monitor to find the id. Returns the monitor as it now is. Requires the Pro plan or above: on a lower plan this refuses and changes nothing.
pause_monitorSTOPS a monitor checking, without deleting it. This is a write: while paused the monitor runs no checks, raises no incidents and sends no alerts, and its uptime figure stops moving. Its history and configuration are kept. Reversible with resume_monitor, so this does NOT ask the user to confirm. Pausing a monitor that is already paused changes nothing and says so. Returns the monitor and its new status. Requires the Pro plan or above: on a lower plan this refuses and changes nothing.
resume_monitorSTARTS a paused monitor checking again. This is a write: checks resume on the monitor's own interval and it can raise incidents and send alerts once more. Also clears the automatic wind-down that slows down a monitor which has been failing for a long time, so a monitor resumed against a url that is still broken gets its full runway again rather than being wound down on the next sweep. Returns the monitor and its new status. Requires the Pro plan or above: on a lower plan this refuses and changes nothing.
delete_monitorDELETES a monitor and everything recorded against it. This is irreversible from here: its checks stop, and its incidents, check history and uptime record go with it. The action groups attached to it are not deleted; they stay in the workspace and keep working for other monitors. ASK THE PERSON FIRST, then call again with userConfirmed. Without it this deletes nothing and tells you what to put to them. Use get_monitor if you need the name, address and uptime record to show them. The reply reports whether an open incident went with it. If the intention is only to stop the checks, use pause_monitor instead. Requires the Pro plan or above: on a lower plan this refuses and changes nothing.

Auth: Required (Bearer)

action-groups

Query the alert destinations configured in a workspace via MCP protocol

ToolDescription
list_action_groupsList every alert destination (action group) in the current workspace. Returns an object with count and actionGroups, each having fields: id, name, type (Email|Sms|Webhook|Slack|MicrosoftTeams), enabled, monitorCount (how many monitors alert through it). A destination with a monitorCount of zero is configured but alerting nothing. Use get_action_group for which monitors a particular one covers.
get_action_groupGet one alert destination (action group) with how many monitors use it. Returns: id, name, type, enabled, created (ISO 8601), associatedMonitorCount. The destination must belong to the current workspace; one in another workspace is reported as not found. Use list_action_groups to find the id.

Auth: Required (Bearer)

action-group-writes

Create and delete alert destinations and attach them to monitors via MCP protocol

ToolDescription
create_email_action_groupCREATES an email alert destination and attaches it to a monitor. This is a write, and it has an effect outside WebSignal: the address given will start receiving mail whenever that monitor goes down or recovers. Check the address with the user before calling this; nothing asks the owner of the mailbox to opt in. The monitor must belong to the current workspace. Returns the destination's name, the address and the monitor it now alerts for. Requires the Pro plan or above: on a lower plan this refuses and changes nothing.
create_webhook_action_groupCREATES a webhook alert destination and attaches it to a monitor. This is a write, and it has an effect outside WebSignal: the url given will start receiving HTTP requests from WebSignal whenever that monitor goes down or recovers. Confirm the url with the user first. The monitor must belong to the current workspace. Returns the destination's name, the url and the monitor it now alerts for. Requires the Pro plan or above: on a lower plan this refuses and changes nothing.
attach_action_groupATTACHES an existing alert destination to a monitor, so that monitor starts alerting through it. This is a write with an effect outside WebSignal: the address, url or channel behind the destination will begin receiving this monitor's alerts as well as those of any monitor it was already attached to. Both the destination and the monitor must belong to the current workspace. Attaching one that is already attached changes nothing. Use list_action_groups and list_monitors to find the ids. Requires the Pro plan or above: on a lower plan this refuses and changes nothing.
detach_action_groupDETACHES an alert destination from a monitor, so that monitor stops alerting through it. This is a write, and it is the one that makes alerting QUIETER: after this the monitor may have no way left to tell anybody it is down. Check with get_monitor or list_action_groups that something else still covers it. The destination itself is not deleted and keeps working for other monitors. Both the destination and the monitor must belong to the current workspace. Requires the Pro plan or above: on a lower plan this refuses and changes nothing.
delete_action_groupDELETES an alert destination outright, removing it from EVERY monitor that uses it. Irreversible from here, and the quietest kind of change there is: a monitor left with no destinations keeps checking and tells nobody when it fails. If the intention is to stop one monitor alerting through it, use detach_action_group instead, which leaves the destination in place. ASK THE PERSON FIRST, then call again with userConfirmed. Without it this deletes nothing and tells you how many monitors lose an alert path, which is the thing to put to them. The reply names the monitors in this workspace that were affected and counts the ones in the caller's other workspaces. Requires the Pro plan or above: on a lower plan this refuses and changes nothing.

Auth: Required (Bearer)

monitor-check

Run ad-hoc HTTP availability and latency checks via MCP protocol

ToolDescription
check_http_availability_latencyRun a single HTTP request against any URL and return availability and latency metrics. Returns: url, method, statusCode (HTTP status), isAvailable (true if 2xx/3xx), latencyMs (response time in milliseconds), checkedAtUtc (ISO 8601 timestamp), error (empty if successful). Useful for quick health checks, debugging connectivity, or validating a website is reachable.

Auth: Required (Bearer)

workspaces

List, switch, rename and delete workspaces via MCP protocol

ToolDescription
list_workspacesList every workspace the authenticated user belongs to. Returns an array of objects with fields: id, name, plan (Starter|Growth|Pro|Enterprise), role (Owner|Admin|Editor|Responder|Viewer), isCurrent (whether this is the workspace other tools act in), mcpEnabled (whether MCP may reach it at all), joinedAt (ISO 8601). A workspace holds its own monitors, alerts, incidents, status pages and plan; nothing is shared between them. Use switch_workspace to change which one the other tools operate on.
get_current_workspaceThe workspace every other tool is currently acting in. Returns id, name, plan, role, mcpEnabled, and the monitor count. Worth calling before anything that creates or deletes, so the answer names the workspace it is about to affect.
switch_workspaceChange which workspace every other tool acts in. IMPORTANT: this is not limited to this conversation. The current workspace is stored against the user's membership and is the same one their browser reads, so switching here also moves what they see when they next load the app or open a new tab. Tell the user before calling it. Takes the workspace id from list_workspaces. Returns the workspace now in use. Requires the Pro plan or above: on a lower plan this refuses and changes nothing.
rename_workspaceRename the current workspace. Owner only. Returns the workspace with its new name. Does not change its plan, its monitors, or which workspace is current. Requires the Pro plan or above: on a lower plan this refuses and changes nothing.
create_workspaceExplains how to create an additional workspace. Does NOT create one. Every workspace after the first is on a paid plan and is paid for before it exists, so this cannot be completed by a tool - it returns the page a person opens to buy one. Give the user the url; do not tell them a workspace has been created, because none has.

Auth: Required (Bearer)

Capabilities

CapabilitySupported
ToolsYes
ResourcesNo
PromptsNo