# devhelmhq/mcp-server [Health: Active]

**Category:** 📊 Monitoring  
**Repository:** https://github.com/devhelmhq/mcp-server  
**GitHub Stars:** 1  
**Views:** 2  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/mcp-server-113

## Description
Monitor uptime, manage incidents, configure alerting, and query dependency status via DevHelm

## Tools
Capabilities this server exposes over MCP:

- **list_monitors** — List all uptime monitors in the workspace.
- **get_monitor** — Get a single monitor by ID, including its full configuration.
- **create_monitor** — Create a new uptime monitor.

Required: name and type (HTTP, DNS, TCP, ICMP, HEARTBEAT,
MCP_SERVER, BROWSER, MULTI_STEP_API).

``config`` is required for probe types (HTTP, DNS, TCP, ICMP,
HEARTBEAT, MCP_SERVER). Browser and multi-step monitors use a
type default when ``config`` is omitted.

``frequencySeconds`` is optional (10–86400). Omit it to use the
plan minimum.

``managedBy`` is set automatically to ``MCP`` server-side; callers
cannot override it. Use the SDK or CLI directly if you need a
different attribution.
- **update_monitor** — Update an existing monitor's configuration.
- **delete_monitor** — Delete a monitor permanently.
- **pause_monitor** — Pause a monitor (stops checking until resumed).
- **resume_monitor** — Resume a paused monitor.
- **test_monitor** — Trigger an ad-hoc test run for a monitor and return the result.
- **list_monitor_results** — List recent check results for a monitor (cursor-paginated).
- **list_monitor_versions** — List version history for a monitor.
- **list_incidents** — List all incidents in the workspace.
- **get_incident** — Get a single incident by ID with full details.
- **create_incident** — Create a manual incident.

Required fields: title, severity (DOWN/DEGRADED/MAINTENANCE).
Optional: monitorId (UUID), body (detailed description).
- **resolve_incident** — Resolve an active incident, optionally with a resolution message.
- **get_incident_timeline** — Full forensic timeline for an incident.

Returns every recorded state transition for the incident, the
rule evaluations that caused each triggering transition, and the
policy snapshot in effect at the time.

Use this to explain why an incident was declared/confirmed/resolved,
or to audit a past detection decision.
- **get_check_trace** — Everything the detection engine recorded for a single check.

Includes the rule evaluations produced for this check_id, the
state transitions that fired (if any), and the policy snapshot
active at evaluation time. Use when a user references a specific
check execution ID (e.g. from a support ticket or webhook).
- **get_policy_snapshot** — Fetch a policy snapshot by its content-addressed SHA-256 hash.

Useful for inspecting the exact detection policy that was active
when a specific evaluation or transition happened — the hash is
stable, so historical data keeps pointing at the right policy
even if the monitor has been edited since.
- **list_monitor_rule_evaluations** — List rule evaluations produced for a monitor (paginated).

Filters:
  - rule_type: e.g. "consecutive_failures", "latency_threshold"
  - region: probe region, e.g. "us-east"
  - only_matched: if True, return only evaluations that fired
  - from_/to: ISO-8601 datetime bounds

Use to answer "which rules fired on monitor X in the last hour?".
- **list_monitor_transitions** — List state transitions recorded for a monitor (paginated).

A transition captures every WATCHING→TRIGGERED→CONFIRMED→RESOLVED
edge the detection engine walked. Includes transitions that
occurred before an incident was declared (incident_id = null).

Use to reconstruct the full reliability history of a monitor.
- **list_alert_channels** — List all alert channels configured in the workspace.
- **get_alert_channel** — Get an alert channel by ID.
- **create_alert_channel** — Create a new alert channel.

