# Connect an MCP Server to Claude: 20 Network Checks, No Account

> One line of configuration, and your AI assistant checks DNS, SSL, SPF and reachability for any domain right in the chat.

Source: https://uptimeify.io/blog/connect-mcp-server-claude

**Update, September 8, 2026:** Uptimeify's MCP server has since grown a set of write tools on top of everything below, pausing a monitor, acknowledging an incident and similar. Each one sits behind its own consent scope you grant separately from read access, area by area, and unchecked until you check it yourself, so the 33 tools this guide describes stay exactly as read-only as written below. Current tool list and scopes are on the [MCP server page](/mcp-server).

You paste in one line of configuration, and your AI assistant can check DNS, SSL, SPF, DMARC, HTTP headers and the reachability of any domain. No account, no token, no install. The Uptimeify MCP server exposes 20 read-only check tools anonymously, and 13 more read your own monitors, alerts, status pages and account once you add an API token. This guide covers the configuration, the tool list, five prompts to start with and the rate limits.

- Endpoint: `POST https://uptimeify.io/mcp`, Streamable HTTP, stateless.
- 20 check tools run without an account or token, 13 more read your own monitors, alerts, status pages and account via API token or OAuth.
- In Claude you add the URL as a remote MCP server; other clients use a JSON block or `mcp-remote`.
- Limits: 120 requests per minute per IP on the endpoint, 15 to 30 per anonymous tool, 60 per authenticated tool. Above that you get HTTP 429 with `retryAfter`.
- All 33 tools this guide describes are read-only. A separate set of write tools now exists, off unless you grant its consent scope yourself.

## What you end up with

At the end you type "Check SSL, DNS and SPF for the domain you look after" into your chat window and get three real network probes back: certificate issuer and remaining validity, the resolved records, the evaluated SPF entry. No copy and paste across three web tools, no tab switching, no clipboard.

To do that, the assistant calls individual tools on the server instead of guessing. That is the difference between an answer from model memory and an answer from a tool call against the live domain: the second one is verifiable and current.

## What an MCP server means here

An MCP server is a service that hands an AI assistant tools it can call on its own. The Model Context Protocol standardises how those tools are described, invoked and answered. The assistant stays the assistant; the server supplies the facts.

In this case: Uptimeify publishes its public check tools over that protocol so your assistant can use them directly. More on the transport layer in the glossary entry on Streamable HTTP.

## The endpoint

`POST https://uptimeify.io/mcp`, transport is Streamable HTTP, the server is stateless. No session, no handshake spread across several requests, every call stands on its own.

Two discovery files are there for clients and registries that want to find the server automatically:

| File | Purpose |
| --- | --- |
| `/.well-known/mcp/server-card.json` | Server card with capabilities and tool metadata |
| `/.well-known/mcp/server.json` | Registry manifest for MCP directories |

Every tool declares an `outputSchema` and returns `structuredContent` next to the text block on success. Two properties of those schemas are deliberate: no field is marked required, and extra properties are allowed. An endpoint that omits a value therefore does not turn a check into a failed tool call, and a field added later rides along instead of failing validation in a strict client.

The tool names follow a deliberate rule too: letters, digits and underscores only. The major function-calling APIs validate tool names against a pattern that excludes dots. A name like `dns.check` would be rejected by any client that passes the tools through to a model.

## Connecting Claude: the actual configuration

The fastest route in Claude Desktop and claude.ai: add `https://uptimeify.io/mcp` as a remote MCP server. For the 20 anonymous tools that is all you need. If you also want to read your own monitors, choose **Connect**: Claude registers itself through Dynamic Client Registration and opens the consent screen where you sign in to Uptimeify and approve read access.

Clients that support remote servers with custom headers can be configured directly:

```json
{
  "mcpServers": {
    "uptimeify": {
      "url": "https://uptimeify.io/mcp",
      "headers": { "Authorization": "Bearer wsm_your_token_here" }
    }
  }
}
```

Drop the `headers` block entirely if the anonymous check tools are enough for you.

Clients that only speak stdio bridge to the HTTP endpoint with `mcp-remote`:

```json
{
  "mcpServers": {
    "uptimeify": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://uptimeify.io/mcp"]
    }
  }
}
```

To confirm the connection without a client at all, one call is enough:

```bash
curl -X POST https://uptimeify.io/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
```

The response lists every available tool with its schema. That is also the most reliable source if you want to know what the server can do today.

## The 20 tools that need no account

All 20 are read-only and run real probes against the domain you ask about. They mirror the public web tools, only callable from the chat.

