Bring HostTracker into your AI workflow.

1. Mint a token. On Integrations - API, create a token and tick the scopes the assistant should use - check for instant checks, monitor:read/monitor:write to see or change monitors, and so on. There is no reason to grant account:write: the server refuses every account write regardless.
2. Paste the config. Add an http-transport MCP server entry pointing at https://mcp.host-tracker.com/mcp with an Authorization: Bearer header carrying the token, in whichever client you use:

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

   For a client that can only launch a local command, use the mcp-remote shim instead:

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

3. Ask. Restart the client so it discovers the tools, then just describe what you want: "which of my monitors are down", "run an http check on example.com from Europe and Asia", "pause staging for an hour". The assistant picks the tool.

If your assistant is not in the list, it likely still works: any MCP client that supports the http transport with custom headers can point at https://mcp.host-tracker.com/mcp directly, and mcp-remote bridges anything that only launches a local stdio process. The server itself does not care which client is asking - it is the client's config format that differs, not the protocol.

Where it is listed. The server is published in the official MCP Registry as io.github.HostTracker/hosttracker, on Smithery (whose gateway lets you paste the token once instead of editing config files) and on Glama; the connection metadata, per-client guide and security policy live in the public HostTracker/mcp repository.

• Scoped tokens. A token carries only the scopes you tick - monitor, contact, webhook, check, status page, report, incident, maintenance, job, account - each as read or write. Grant what the integration needs and nothing else.
• Long-lived, not revocable. Tokens are JWTs with a lifetime you choose (10 years by default) and cannot be revoked before they expire; an account-wide API switch disables every token at once. Treat a token like a password: keep it out of source control, and add an IP allow-list and a per-token request cap when you mint it.
• Limits you can read. Every response carries RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset and RateLimit-Policy; a 429 carries Retry-After. Current usage is on the Integrations - API page and at GET /account/quota.
• Safe retries. Writes accept an Idempotency-Key, so a retried request is never a duplicate; long operations return a job you can poll or have delivered to a webhook.
• Guard rails. The server refuses account-profile writes (POST/PUT/PATCH/DELETE on /account) - reading the account, its quota and usage is allowed; every other tool does exactly what the token's scopes allow, so a read-only token gives a read-only assistant.

Full details: authentication and limits in the docs. Plans and prices: pricing.