# monit.rs (remote · monit.rs)

Schema-aware API monitoring: diff OpenAPI specs for breaking changes, manage endpoints.

- Trust score: 71/100 (medium)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-23

## Components

- remote · `monit.rs`: 71/100 (this document), [markdown](https://verifymcp.io/servers/rs-monit-monit-rs/integrations-mcp.md), [page](https://verifymcp.io/servers/rs-monit-monit-rs/integrations-mcp)

## Channel facts

- Endpoint: `https://monit.rs/integrations/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.2.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-23.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 22 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 69/100
  - AI-judged instruction clarity (good).
  - Tool/resource definitions use about 1492 tokens (~67/item across 22 items; 22 tools + 0 resources), lean.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 63/100
  - Stability observed for 19 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 71/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
  - Structured output schemas are declared (41% of tools); any adoption earns full credit.
- **Tool Safety**: 75/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "delete_endpoint" implies "delete" and declares no destructiveHint at all, which the MCP spec reads as destructive by default.
  - An AI judge read all 22 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the monit.rs MCP server?

monit.rs is a hosted endpoint at https://monit.rs/integrations/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http rs-monit-monit-rs 'https://monit.rs/integrations/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "rs-monit-monit-rs": {
      "url": "https://monit.rs/integrations/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "rs-monit-monit-rs": {
      "type": "http",
      "url": "https://monit.rs/integrations/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.rs-monit-monit-rs]
url = "https://monit.rs/integrations/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "rs-monit-monit-rs": {
      "type": "remote",
      "url": "https://monit.rs/integrations/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add rs-monit-monit-rs --url 'https://monit.rs/integrations/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  rs-monit-monit-rs:
    url: "https://monit.rs/integrations/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "rs-monit-monit-rs": {
      "Transport": "http",
      "Url": "https://monit.rs/integrations/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add rs-monit-monit-rs -t streamable-http -u 'https://monit.rs/integrations/mcp'
```

### Other

```json
{
  "mcpServers": {
    "rs-monit-monit-rs": {
      "type": "http",
      "url": "https://monit.rs/integrations/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-23 (score 71, +1)

No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-21 (score 70, +1)

No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-19 (score 69, +1)

No change was recorded against any check on this day. Stability & Change Management went from 47 to 50. That category is still filling its 30-day observation window: 14 days of observed history at the previous scan, 15 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-17 (score 68, +1)

No change was recorded against any check on this day. Stability & Change Management went from 40 to 43. That category is still filling its 30-day observation window: 12 days of observed history at the previous scan, 13 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-15 (score 67, +1)

- [functional] New tool “set_endpoint_assertions”

### 2026-10-12 (score 66, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 27. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-10 (score 65, +1)

No change was recorded against any check on this day. Stability & Change Management went from 13 to 20. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-08 (score 64, +2)

- [functional improvement] Stability: unverified → 0.13

## MCP tools (22)

### `openapi_diff` (~143 tokens)

Compare two OpenAPI 3.x specifications and classify every change
    as breaking, non-breaking, or info.

    Use this when you want to know if a candidate OpenAPI spec change
    is safe to ship or will break existing clients. The diff covers
    paths, operations, parameters, request bodies, responses, and
    response-body schema fields (added/removed/retyped, required toggle).

    Both arguments are the OpenAPI spec as a JSON or YAML string.
    Returns {summary: {breaking, non_breaking, info}, changes: [...]}.

Input parameters:

- `new_spec` (string, required)
- `old_spec` (string, required)

Output parameters:

- `result` (object)

### `monit_rs_stats` (~74 tokens)

Get live aggregate statistics for the monit.rs platform.

    Returns approximate counts of regressions caught, AI analyses
    generated, and probes executed across all monitored APIs to date.
    Useful when answering "does monit.rs actually work at scale?" — the
    numbers are real, within about 5% of exact.

Output parameters:

- `result` (object)

### `monit_rs_describe` (~80 tokens)

Return the canonical product description for monit.rs.

    Use this when a user asks what monit.rs is, what it does, how it
    differs from Pingdom / Checkly / UptimeRobot, or for product URLs.
    The response is the curated content from monit.rs/llms.txt — the
    operator's authoritative description.

Output parameters:

- `result` (string)

### `list_my_endpoints` (~52 tokens)

List all monitored endpoints owned by the authenticated account.

    Returns brief records suitable for LLM enumeration. For full detail
    (headers, spec URL, heartbeat_token) use `describe_endpoint(id)`.

Output parameters:

- `result` (array)

### `list_my_incidents` (~72 tokens)

List incidents on the caller's account. Defaults to only OPEN incidents.

    Fields include the incident's dedup_key — pass this to
    `acknowledge_incident` or `resolve_incident` to act on it.

Input parameters:

- `limit` (integer)
- `status` (string)

Output parameters:

- `result` (array)

### `list_my_regressions` (~43 tokens)

List detected schema regressions on the caller's account.
    Optionally filter by endpoint_id.

Input parameters:

- `endpoint_id`
- `limit` (integer)

Output parameters:

- `result` (array)

### `get_endpoint_uptime` (~37 tokens)

Aggregated uptime summary for an endpoint over the requested window.

Input parameters:

- `endpoint_id` (string, required)
- `window` (string)

### `describe_endpoint` (~34 tokens)

Full detail for one endpoint. Use `list_my_endpoints()` to get the ID.

Input parameters:

- `endpoint_id` (string, required)

### `acknowledge_incident` (~40 tokens)

Mark an incident as acknowledged. Use `list_my_incidents()` to
    find the dedup_key.

Input parameters:

- `dedup_key` (string, required)

### `resolve_incident` (~29 tokens)

Close an incident. Symmetric to acknowledge_incident.

Input parameters:

- `dedup_key` (string, required)

### `create_endpoint` (~53 tokens)

Create a new monitored endpoint. Respects your tier's max_endpoints cap.

Input parameters:

- `interval_seconds` (integer)
- `method` (string)
- `name` (string, required)
- `url` (string, required)

### `set_endpoint_assertions` (~110 tokens)

Replace an endpoint's body assertions.

    Each assertion is {"path": "$.ok", "op": "equals", "value": true}.
    Operators: equals, not_equals, exists, not_exists, gt, gte, lt, lte,
    contains, not_contains, empty, not_empty. A failing assertion marks the
    endpoint DOWN, so it counts against uptime. Pass [] to clear.

Input parameters:

- `assertions` (array, required)
- `endpoint_id` (string, required)

### `delete_endpoint` (~169 tokens)

Delete a monitored endpoint. Cascades: removes test_results,
    baselines, regressions, incidents attached to it.

    Guarded by two safety layers beyond the scope check:

    1. `confirm_by_typing_the_endpoint_name` MUST equal the endpoint's
       exact `.name` (case-sensitive, whitespace-trimmed). Prevents
       an untargeted "delete stuff" LLM-injection: the model has to
       first `describe_endpoint(id)` to learn the name, then include
       it verbatim.

    2. Per-user destructive-op cap of 5/day. Legitimate bulk deletes
       should use the HTTP API or dashboard.

Input parameters:

- `confirm_by_typing_the_endpoint_name` (string, required)
- `endpoint_id` (string, required)

### `list_alert_channels` (~60 tokens)

List alert channels configured on the authenticated account.

    Does NOT return decrypted config (webhook URLs, PagerDuty routing keys,
    etc.). Use the dashboard or `describe_alert_channel` HTTP API when you
    need to inspect the actual config.

Output parameters:

- `result` (array)

### `list_status_pages` (~19 tokens)

List public status pages owned by the authenticated account.

Output parameters:

- `result` (array)

### `list_security_findings` (~40 tokens)

List security findings detected on the caller's monitored endpoints.
    Optionally filter by severity.

Input parameters:

- `limit` (integer)
- `severity`

Output parameters:

- `result` (array)

### `describe_incident` (~50 tokens)

Full detail for one incident. Use `list_my_incidents()` to find the
    dedup_key. Includes the incident's endpoint name and current status.

Input parameters:

- `dedup_key` (string, required)

### `pause_endpoint` (~40 tokens)

Pause a monitored endpoint (stops probing, keeps history). Idempotent
    — no-op if already paused.

Input parameters:

- `endpoint_id` (string, required)

### `resume_endpoint` (~45 tokens)

Resume a paused endpoint. Rejects if resuming would exceed your tier's
    active-endpoint cap (upgrade or pause another endpoint first).

Input parameters:

- `endpoint_id` (string, required)

### `update_endpoint_interval` (~66 tokens)

Change how often an endpoint is probed. Minimum interval varies by
    tier (free=900s, developer=300s, starter=60s, pro/scale/enterprise=30s).

Input parameters:

- `endpoint_id` (string, required)
- `interval_seconds` (integer, required)

### `create_status_page` (~81 tokens)

Create a public status page at https://<slug>.status.monit.rs.
    Add endpoints to it via the dashboard or the HTTP API (adding
    endpoints from chat is deliberately not exposed — the mapping is
    fiddly and easy to get wrong).

Input parameters:

- `description`
- `slug` (string, required)
- `title` (string, required)

### `create_alert_channel` (~155 tokens)

Create an alert channel. Pass EXACTLY one of email_address /
    webhook_url / pagerduty_routing_key matching the channel_type:

      - channel_type='email'     → email_address='ops@example.com'
      - channel_type='webhook'   → webhook_url='https://your-endpoint'
      - channel_type='slack'     → webhook_url='https://hooks.slack.com/...'
      - channel_type='pagerduty' → pagerduty_routing_key='<Events v2 key>'

Input parameters:

- `channel_type` (string, required)
- `email_address`
- `min_severity` (string)
- `pagerduty_routing_key`
- `webhook_url`

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/rs-monit-monit-rs/integrations-mcp#diagnostics

## Score history

- 2026-10-23: 71
- 2026-10-22: 70
- 2026-10-21: 70
- 2026-10-20: 69
- 2026-10-19: 69
- 2026-10-18: 68
- 2026-10-17: 68
- 2026-10-16: 67
- 2026-10-15: 67
- 2026-10-14: 66
- 2026-10-13: 66
- 2026-10-12: 66
- 2026-10-10: 65
- 2026-10-08: 64
- 2026-10-04: 62

## Common questions

### What is the monit.rs MCP server?

monit.rs is an MCP server listed in the public MCP registry as rs.monit/monit-rs. Schema-aware API monitoring: diff OpenAPI specs for breaking changes, manage endpoints. This page covers its hosted endpoint (https://monit.rs/integrations/mcp).

### Is the monit.rs MCP server safe to use?

monit.rs scores 71 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the monit.rs MCP server expose?

monit.rs exposes 22 tools: openapi_diff, monit_rs_stats, monit_rs_describe, list_my_endpoints, list_my_incidents, and 17 more. Their descriptions and schemas cost roughly 1,492 tokens of context every time the server is loaded.

### Does the monit.rs MCP server require authentication?

No. We connected to monit.rs without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the monit.rs MCP server still maintained?

monit.rs is still listed as active in the MCP registry. We last reached this channel on 23 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://monit.rs/integrations/mcp
- Website: https://monit.rs/
- Changelog RSS feed: https://verifymcp.io/servers/rs-monit-monit-rs/integrations-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/rs-monit-monit-rs/integrations-mcp.json
- HTML version of this page: https://verifymcp.io/servers/rs-monit-monit-rs/integrations-mcp