Monitoring — MCP Tools

21 tools in the Monitoring group of the Routebase MCP server.

generate_monitors_from_spec

Create monitors for many spec endpoints at once — the two steps of the generate wizard. 'preview' lists the endpoints of a spec with the ones that already have a monitor marked, so you can pick; 'create' then creates monitors for the endpoints you selected. Both need specId; 'create' also needs environmentId and endpoints. Requires project context.

Required scope: monitoring:write

Parameter	Type	Required	Description
action	string	Yes	What to do: 'preview' or 'create'
specId	string	Yes	Public ID (GUID) of the API specification
specVersionId	string	No	Public ID (GUID) of the spec version — defaults to the latest published version
environmentId	string	No	Public ID (GUID) of the environment the monitors check — required for 'create'
endpoints	string	No	Endpoints to create monitors for, as a JSON array. Each item needs endpointPublicId and may carry nameOverride, expectedStatusCodeOverride, intervalSecondsOverride and pathParameterValues (an object of parameter name to value, required for endpoints with path parameters). Example: [{"endpointPublicId":"...","pathParameterValues":{"id":"42"}}]. Get the ids from action 'preview'. Required for 'create'
defaultIntervalSeconds	integer	No	Seconds between checks for the created monitors, defaults to 300
defaultTimeoutSeconds	integer	No	Request timeout in seconds for the created monitors, defaults to 30
defaultSchemaMode	string	No	Response schema validation for the created monitors: 'off', 'warn' or 'strict'. Defaults to 'warn'

get_alert_policy

Get one alert policy with its full rule set and how many scopes it is assigned to. Requires project context.

Required scope: monitoring:read

Parameter	Type	Required	Description
policyId	string	Yes	Public ID (GUID) of the policy, from list_alert_policies

get_contract_drift

One contract drift event in full: per-field deviations with the value that actually arrived, the route, the request that was sent, and the response body they were read from (first 4 KB, credential headers redacted). Ids come from list_contract_drift. Requires project context.

Required scope: monitoring:read

Parameter	Type	Required	Description
driftEventId	string	Yes	Public ID (GUID) of the drift event
projectId	string	No	Public ID (GUID) of the project — defaults to the session context

get_monitor

Get one monitor with its recent checks. The include flags pull in what the monitor detail page shows next to it: uptime and latency percentiles over 24h to 90d, the alert policy that applies (inherited or its own), its maintenance windows, and the fire/resolve history of its alerts. Requires project context.

Required scope: monitoring:read

Parameter	Type	Required	Description
monitorId	string	Yes	Public ID (GUID) of the monitor, from list_monitors
includeUptimeStats	boolean	No (default false)	Include uptime percentages and response-time percentiles
includeEffectivePolicy	boolean	No (default false)	Include the alert policy that applies to this monitor and where it comes from
includeMaintenanceWindows	boolean	No (default false)	Include the maintenance windows that cover this monitor
includeAlertHistory	boolean	No (default false)	Include the fire/resolve history of this monitor's alerts
includeFreshnessWatches	boolean	No (default false)	Include watched field paths and how long each value has been unchanged

get_monitoring_settings

Get the project's monitoring defaults: how long check history is kept, the default check interval, timeout, incident threshold and schema validation mode, and whether monitors are created automatically when a spec is published. Requires project context.

Required scope: monitoring:read

Parameter	Type	Required	Description
projectId	string	No	Public ID (GUID) of the project — defaults to the project in the session context

get_monitoring_sync_status

Compare a spec against the monitors that exist for it in one environment: how much of it is covered, which endpoints have no monitor, which monitors point at endpoints that are gone, and how many are drift-watched. The starting point before generating monitors. Requires project context.

Required scope: monitoring:read

Parameter	Type	Required	Description
specId	string	Yes	Public ID (GUID) of the API specification
environmentId	string	Yes	Public ID (GUID) of the environment
projectId	string	No	Public ID (GUID) of the project — defaults to the project in the session context

get_schema_drift_report

Get what a monitor's schema validation found: per check whether it passed, and the drift items with their JSON path, severity, expected and actual value. Only returns something for monitors with schema validation on — see manage_drift_watch. Requires project context.

Required scope: monitoring:read

Parameter	Type	Required	Description
monitorId	string	Yes	Public ID (GUID) of the monitor, from list_monitors
from	string	No	Only checks at or after this UTC timestamp (ISO 8601)
to	string	No	Only checks at or before this UTC timestamp (ISO 8601)
take	integer	No (default 50)	Maximum number of checks to report on, defaults to 50

list_alert_policies

List the alert policies of a project with their rules. Set includeAssignments to also get which environments, specs and monitors each policy is attached to — that is where the assignmentId for unassigning comes from. Requires project context.

Required scope: monitoring:read

