Devhelm Mcp Server

by devhelmhq

292 downloads
Not rated
GitHub

About

MCP server for uptime monitoring, incident management, alerting, and dependency status tracking. Gives AI agents tools to create and manage HTTP/DNS/TCP/ICMP monitors, handle incidents, configure alert channels, and query third-party service health.

Details

Author
devhelmhq
Downloads
292
Categories
Developer Tools, Infrastructure

- 70+ tools for DevHelm monitoring management
- Supports hosted (URL) and local stdio modes
- Works with multiple AI coding assistants
- Manage monitors, incidents, alert channels, and more
- Includes environment, webhook, and API key tools
- Offers deploy locks and status page management

Setting up with Highlight

This MCP is not yet compatible with Highlight’s one-click setup. However, you can still use it with Highlight by following these steps:

  1. Download and install Highlight from highlightai.com/download
  2. Navigate to the plugins tab and select "Add Custom Plugin"
  3. Configure the plugin with the settings below
    Plugin Name Devhelm Mcp Server
    Command (node, npx, python, etc.)

    Please refer to the README for specific instructions on how to obtain API keys or other required environment variables.

  4. Enable "Start Automatically" if you want the plugin to start when Highlight launches

From the repository

Use hosted mode by providing a URL (no installation required) or install locally via pip/uvx for stdio mode. The server works with Cursor, Claude Desktop, Windsurf, and any MCP-compatible client.

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 fields: name, type (HTTP/DNS/TCP/ICMP/MCP/HEARTBEAT), config (type-specific), frequencySeconds (30-86400). ``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). Optional: body, status (INVESTIGATING/IDENTIFIED/MONITORING/RESOLVED), affectedComponents (list of {componentId, status}).

update_status_page_incident

Update a status page incident's title, impact, or status.

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_subscribers

List confirmed subscribers on a status page (paginated).

add_status_page_subscriber

Add a subscriber to a status page (admin). Required fields: email.

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 / Cursor

Paste into your MCP client config file to install this server.

{
    "mcpServers": {
        "devhelm mcp server": {
            "devhelm": {
                "url": "https://mcp.devhelm.io/<your-api-token>/mcp"
            }
        }
    }
}

McpServers

{
    "devhelm": {
        "url": "https://mcp.devhelm.io/<your-api-token>/mcp"
    }
}

DevHelm MCP Server connects AI coding assistants to the DevHelm monitoring platform. It exposes 70+ tools across monitors, incidents, alert channels, notification policies, environments, webhooks, API keys, dependencies, deploy locks, status pages, and more.

Supports hosted mode (no install, just a URL) and local stdio mode via pip/uvx. Works with Cursor, Claude Desktop, Windsurf, and any MCP-compatible client.

No reviews yet — be the first

Sign in to leave a review

Use Google, GitHub, or an email account so ratings stay tied to real people.

Email sign in

No reviews posted yet.