Required: name, type, config (type-specific).
Types: EMAIL, WEBHOOK, SLACK, PAGERDUTY, OPSGENIE, TEAMS,
DISCORD, TELEGRAM, GOOGLE_CHAT, PUSHOVER, MATTERMOST,
SPLUNK_ONCALL, PUSHBULLET, LINEAR, INCIDENT_IO, ROOTLY,
ZAPIER, DATADOG, JIRA, GITLAB.
- **update_alert_channel** — Update an existing alert channel.

Updatable fields: name, type, config (type-specific).
See create_alert_channel for supported types.
- **delete_alert_channel** — Delete an alert channel.
- **test_alert_channel** — Send a test notification to an alert channel to verify it works.
- **list_notification_policies** — List all notification policies in the workspace.
- **get_notification_policy** — Get a notification policy by ID.
- **create_notification_policy** — Create a notification policy.

Required: name, matchRules (list of {type, value?, monitorIds?, regions?}),
escalation ({steps: [{delayMinutes, channelIds}], onResolve?, onReopen?}),
enabled (bool), priority (int, higher = evaluated first).
- **update_notification_policy** — Update a notification policy.
- **delete_notification_policy** — Delete a notification policy.
- **test_notification_policy** — Send a test dispatch to verify a notification policy's routing.
- **list_environments** — List all environments in the workspace.
- **get_environment** — Get an environment by slug (e.g. 'production', 'staging').
- **create_environment** — Create an environment.

Required fields: name, slug, color.
- **update_environment** — Update an environment by slug.
- **delete_environment** — Delete an environment by slug.
- **list_secrets** — List all secrets (metadata only, values are never returned).
- **create_secret** — Create an encrypted secret.

Required fields: key, value. The value is encrypted at rest
and can be referenced in monitor auth configs as {{secrets.KEY}}.
- **update_secret** — Update a secret's value by key.
- **delete_secret** — Delete a secret by key.
- **list_tags** — List all tags in the workspace.
- **get_tag** — Get a tag by ID.
- **create_tag** — Create a tag.

Required fields: name. Optional: color.
- **update_tag** — Update a tag.
- **delete_tag** — Delete a tag.
- **list_resource_groups** — List all resource groups in the workspace.
- **get_resource_group** — Get a resource group by ID.
- **create_resource_group** — Create a resource group.

Required fields: name. Optional: description.
- **update_resource_group** — Update a resource group.
- **delete_resource_group** — Delete a resource group.
- **add_resource_group_member** — Add a monitor to a resource group.

Required fields: monitorId.
- **remove_resource_group_member** — Remove a monitor from a resource group.
- **list_webhooks** — List all webhook endpoints in the workspace.
- **get_webhook** — Get a webhook endpoint by ID.
- **create_webhook** — Create a webhook endpoint.

Required fields: url, events (list of event types to subscribe to).
- **update_webhook** — Update a webhook endpoint.
- **delete_webhook** — Delete a webhook endpoint.
- **test_webhook** — Send a test event to a webhook endpoint to verify it works.
- **list_api_keys** — List all API keys in the workspace.
- **get_api_key** — Get a single API key's metadata by id. The secret value is never returned.
- **create_api_key** — Create a new API key. The key value is returned only once.

Required fields: name. Optional: expiresAt.
- **revoke_api_key** — Revoke an API key (disables it without deleting).
- **delete_api_key** — Delete an API key permanently.
- **list_dependencies** — List all tracked service dependencies.
- **get_dependency** — Get a tracked dependency by ID.
- **track_dependency** — Start tracking a service dependency by its slug (e.g. 'github', 'aws').

Optionally track a single component via `component_id` (see
list_service_components) and set `alert_sensitivity`: AWARENESS
(silent tracking, default), INCIDENTS_ONLY, MAJOR_ONLY, or ALL.
- **update_dependency_alert_sensitivity** — Change how loudly a tracked dependency alerts you.

Levels: AWARENESS (silent tracking, default — status visible on the
dashboard but no notifications), INCIDENTS_ONLY (notify on any
incident), MAJOR_ONLY (notify only on major/critical incidents), and
ALL (every status change, including maintenance).
- **delete_dependency** — Stop tracking a service dependency.
- **search_services** — Search the catalog of third-party services (Stripe, GitHub, AWS, ...)
that can be tracked as dependencies.