Parameter	Type	Required	Description
projectId	string	No	Public ID (GUID) of the project — defaults to the project in the session context
includeAssignments	boolean	No (default false)	Include the scope assignments of the policies

list_contract_drift

List the endpoints of a project whose live responses drift from their contract, grouped by endpoint with the drift items, how long it has lasted and the contract version checked against. Resolved events are left out unless asked for. Use get_schema_drift_report for one monitor's history. Requires project context.

Required scope: monitoring:read

Parameter	Type	Required	Description
projectId	string	No	Public ID (GUID) of the project — defaults to the session context
environmentId	string	No	Only drift in this environment, by its public ID (GUID)
minSeverity	string	No	Lowest severity to report: 'error' or 'warning'. Omit for all
status	string	No	'all' or 'resolved' includes closed events; omit for the open ones
lookbackDays	integer	No (default 7)	How far back to list RESOLVED events, in days (1-30, default 7)

list_incidents

List incidents across the organization, newest first, with the monitor that raised each one and its event timeline. Filter by status, by monitor, by environment or spec, and by time window. Works across the organization, no project context needed.

Required scope: monitoring:read

Parameter	Type	Required	Description
status	string	No	Only incidents in this state: 'open', 'acknowledged' or 'resolved'
monitorId	string	No	Public ID (GUID) of a monitor to filter by
environmentId	string	No	Public ID (GUID) of an environment to filter by
apiSpecId	string	No	Public ID (GUID) of an API specification to filter by
from	string	No	Only incidents started at or after this UTC timestamp (ISO 8601)
to	string	No	Only incidents started at or before this UTC timestamp (ISO 8601)
skip	integer	No (default 0)	Number of incidents to skip, defaults to 0
take	integer	No (default 50)	Maximum number of incidents to return, defaults to 50

list_maintenance_windows

List the maintenance windows of a project across all scopes, with the window ids needed to cancel them. Set activeOnly to see just the ones in effect right now. Requires project context.

Required scope: monitoring:read

Parameter	Type	Required	Description
projectId	string	No	Public ID (GUID) of the project — defaults to the project in the session context
activeOnly	boolean	No (default false)	Only windows that are in effect right now

list_monitor_checks

List the individual checks a monitor ran, newest first — status code, response time and the timing breakdown (DNS, connect, TLS, first byte). Set onlyErrors to see just the failures. Use from and to to narrow the window. Requires project context.

Required scope: monitoring:read

Parameter	Type	Required	Description
monitorId	string	Yes	Public ID (GUID) of the monitor, from list_monitors
from	string	No	Only checks at or after this UTC timestamp (ISO 8601, e.g. '2026-07-31T00:00:00Z')
to	string	No	Only checks at or before this UTC timestamp (ISO 8601)
onlyErrors	boolean	No	Only return checks that failed
skip	integer	No (default 0)	Number of checks to skip, defaults to 0
take	integer	No (default 50)	Maximum number of checks to return, defaults to 50

list_monitors

List the monitors of a project with their current status. Set grouped to see them as an environment → spec tree the way the sidebar shows them (paging does not apply then). Set includeStats to add 24h uptime, p95 latency and the response-time sparkline per monitor. Requires project context.

Required scope: monitoring:read

Parameter	Type	Required	Description
projectId	string	No	Public ID (GUID) of the project — defaults to the project in the session context
isEnabled	boolean	No	Only enabled (true) or only disabled (false) monitors — omit for all
grouped	boolean	No (default false)	Group as an environment → spec → monitor tree instead of a flat list
includeStats	boolean	No (default false)	Include 24h uptime, p95 latency and sparkline buckets per monitor
skip	integer	No (default 0)	Number of monitors to skip, defaults to 0
take	integer	No (default 100)	Maximum number of monitors to return, defaults to 100

manage_alert_policy

Create, change, delete or attach an alert policy — a named set of rules that decides when monitors raise an incident. 'create' needs name and rules; 'update' needs policyId and REPLACES the policy, fields you omit keep their current value; 'delete' needs policyId; 'assign' attaches the policy to a scope and needs policyId, scope and the id for that scope; 'unassign' needs assignmentId from list_alert_policies with includeAssignments; 'migrate_legacy_alerts' converts the project's per-monitor alert rules into policies once. For rules on a single monitor use manage_monitor_alert. Requires project context.

Required scope: monitoring:write

