HostTracker MCP server

Connect an AI assistant to HostTracker over the
Model Context Protocol and let it operate your monitoring account in
conversation: run a live check from 300+ global locations, see what is down, create or pause a monitor, schedule a
maintenance window, review incidents, manage who gets alerted, wire a webhook, publish a status page update.
Endpoint https://mcp.host-tracker.com/mcp
Transport streamable HTTP
Auth OAuth 2.1 (sign in when your client asks) - or Authorization: Bearer <HostTracker API token>
This repository is the public face of that hosted server: the connection metadata
(server.json), the per-client setup guide (CLIENT.md), and the security policy
(SECURITY.md) - and, since 2.0.0, the server's own source code in src/, so you can read
exactly what runs behind the endpoint or run a copy yourself (see "Run it yourself" below).
Connect in two minutes
With OAuth (recommended - Claude.ai, Claude Desktop, Claude Code, ChatGPT and any client with an OAuth-capable
connector dialog):
- Add the endpoint
https://mcp.host-tracker.com/mcp as a connector in your client.
- Sign in and approve. The client opens HostTracker's sign-in page, then a consent card listing the
permissions it asks for (by default: run checks + read monitors). Press Approve. No token ever appears.
- Ask in plain language: "is example.com up right now,
checked from Europe and Asia?", "which of my monitors are down?", "pause the staging monitor until
tomorrow".
Claude Code
With OAuth (no token needed):
claude mcp add --transport http hosttracker https://mcp.host-tracker.com/mcp
# then, inside Claude Code: /mcp -> hosttracker -> Authenticate (opens the sign-in + consent page)
Or with a bearer token in the header:
.mcp.json in your project (or ~/.claude.json for a user-wide connector):
{
"mcpServers": {
"hosttracker": {
"type": "http",
"url": "https://mcp.host-tracker.com/mcp",
"headers": { "Authorization": "Bearer YOUR_HOSTTRACKER_API_TOKEN" }
}
}
}
Or from the command line:
claude mcp add --transport http hosttracker https://mcp.host-tracker.com/mcp \
--header "Authorization: Bearer YOUR_HOSTTRACKER_API_TOKEN"
Claude.ai and Claude Desktop
Settings -> Connectors -> Add custom connector -> paste https://mcp.host-tracker.com/mcp -> Connect. The
browser opens HostTracker's sign-in + consent page; press Approve and the connector is live. That is the whole
setup.
To use a bearer token instead (for example a long-lived token with a hand-picked scope set), Desktop can also
connect through the mcp-remote bridge. Edit claude_desktop_config.json:
{
"mcpServers": {
"hosttracker": {
"command": "npx",
"args": [
"-y", "mcp-remote", "https://mcp.host-tracker.com/mcp",
"--header", "Authorization:${HT_AUTH}"
],
"env": { "HT_AUTH": "Bearer YOUR_HOSTTRACKER_API_TOKEN" }
}
}
}
The ${HT_AUTH} indirection is deliberate: some mcp-remote builds split an argument on its first space, which
breaks a literal Authorization: Bearer .... Node.js 18 or newer is required.
Cursor
~/.cursor/mcp.json for every project, or .cursor/mcp.json for one:
{
"mcpServers": {
"hosttracker": {
"url": "https://mcp.host-tracker.com/mcp",
"headers": { "Authorization": "Bearer YOUR_HOSTTRACKER_API_TOKEN" }
}
}
}
VS Code (GitHub Copilot agent mode)
.vscode/mcp.json in the workspace. The inputs block keeps the token out of the file, prompting for it once and
storing it in the editor's secret storage:
{
"inputs": [
{
"type": "promptString",
"id": "ht-token",
"description": "HostTracker API token",
"password": true
}
],
"servers": {
"hosttracker": {
"type": "http",
"url": "https://mcp.host-tracker.com/mcp",
"headers": { "Authorization": "Bearer ${input:ht-token}" }
}
}
}
Windsurf
~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"hosttracker": {
"serverUrl": "https://mcp.host-tracker.com/mcp",
"headers": { "Authorization": "Bearer YOUR_HOSTTRACKER_API_TOKEN" }
}
}
}
Run it yourself (Docker)
The hosted endpoint is the normal way to use the server. If you would rather run your own copy - to read the
code, audit it, or keep the MCP hop inside your network - the repository builds it from source:
docker build -t hosttracker-mcp https://github.com/HostTracker/mcp.git
docker run --rm -p 8080:8080 hosttracker-mcp
Your copy then answers at http://localhost:8080/mcp and takes exactly the same Authorization: Bearer header:
it is a stateless bridge, so it stores nothing and still talks to the public HostTracker API v2 under your token.
Without Docker, dotnet run --project src does the same on any machine with the .NET 10 SDK.
The same binary also speaks stdio, for clients that launch the server as a child process instead of
connecting to a URL. Add --stdio and pass your token as the HT_TOKEN environment variable (there is no request
header on stdio):
HT_TOKEN=YOUR_HOSTTRACKER_API_TOKEN dotnet run --project src -- --stdio
docker run -i --rm -e HT_TOKEN=YOUR_HOSTTRACKER_API_TOKEN hosttracker-mcp --stdio
Logs go to stderr in that mode, so stdout stays a clean protocol stream.
ChatGPT and other clients
ChatGPT (developer mode -> connectors): add https://mcp.host-tracker.com/mcp; ChatGPT offers its "link
account" step, which opens HostTracker's sign-in + consent page. Any other client with an OAuth-capable connector
dialog works the same way - just the URL.
Any client that can send a static header also works with a bearer token: the endpoint
https://mcp.host-tracker.com/mcp and the header Authorization: Bearer YOUR_HOSTTRACKER_API_TOKEN. Where a
client's connector form offers an API-key or custom-header authentication mode, the token goes there.
A generic, dependency-free bridge for anything that can only launch a command:
npx -y mcp-remote https://mcp.host-tracker.com/mcp --header "Authorization:${HT_AUTH}"
Longer walkthroughs, verification commands and troubleshooting live in CLIENT.md.
What the assistant can do
The server exposes the HostTracker v2 REST API as MCP tools. Every list tool takes limit (maximum 50) and
cursor and returns the next cursor; every timestamp is Unix seconds in both directions; ids are opaque strings.
| Family | What it covers |
|---|
| Checks | Run an instant check on any URL from 300+ locations (HTTP/S, ping, TCP port, traceroute, DNS, blacklist, WHOIS, Web Risk, crawl, page speed), fetch its result, list the available check types and devices. |
| Monitors | List, read, create, edit, copy, pause, resume and delete monitors, in single or bulk form, plus the catalogue of monitor types. |
| Results and incidents | Uptime summaries, raw check results, the incident list, one incident in detail, and comments on an incident. |
| Maintenance | List, create, edit and delete maintenance windows so planned work does not raise alerts. |
| Contacts | Manage contacts and contact groups, send and confirm a contact confirmation, and send a test alert to one. |
| Subscriptions | See who is notified for which monitor, and subscribe or unsubscribe a contact. |
| Webhooks | Manage webhook endpoints, send a test delivery, review the delivery log and redeliver a failed one. |
| Status pages | Manage public status pages, publish an incident on one and post follow-up updates. |
| Reports | Generate a report and list the report types available on your plan. |
| Jobs | Poll, wait on, cancel or resume the asynchronous jobs that bulk operations and reports return. |
| Account | Read-only: the account profile, its quota and its current usage. Useful for diagnosing a refused call. |
| Locations | List the checkpoint pools and individual monitoring locations you can target. |
| Generic door | describe_api searches the real v2 operations and api_request calls one, for anything without a dedicated tool. It is not a URL proxy: the operation must exist in the published API description, and the safety policy below still applies. |
The full tool list