Use `query` for free-text search by name (e.g. 'stripe', 'cloudflare')
and `category` to filter by catalog category (see
list_service_categories). Results are paginated; raise `limit`
(default 20) for broader sweeps.
- **get_service** — Get a catalog service's summary by slug (e.g. 'github'), including
its current status, categories, and component overview.
- **get_service_live_status** — Get the live (real-time) operational status of a catalog service,
fetched from its upstream status page. Use this when freshness matters
more than latency — e.g. 'is Stripe down right now?'.
- **get_services_summary** — Get the global status summary across the entire service catalog —
counts of operational / degraded / outage services. Use this for a
quick 'is anything broken on the internet right now?' overview before
drilling into a specific service.
- **list_service_categories** — List all service catalog categories (e.g. cloud, payments, devtools)
usable as the `category` filter in search_services.
- **list_service_components** — List a catalog service's components (e.g. 'API', 'Dashboard',
'Webhooks') with their individual statuses. Component IDs can be used
to track a single component via track_dependency.
- **get_service_uptime** — Get historical uptime stats for a catalog service over a period
(e.g. '7d', '30d', '90d'; default '30d').
- **list_service_incidents** — List incidents for a catalog service, or across all services when
`slug` is omitted. Filter by `status` (e.g. 'active', 'resolved') to
answer questions like 'which of my dependencies have open incidents?'.
- **get_service_incident** — Get one vendor incident in full detail, including the vendor's
timeline of status updates (investigating → identified → resolved).
Get incident IDs from list_service_incidents.
- **get_service_day_rollup** — Get a one-day rollup for a catalog service on a UTC calendar day
(ISO YYYY-MM-DD): aggregated uptime, per-component impact windows,
and the incidents that overlapped that day. Use this to answer
'what happened to Stripe on 2026-06-01?'.
- **get_component_uptime** — Get daily uptime history for a single component of a catalog
service (e.g. just the 'API' component of Stripe) over a period
('7d', '30d', '90d', '1y'; default '30d'). Get component IDs from
list_service_components.
- **get_all_components_uptime** — Get daily uptime history for every leaf component of a catalog
service in one call, keyed by component ID, over a period ('7d',
'30d', '90d', '1y'; default '30d'). Prefer this over repeated
get_component_uptime calls when comparing components.
- **list_service_maintenances** — List scheduled and past maintenance windows announced by a catalog
service (e.g. upcoming AWS maintenance that could affect you).
- **acquire_deploy_lock** — Acquire a deploy lock to prevent concurrent deployments.

Required: lockedBy (identity of requester, e.g. hostname or CI job ID).
Optional: ttlMinutes (default 30, max 60).
- **get_current_deploy_lock** — Get the currently active deploy lock, or null if unlocked.
- **release_deploy_lock** — Release a deploy lock by ID.
- **force_release_deploy_lock** — Force-release any active deploy lock (admin action).
- **list_maintenance_windows** — List maintenance windows for the workspace.

Use this BEFORE creating a new window to check whether someone
else (or an earlier agent run) already scheduled overlap, or
AFTER a deploy to confirm the window you opened is still
active.

Filters (all optional; combine freely):
  - ``monitor_id``: UUID of a monitor — only windows attached
    to that single monitor (org-wide windows are excluded).
  - ``status``: ``"active"`` for windows currently in
    progress, or ``"upcoming"`` for windows scheduled in the
    future. Past / cancelled windows are not returned by the
    API today; omit ``status`` for the broadest result.
- **get_maintenance_window** — Get a single maintenance window by ID with full details.
- **create_maintenance_window** — Schedule a maintenance window to suppress alerts during planned work.