Parameter	Type	Required	Description
action	string	Yes	What to do: 'create', 'update', 'delete', 'assign', 'unassign' or 'migrate_legacy_alerts'
policyId	string	No	Public ID (GUID) of the policy — required for 'update', 'delete' and 'assign'
name	string	No	Policy name (e.g. 'Production — strict') — required for 'create'
description	string	No	Optional description
isEnabled	boolean	No	Whether the policy is active — used by 'update'
rules	string	No	Rules as a JSON array — required for 'create'. Each item needs alertType and condition, and may carry cooldownMinutes (defaults to 30). condition may be an object or a JSON string. Alert types and the condition each one needs: 'downtime' → {"consecutiveFailures":n}; 'latencyThreshold' → {"thresholdMs":n,"windowChecks":n}; 'errorRate' → {"thresholdPercent":1-100,"windowChecks":n}; 'schemaDrift' → {"minSeverity":"error"|"warning"|"info"}. Example: [{"alertType":"downtime","condition":{"consecutiveFailures":3}}]
scope	string	No	What the policy attaches to — required for 'assign': 'environment', 'apiSpec' or 'monitor'
environmentId	string	No	Public ID (GUID) of the environment — required for 'assign' with scope 'environment'
apiSpecId	string	No	Public ID (GUID) of the API specification — required for 'assign' with scope 'apiSpec'
monitorId	string	No	Public ID (GUID) of the monitor — required for 'assign' with scope 'monitor'
assignmentId	string	No	Public ID (GUID) of the assignment to remove — required for 'unassign'

manage_drift_event

Triage one contract drift event. 'acknowledge' marks it as owned — it stops counting as new but stays listed; 'resolve' closes it; 'reopen' undoes either. Drift that stops on its own is closed by the next clean check. Ids come from list_contract_drift. Requires project context.

Required scope: monitoring:write

Parameter	Type	Required	Description
action	string	Yes	What to do: 'acknowledge', 'resolve' or 'reopen'
driftEventId	string	Yes	Public ID (GUID) of the drift event
note	string	No	Optional note recorded on the event
projectId	string	No	Public ID (GUID) of the project — defaults to the session context

manage_drift_watch

Turn schema drift watching on or off for one spec in one environment. 'enable' provisions or updates a schema-validating monitor for every endpoint of the spec's latest published version — it is idempotent, so running it again after a publish picks up new endpoints. 'disable' stops the validation but keeps the monitors running as plain uptime checks. Both need specId and environmentId. Read the findings with get_schema_drift_report. Requires project context.

Required scope: monitoring:write

Parameter	Type	Required	Description
action	string	Yes	What to do: 'enable' or 'disable'
specId	string	Yes	Public ID (GUID) of the API specification
environmentId	string	Yes	Public ID (GUID) of the environment to watch
schemaMode	string	No	How strictly responses are validated — 'enable' only: 'warn' or 'strict'. Defaults to 'warn'
alertSharpness	string	No	How loudly drift is reported — 'enable' only: 'error' or 'warning'. Defaults to 'error'

manage_incident

Acknowledge or resolve incidents. Pass one incident id or several as a comma-separated list — several are handled as one bulk operation and the result reports how many succeeded and failed. 'acknowledge' marks an incident as seen and being worked on; 'resolve' closes it. The optional note is recorded on the incident timeline. Get the ids from list_incidents. Works across the organization, no project context needed.

Required scope: monitoring:write

Parameter	Type	Required	Description
action	string	Yes	What to do: 'acknowledge' or 'resolve'
incidentIds	string	Yes	Public ID (GUID) of the incident, or several separated by commas
note	string	No	Optional note recorded on the incident timeline

manage_maintenance_window

Plan or cancel a maintenance window — a period in which monitors keep running but do not raise incidents, and which is excluded from uptime. 'create' covers a whole scope and needs title, startsAt, endsAt, scope and the id for that scope; it can repeat on a cron schedule. 'create_for_monitor' is the short path for a one-off window on a single monitor and needs monitorId, title, startsAt and endsAt. 'delete' needs windowId from list_maintenance_windows. Requires project context.

Required scope: monitoring:write

Parameter	Type	Required	Description
action	string	Yes	What to do: 'create', 'create_for_monitor' or 'delete'
windowId	string	No	Public ID (GUID) of the window to cancel — required for 'delete'
title	string	No	What the window is about (e.g. 'Database migration') — required for both create actions
startsAt	string	No	When the window starts, as a UTC timestamp (ISO 8601, e.g. '2026-08-01T22:00:00Z') — required for both create actions
endsAt	string	No	When the window ends, as a UTC timestamp (ISO 8601) — required for both create actions
scope	string	No	What the window covers — required for 'create': 'environment', 'apiSpec' or 'monitor'
environmentId	string	No	Public ID (GUID) of the environment — required for 'create' with scope 'environment'
apiSpecId	string	No	Public ID (GUID) of the API specification — required for 'create' with scope 'apiSpec'
monitorId	string	No	Public ID (GUID) of the monitor — required for 'create_for_monitor', and for 'create' with scope 'monitor'
isRecurring	boolean	No (default false)	Whether the window repeats — 'create' only
cronExpression	string	No	Cron expression for the repeat (e.g. '0 2 * * SUN') — required when isRecurring is true
durationMinutes	integer	No	How many minutes each repeat lasts — used with isRecurring

