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

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.

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.

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:

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:

{
  "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:

{
  "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:

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.

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, the DNS lookup and the SPF checker.

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.

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.

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:

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.