Aller au contenu principal

Let AI Assistants Run Your Uptime Checks: the MCP Server

  • API monitoring
  • guide
  • product
  • HostTracker
  • uptime monitoring

By the HostTracker Team - published August 2026

Ask an AI assistant whether your production site is up, and it can actually find out - not by guessing from training data, not from a screenshot you pasted in, but by calling a live check against your own HostTracker account from real checkpoints around the world and reading back the result. That is what a Model Context Protocol (MCP) server does: it turns your monitoring account into a set of tools an assistant can call directly, inside the conversation you are already having. HostTracker runs one, and it is live today at mcp.host-tracker.com.

What is MCP, and why does it matter for monitoring

Model Context Protocol, or MCP, is an open standard (see the specification at modelcontextprotocol.io) that defines how an AI assistant talks to external tools and data. Instead of an assistant answering from what it was trained on, an MCP server exposes a fixed set of callable actions - list monitors, run a check, read an incident - each with a name, a description and a typed set of inputs. The assistant reads that list, decides which action fits the request in front of it, calls it, and gets a structured result back. The same mechanism works whether the assistant is a terminal coding tool, a desktop chat app, or a script you wrote yourself, because the protocol, not the client, defines the contract.

For monitoring specifically, that closes a gap that has existed for as long as alerting has lived in one place and the conversation about it in another - a chat window, a support ticket, an incident channel. An assistant connected over MCP does not need a copy-pasted API response to reason about your uptime. It can ask HostTracker directly, in the middle of whatever you were already doing, and act on what comes back.

What HostTracker's MCP server lets an assistant do

The server exposes 65 tools across the groups below, plus a generic pair that reaches anything the named tools do not cover yet.

GroupToolsWhat it does
Checksrun_instant_check, get_check_result, list_check_typesStart a one-off check, poll a slow one through to its final result, and list the supported check types.
Monitors (12)list_monitors, get_monitor, create_monitor, update_monitor, delete_monitor, pause_monitor, resume_monitor, copy_monitor, bulk_create_monitors, bulk_update_monitors, bulk_delete_monitors, list_monitor_typesFull lifecycle management for continuous monitors, one at a time or in bulk.
Results and incidents (5)get_uptime_summary, list_monitor_results, list_incidents, get_incident, comment_incidentRead historical uptime, pull result history, and work an incident's timeline.
Maintenance (4)list_maintenance, create_maintenance, update_maintenance, delete_maintenanceSchedule and manage maintenance windows so planned downtime does not page anyone.
Contacts (12)list_contacts, get_contact, create_contact, update_contact, delete_contact, send_contact_confirmation, confirm_contact, test_contact, list_contact_groups, create_contact_group, update_contact_group, delete_contact_groupManage who gets notified, confirm delivery channels, and organize contacts into groups.
Subscriptions (3)list_subscriptions, subscribe_contact, unsubscribe_contactWire contacts to the monitors that should notify them.
Webhooks (7)list_webhooks, create_webhook, update_webhook, delete_webhook, test_webhook, list_webhook_deliveries, redeliver_webhookRegister outbound event delivery and inspect or retry past deliveries.
Status pages (7)list_status_pages, get_status_page, create_status_page, update_status_page, delete_status_page, create_status_page_incident, add_status_page_incident_updateManage public status pages and post incident updates to them.
Reports (2)generate_report, list_report_typesGenerate a report and see what report types exist.
Jobs (4)get_job, wait_for_job, cancel_job, resume_jobTrack the asynchronous jobs that bulk operations hand back.
Account, read-only (3)get_account, get_account_quota, get_account_usageRead account identity, quota and usage - never write it.
Locations (1)list_locationsList the available checkpoint locations and pools.
Generic door (2)describe_api, api_requestDiscover and call anything on the API v2 surface that the named tools above do not cover.

list_check_types currently covers 10 check types: Http, Ping, Port, Trace, Dns, DNSBL, Whois, WebRisk, Crawl and Waterfall (pageSpeed is accepted as an alias for Waterfall).

What it will never touch

  • No writes under /account - identity data stays readable but not editable through the server.
  • No payments, packages or plan changes - that surface is not part of the API v2 the server calls at all.
  • No passwords, login or account recovery - also outside API v2.
  • No minting or revoking API tokens - that happens only from your own account profile.
  • Every delete previews first and only runs once you confirm it.
  • Bulk operations validate before they submit, and a bulk delete additionally needs a confirmation plus a matching expected count.