Call this BEFORE running an operation that may legitimately
cause monitors to fail — a deploy, a database migration, a
third-party service's announced downtime — so the on-call
rotation isn't paged for known-expected failures. Always
pair every successful create with a follow-up
``cancel_maintenance_window`` once the operation finishes;
if the operation runs long, call ``update_maintenance_window``
to push the end time back rather than letting the window
lapse early.

Time fields use ISO 8601 / RFC 3339 timestamps with explicit
timezone — UTC strongly preferred. Example:
``"2026-05-15T14:00:00Z"``. Naive timestamps (no timezone)
are rejected by the API.

Body fields:
  - ``startsAt`` (required): when the window opens.
  - ``endsAt`` (required): when the window closes; must be
    strictly after ``startsAt``.
  - ``monitorId`` (optional): UUID of a single monitor to
    scope the window to. Omit (or set null) to make this an
    **org-wide window** that suppresses alerts on every
    monitor in the workspace — the right choice for a deploy
    or migration that touches the whole platform.
  - ``reason`` (optional): human-readable explanation
    ("v0.7.3 deploy", "Postgres major upgrade"). Surfaces in
    the dashboard and on-call channel; keep it specific.
  - ``repeatRule`` (optional): iCal RRULE string for
    recurring windows (max 100 chars), e.g.
    ``FREQ=WEEKLY;BYDAY=SU`` for weekly Sunday maintenance.
    Omit for one-time windows.
  - ``suppressAlerts`` (optional): whether the window
    actually silences alerts. Default ``true``; set
    ``false`` to record a maintenance window for audit
    without changing alerting behavior.
- **update_maintenance_window** — Update an in-flight or scheduled maintenance window.

The most common use is **extending** an active window when a
deploy runs longer than expected — call this with the new
``endsAt`` to keep alerts suppressed past the original
deadline. The endpoint is a full replacement (PUT, not
PATCH): pass the complete intended state, not a delta.
Any field omitted falls back to the underlying model's
default rather than preserving the existing value.

Time fields use ISO 8601 / RFC 3339 timestamps with explicit
timezone (UTC preferred), e.g. ``"2026-05-15T16:30:00Z"``.

Body fields (same schema as create):
  - ``startsAt`` (required)
  - ``endsAt`` (required)
  - ``monitorId`` (optional; null = org-wide)
  - ``reason`` (optional; null clears)
  - ``repeatRule`` (optional; null clears the recurrence)
  - ``suppressAlerts`` (optional)
- **cancel_maintenance_window** — Cancel a maintenance window — alerts resume immediately.

Call this AFTER a deploy or maintenance operation completes
successfully so any new monitor failures surface as real
incidents instead of being silently absorbed. If the window
was scheduled but not yet started, this prevents it from
ever opening.

The window record is removed; the audit log preserves the
historical fact that the window existed. There is no
"uncancel" — schedule a new window if you need to restore
suppression.
- **get_status_overview** — Get the dashboard overview with monitor counts,
incident summary, and uptime stats.
- **list_status_pages** — List all status pages in the workspace.
- **get_status_page** — Get a status page by ID, including branding and overall status.
- **create_status_page** — Create a new status page.

Required fields: name, slug.
Optional: description, branding (brandColor, theme, headerStyle, etc.),
visibility (PUBLIC/PASSWORD), enabled, incidentMode (MANUAL/REVIEW/AUTOMATIC).
- **update_status_page** — Update a status page's name, slug, branding, visibility, or incident mode.
- **delete_status_page** — Delete a status page permanently.
- **reorder_status_page_layout** — Batch-reorder a status page's full layout.

Required: sections — top-level layout in their new order, where each
entry is either {kind:"component", componentId} or
{kind:"group", groupId}. Use ``groupOrders`` (optional) to also
reorder components within specific groups; only include groups whose
internal order changed. The full top-level set must be provided —
partial reorders are rejected by the API.