manage_monitor

Create, change or run a monitor — an HTTP check against one URL on a fixed interval. 'create' needs name and targetUrl; 'update' needs monitorId and REPLACES the monitor, fields you omit keep their current value, so you can change one alone; 'delete' needs monitorId; 'toggle' needs monitorId and isEnabled (this is the ONLY way to enable or disable — 'update' does not touch it); 'toggle_custom_alerts' switches a monitor between the inherited alert policy and its own rules; 'trigger_check' runs one check right now and returns its result; 'set_freshness_watches' replaces the paths this monitor watches for values that stopped changing. To create many monitors from a spec at once use generate_monitors_from_spec. Requires project context.

Required scope: monitoring:write

Parameter	Type	Required	Description
action	string	Yes	What to do: 'create', 'update', 'delete', 'toggle', 'toggle_custom_alerts', 'trigger_check' or 'set_freshness_watches'
monitorId	string	No	Public ID (GUID) of the monitor — required for every action except 'create'
name	string	No	Monitor name (e.g. 'GET /customers — production') — required for 'create'
targetUrl	string	No	Absolute URL the check calls (e.g. 'https://api.example.com/customers') — required for 'create'
httpMethod	string	No	HTTP method to call, defaults to GET on 'create'
headers	string	No	Request headers as a JSON object string (e.g. '{"Authorization":"Bearer x"}')
requestBody	string	No	Request body to send, for POST/PUT/PATCH checks
intervalSeconds	integer	No	Seconds between checks, defaults to 300 on 'create'
timeoutSeconds	integer	No	Request timeout in seconds, defaults to 30 on 'create'
expectedStatusCode	integer	No	HTTP status code that counts as healthy, defaults to 200 on 'create'
region	string	No	Check region, defaults to 'default'
schemaValidationMode	string	No	Response schema validation: 'off', 'warn' or 'strict'. Defaults to 'warn' on 'create'
environmentId	string	No	Public ID (GUID) of the environment this monitor belongs to, from list_environments
isEnabled	boolean	No	Whether the monitor runs — required for 'toggle'
useCustomAlerts	boolean	No	Whether the monitor uses its own alert rules instead of the inherited policy — required for 'toggle_custom_alerts'
freshnessPaths	string	No	For 'set_freshness_watches': the COMPLETE set of watched paths as a JSON array (e.g. '["$.data.updatedAt"]'). Known paths keep their history, omitted ones are removed, '[]' clears them

manage_monitor_alert

Create, change or delete an alert rule that belongs to one monitor and overrides the inherited policy. The monitor must have custom alerts switched on — see manage_monitor action 'toggle_custom_alerts'. A monitor can hold at most one rule per alert type. 'create' needs monitorId, alertType and condition; 'update' needs monitorId and alertId, and keeps the fields you omit (the alert type itself cannot change); 'delete' needs both ids. Get alertId from get_monitor with includeAlertHistory. Alert types and the condition each one needs: 'downtime' → {"consecutiveFailures":n}; 'latencyThreshold' → {"thresholdMs":n,"windowChecks":n}; 'errorRate' → {"thresholdPercent":1-100,"windowChecks":n}; 'schemaDrift' → {"minSeverity":"error"|"warning"|"info"}. Requires project context.

Required scope: monitoring:write

Parameter	Type	Required	Description
action	string	Yes	What to do: 'create', 'update' or 'delete'
monitorId	string	Yes	Public ID (GUID) of the monitor the rule belongs to
alertId	string	No	Public ID (GUID) of the alert rule — required for 'update' and 'delete'
alertType	string	No	Alert type: 'downtime', 'latencyThreshold', 'errorRate' or 'schemaDrift' — required for 'create'
condition	string	No	The condition, as an object or a JSON string — required for 'create'. Shape depends on alertType, see the tool description
cooldownMinutes	integer	No	Minutes to wait before the rule can fire again, defaults to 30 on 'create'
isEnabled	boolean	No	Whether the rule is active — used by 'update'

update_monitoring_settings

Change the project's monitoring defaults. Settings you do not pass keep their current value. These apply to monitors created afterwards; existing monitors keep their own values. Requires project context.

Required scope: monitoring:write

Parameter	Type	Required	Description
retentionDays	integer	No	Days of check history to keep
defaultCheckIntervalSeconds	integer	No	Default seconds between checks for new monitors
defaultTimeoutSeconds	integer	No	Default request timeout in seconds for new monitors
defaultIncidentThreshold	integer	No	How many consecutive failures open an incident
defaultSchemaValidationMode	string	No	Default response schema validation for new monitors: 'off', 'warn' or 'strict'
autoCreateMonitorsOnSpecPublish	boolean	No	Whether publishing a spec creates monitors for its endpoints automatically