Connecting your assistant

The server speaks MCP over streamable HTTP at one public address, https://mcp.host-tracker.com/mcp. Every call carries your own HostTracker API v2 token as a bearer credential. The server itself holds no account data and enforces nothing on its own - authentication, scopes, quota and ownership are all checked inside the API behind it, on every request.

In Claude Code, add it to your .mcp.json:

{
  "mcpServers": {
    "hosttracker": {
      "type": "http",
      "url": "https://mcp.host-tracker.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_HOSTTRACKER_API_TOKEN"
      }
    }
  }
}

Swap in a token minted from your account, restart the client, and the tools listed above become available in the conversation.

For any other MCP-capable client that does not yet speak streamable HTTP natively, bridge it with mcp-remote instead:

npx mcp-remote https://mcp.host-tracker.com/mcp --header "Authorization: Bearer YOUR_TOKEN"

One honest limitation, worth stating plainly: Claude Desktop's and claude.ai's one-click "Add connector" flow currently accepts only OAuth, with no field for a bearer token, so the HostTracker server does not work through that particular UI yet - that support is on the roadmap. Today it works from Claude Code and from any config-file or command-line MCP client that can send a custom header, which is most MCP-capable assistants outside those two specific one-click connector screens.

A worked example: is my site down

Say a site looks slow or unreachable and you want a second opinion before paging anyone. Ask your assistant, in plain language, to check it, and it calls run_instant_check. That tool starts a check from more than 300 checkpoints across 158 cities, optionally pinned to named pools, waits up to 30 seconds for the results to arrive, and hands back per-location status and timings plus the public result-page URL. If the check is still running when that window closes, the result comes back labelled as partial, and get_check_result polls it through to completion.

What comes back is not a single up or down bit. A site that is unreachable from three checkpoints in one region but fine everywhere else looks very different from one that is down globally, and the assistant can read that difference straight from the per-location breakdown, tell you which regions are affected, and hand you the result-page link to look yourself. For an http check, passing strictTls validates the TLS handshake strictly at the same time: a self-signed certificate, an untrusted root, a wrong host or an expired certificate is caught instead of silently passed, and the detail lands in the result's TLS section - the same strict mode behind the free SSL certificate checker. Left at its default of false, the handshake stays relaxed, which is what an ordinary uptime check wants.

Authentication, rate limits and plan access

Every call to /mcp needs an Authorization header carrying a bearer token - your own API v2 token, the same kind the REST API, the SDKs and the CLI all use, forwarded per request rather than held in a shared default header. The only anonymous endpoint is /stats, and that reports liveness only. There is no separate charge for MCP access: it rides the same API access and quota your account already has for REST, SDK and CLI calls. On top of that account-level quota, the server itself caps traffic on /mcp at 60 requests per minute per client IP, a 256 KiB request body, 500 concurrent connections and 64 concurrent in-flight instant checks.

That account-level API access is the part worth planning around: the Free, Personal and Webmaster plans do not include API, SDK, CLI or MCP access at all. Business and Enterprise plans do, and so does the 30-day free trial, which needs no card to start. If your assistant's tool calls start failing with an authorization error, check which plan the token belongs to before you go looking for a bug in the server.

Why we built an MCP server

Most of what the server exposes already existed as a REST API, so building it did not require new capability - it required a second door onto the same one, shaped for how an assistant calls a tool rather than how a developer writes an HTTP request. That the surface underneath is one well-documented API v2 (145 paths across 14 resource groups, generated from a single OpenAPI document, public at api2.host-tracker.com/openapi/v2.json) is also why the server can offer a generic api_request tool alongside the named ones: describe_api exposes that same machine-readable surface for an assistant to query directly, rather than needing a new tool hand-written for every operation. As more day-to-day infrastructure work runs through an assistant instead of a dashboard, a directly-callable, machine-readable surface is what lets it actually act on your monitoring rather than just summarize a screenshot someone handed it.

Where to go next

The MCP client-setup page walks through minting a token and pointing your assistant at it once you are signed in, and the public MCP server overview covers the same ground for anyone evaluating it before they sign up. If you would rather call the API directly, or from a typed client, or from a shell, this wave's sibling articles cover those paths against the exact same account, quota and monitors: a practical tour of the API v2 surface, the official CLI walkthrough, and the SDK overview for Python, JavaScript, Go and .NET.

To get a token to try any of this, start the 30-day trial, no card required, or see the Business and Enterprise plans for production access once you are past the trial.