Use this for "drag-and-drop" layout edits that touch both groups and
ungrouped components. To reorder components within a single group
only, prefer ``reorder_status_page_components``.
- **list_status_page_components** — List all components on a status page.
- **create_status_page_component** — Add a component to a status page.

Required fields: name, type (STATIC or MONITOR).
Optional: groupId (nest under a group), monitorId (for MONITOR type).
- **update_status_page_component** — Update a status page component's name, group, or status.
- **delete_status_page_component** — Remove a component from a status page.
- **reorder_status_page_components** — Reorder components on a status page.

Required: positions — list of {componentId, position} entries giving
every component its new zero-based ordinal. The full set must be
provided; partial reorders are rejected by the API.
- **list_status_page_groups** — List component groups on a status page (with nested components).
- **create_status_page_group** — Create a component group on a status page.

Required fields: name.
- **update_status_page_group** — Update a component group's name or display order.
- **delete_status_page_group** — Delete a component group from a status page.
- **list_status_page_incidents** — List incidents on a status page (paginated).
- **get_status_page_incident** — Get a status page incident with its full timeline of updates.
- **create_status_page_incident** — Create an incident on a status page.

Required fields: title, impact (NONE/MINOR/MAJOR/CRITICAL), body.
Optional: status (INVESTIGATING/IDENTIFIED/MONITORING/RESOLVED),
affectedComponents (list of {componentId, status}), notifySubscribers.

To schedule a maintenance window, use create_status_page_maintenance.
- **update_status_page_incident** — Update a status page incident's title, impact, status, or components.

Schedule fields belong on update_status_page_maintenance.
- **post_status_page_incident_update** — Post a timeline update on a status page incident.

Required fields: body (message text), status.
Optional: notifySubscribers (default true),
affectedComponents (list of {componentId, status}).
- **publish_status_page_incident** — Publish a draft incident (sets it live, notifies subscribers).

Use update_status_page_incident first if you need to change the draft's
title, impact, status, body, or affected components before publishing.
- **dismiss_status_page_incident** — Dismiss a draft incident (deletes it without publishing).
- **delete_status_page_incident** — Delete a status page incident permanently.
- **list_status_page_maintenance** — List maintenance windows on a status page (paginated).
- **get_status_page_maintenance** — Get a status page maintenance window with its full timeline of updates.
- **create_status_page_maintenance** — Create a maintenance window on a status page.

Required fields: title, impact (NONE/MINOR/MAJOR/CRITICAL), body,
scheduledFor (ISO 8601). Optional: scheduledUntil, autoResolve,
status, affectedComponents, notifySubscribers.
- **update_status_page_maintenance** — Update a maintenance window's title, impact, status, or schedule.
- **post_status_page_maintenance_update** — Post a timeline update on a status page maintenance window.

Required fields: body (message text), status.
Optional: notifySubscribers (default true),
affectedComponents (list of {componentId, status}).
- **publish_status_page_maintenance** — Publish a draft maintenance window (sets it live, notifies subscribers).
- **dismiss_status_page_maintenance** — Dismiss a draft maintenance window (deletes it without publishing).
- **delete_status_page_maintenance** — Delete a status page maintenance window permanently.
- **list_status_page_subscribers** — List confirmed subscribers on a status page (paginated).
- **add_status_page_subscriber** — Add a subscriber to a status page (admin).

Optional: email (legacy EMAIL), channel, destination,
componentIds, requireConfirmation.
- **remove_status_page_subscriber** — Remove a subscriber from a status page.
- **list_status_page_domains** — List custom domains on a status page.
- **add_status_page_domain** — Add a custom domain to a status page.

Required fields: hostname (e.g. "status.example.com").
Returns verification records (CNAME target and TXT token) that must
be configured in your DNS before calling verify.
- **verify_status_page_domain** — Trigger DNS verification for a custom domain.

Returns the updated domain with current verification status.
- **remove_status_page_domain** — Remove a custom domain from a status page.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `uvx` (confidence: high):

