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.
| Group | Tools | What it does |
|---|---|---|
| Checks | run_instant_check, get_check_result,
list_check_types | Start 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_types | Full 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_incident | Read historical uptime, pull result history, and work an incident's timeline. |
| Maintenance (4) | list_maintenance, create_maintenance,
update_maintenance, delete_maintenance | Schedule 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_group | Manage who gets notified, confirm delivery channels, and organize contacts into groups. |
| Subscriptions (3) | list_subscriptions, subscribe_contact,
unsubscribe_contact | Wire contacts to the monitors that should notify them. |
| Webhooks (7) | list_webhooks, create_webhook,
update_webhook, delete_webhook, test_webhook,
list_webhook_deliveries, redeliver_webhook | Register 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_update | Manage public status pages and post incident updates to them. |
| Reports (2) | generate_report, list_report_types | Generate a report and see what report types exist. |
| Jobs (4) | get_job, wait_for_job, cancel_job,
resume_job | Track the asynchronous jobs that bulk operations hand back. |
| Account, read-only (3) | get_account, get_account_quota,
get_account_usage | Read account identity, quota and usage - never write it. |
| Locations (1) | list_locations | List the available checkpoint locations and pools. |
| Generic door (2) | describe_api, api_request | Discover 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.