| Group | Tools | Arguments |
| --- | --- | --- |
| DNS and domain | `check_dns`, `dns_propagation`, `whois`, `domain_expiry` | `domain` |
| Mail | `mx_lookup`, `spf_check`, `dmarc_check`, `dkim_check`, `dnsbl_check` | `domain`, plus `selector` for `dkim_check` and an `ip` for `dnsbl_check` |
| TLS | `check_ssl`, `hsts_check` | `host` and optional `port`, or `domain` |
| HTTP | `http_headers`, `redirect_check`, `website_status`, `response_time` | `url` |
| Network | `port_check`, `ping_test`, `ip_geolocation`, `asn_lookup`, `reverse_dns` | `host` and `port`, `query` or `ip` |

If you would rather run the same checks in a browser, or send a client a link: they exist as web tools too, among them the [SSL certificate checker](/tools/ssl-certificate-checker), the [DNS lookup](/tools/dns-lookup) and the [SPF checker](/tools/spf-checker).

The full overview with every tool, its arguments and the supported clients lives on the MCP server page.

## Five prompts that work right away

Describe the task, not the tool name. The assistant picks what to call.

1. "Check SSL, DNS and SPF for this client domain and tell me what stands out."
2. "Does the certificate for this domain expire in the next 30 days? Who issued it?"
3. "We just changed the A record. Has the change propagated everywhere yet?"
4. "Why is mail from this domain landing in spam? Look at SPF, DKIM with selector `default`, and DMARC."
5. "Follow every redirect from the http version of this domain to its destination and show me the security headers of the final page."

The fifth one is what agencies reach for most: a post-launch migration check, in one sentence instead of four tabs.

A prompt against a live domain beats any answer from model memory, because you can verify it.

## With an API token: the 13 extra tools

Thirteen further tools read your own monitoring and account data. For those you need either an API token in an `Authorization: Bearer` header or the OAuth connection from Claude:

- `list_monitors` lists your website monitors, no arguments.
- `monitor_status` returns the current up or down state for a `monitor_id`.
- `list_incidents` shows recent incidents, optionally with `limit`.
- `check_history` returns recent checks for a `monitor_id`, optionally bounded by `from` and `to`.
- `uptime_summary` sums up availability and average response time for day, month and year.
- `list_alert_channels` lists the notification channels that can raise an alert for you, optionally narrowed to one monitor with `website_id`.
- `alert_history` shows which alerts went out for a `monitor_id`, over which channel and whether delivery succeeded or failed.
- `list_status_pages` lists your status pages with slug, visibility and custom domain, no arguments.
- `list_maintenance_windows` lists your scheduled maintenance windows, optionally only the active ones.
- `get_organization` returns your own organization with its name, public id and account status, no arguments.
- `list_users` lists the members of your organization with role and join date, no arguments. It carries no member identifier at all, so a member can be named but not referenced.
- `list_customers` lists your customers with name, status and monitor counts, no arguments.
- `billing_summary` returns the SMS usage of the running month, per customer and in total, no arguments.

The last four hand out a fixed list of fields and nothing else: no contact e-mail, no address, no VAT id, no phone number, no custom fields, no tariff name, no billing e-mail and no payment method. Over OAuth they also sit in their own consent area, so a connection can take the monitoring tools and leave the account ones out.

The token decides the scope: a customer-scoped token sees only that one customer's monitors, an organization token sees every customer in the organization. Create one under **Settings, API tokens**; it is displayed exactly once.

Take the OAuth route instead and the same boundary applies automatically: the connection inherits your account's visibility and is explicitly limited to reading. Access tokens expire after an hour and refresh in the background, the grant itself after seven days of inactivity. You can revoke it any time under **Settings, Connected apps**, and revoking takes effect immediately.

Every argument, response schema and error case is documented in the technical reference.

## Rate limits and what HTTP 429 means

The anonymous tools run real network probes on your behalf, so they are capped per client IP. Two layers apply at the same time:

| Scope | Limit |
| --- | --- |
| `POST /mcp` overall | 120 requests per minute per IP |
| Each anonymous check tool | 15 to 30 calls per minute per IP, depending on how expensive the probe is |
| Each authenticated tool | 60 calls per minute per IP |

120 calls a minute spread across different tools is fine. 120 calls a minute of `whois` is not: `whois` and `domain_expiry` sit at the strict end with 15.

Exceed a limit and the server answers with HTTP 429 and a `retryAfter` value in seconds. The windows are fixed, not sliding, so a client that waits out `retryAfter` starts again with a full allowance. And the limits are tied to the IP, not the token. An API token does not raise the ceiling, and several agents behind one NAT address share a single allowance. If your use case genuinely needs more, talk to us rather than working around it.