```json
"mcpServers": {
  "mcp-server": {
    "command": "uvx",
    "args": ["devhelm-mcp-server"],
    "env": {
      "DEVHELM_API_TOKEN": ""
    }
  }
}
```

**Requires environment variables:** `DEVHELM_API_TOKEN` — the values above are empty placeholders; fill in real credentials before running (see the repository for what each one is for).

## Documentation

## What devhelmhq/mcp-server does

devhelmhq/mcp-server exposes DevHelm monitoring and alerting operations through the Model Context Protocol. Agents can work with uptime monitors, incidents, alert channels, and notification policies without switching to a separate DevHelm client.

Monitor operations cover the full lifecycle: listing and inspecting monitors, creating configurations for supported probe types, editing or deleting them, pausing and resuming checks, and triggering an immediate test. Recent check results and monitor version history are also available.

Incident tools support workspace-wide listing, detailed retrieval, manual creation, resolution, and timeline analysis. A timeline includes state transitions, the rule evaluations behind triggering transitions, and the policy snapshot active at the time.

## How it works

The server can run as a hosted MCP endpoint at `https://mcp.devhelm.io/mcp` or locally over stdio. Hosted connections authenticate with a bearer token or, for clients that only accept a URL, an API key embedded in the endpoint path. Local execution uses the `devhelm-mcp-server` command or `uvx`.

Detection-focused tools provide historical context rather than only current status. A check trace ties one check execution ID to its rule evaluations, resulting transitions, and active policy snapshot. Policy snapshots are retrieved by content-addressed SHA-256 hash, allowing historical evaluations to be examined against the exact policy that was active at the time. Monitor rule evaluations and state transitions can be paginated and filtered by rule type, region, match status, or ISO-8601 time bounds.

## Setup and configuration

For local use, install the package with pip, set the API token, and start the server:

```bash
pip install devhelm-mcp-server
export DEVHELM_API_TOKEN=your-token
devhelm-mcp-server
```

The `uvx` alternative avoids a separate package installation:

```bash
export DEVHELM_API_TOKEN=your-token
uvx devhelm-mcp-server
```

Hosted clients can use either `https://mcp.devhelm.io/mcp` with an `Authorization: Bearer <your-api-token>` header or `https://mcp.devhelm.io/<your-api-token>/mcp` when only a URL can be configured. Cursor and Claude Desktop can be configured with the hosted URL in their MCP server settings; Windsurf is also named as a supported MCP client.

## Tools and capabilities

- Create monitors for HTTP, DNS, TCP, ICMP, heartbeat, MCP server, browser, and multi-step API checks.
- Set monitor frequencies from 10 to 86,400 seconds, subject to the plan minimum.
- Pause, resume, test, update, and delete monitors, then inspect results and version history.
- Create and resolve incidents with severity values of `DOWN`, `DEGRADED`, or `MAINTENANCE`.
- Reconstruct detection history through incident timelines, check traces, rule evaluations, and state transitions.
- Manage alert channels such as email, webhooks, Slack, PagerDuty, Opsgenie, Teams, Discord, and other listed destinations.
- Define notification policies with match rules, escalation steps, enablement state, and evaluation priority.

Monitor configuration is required for probe-based monitor types, while browser and multi-step monitors can use their type default when configuration is omitted. Monitor attribution is assigned server-side as `MCP` and cannot be overridden through these tools. Alert channel configuration is type-specific, and notification policies require match rules, escalation steps, an enabled flag, and a priority.

## Limitations and notes

Creating a monitor requires a name and type; probe types also require configuration. Creating an incident requires a title and severity, with monitor association and a detailed body available optionally. Detection history and result collections use pagination where specified, so callers may need to follow cursors for complete results. Deleting monitors and alert channels is permanent, while pausing a monitor stops checks until it is resumed.

_Full upstream README: https://allmcps.com/mcp/mcp-server-113/readme_