TooltowerBot

TooltowerBot checks that remote MCP servers answer, and how. It runs for two reasons only:

• Monitoring that someone asked for. A server's owner monitors their own server, or a team monitors a third-party MCP server their agents depend on.
• Occasional research snapshots. At most once a week we check up to 800 public MCP servers listed in the Official MCP Registry, in a single pass, to publish aggregate statistics about the ecosystem (for example, how many servers support each protocol version). Research reports publish totals, never a verdict about a named server.

We do not run public status pages about servers whose owners have not turned them on.

This page says what the bot sends, how often, and how to make it stop.

How to recognise it

• User-Agent: TooltowerBot/1.0 (+https://tooltower.dev/bot) — this token will not change.
• In MCP requests: clientInfo.name = "tooltower-prober".
• Source addresses: /bot/ips.json. Reverse DNS points to the bot's name where our hosting allows it.
• Abuse contact: abuse@tooltower.dev. We answer within 24 hours.

What it sends

• Liveness: one server/discover POST (MCP 2026-07-28). Servers on earlier protocol versions answer it with a normal JSON-RPC error, which is enough to know the server is up.
• Protocol detection: once a day, after an outage, and when an endpoint is added: the same POST, then a legacy initialize and, if neither is understood, a GET that waits up to 5 seconds for an HTTP+SSE endpoint event. Any session we open is closed with DELETE straight away.
• Inventory (monitored servers only): at most once an hour, the list methods only — tools/list, prompts/list, resources/list, resources/templates/list — at most 50 pages and 5 MB per run.
• Discovery documents: /robots.txt, /.well-known/tooltower.json, and the OAuth discovery documents that the MCP specification tells clients to read (/.well-known/oauth-protected-resource, authorization server metadata).

A research snapshot sends only the liveness request, the protocol detection and the discovery documents — no inventory.

What it never sends

To any server whose owner has not verified it with us: tools/call, resources/read, prompts/get, subscriptions/listen, dynamic client registration, deliberately malformed requests, or an Origin header. It never sends credentials to a server that has not given them to us, and never follows links found in tool descriptions.

Rate and load

• One request at a time per host, at most 12 requests per minute per host across all its endpoints.
• A server that a customer monitors without being its owner: at most every 5 minutes. Research snapshots: at most once a week.
• 429 and 503 with Retry-After are honoured, with exponential backoff up to 24 hours.
• Repeated 403 responses to our User-Agent pause probing of that host for 24 hours.
• Every probe opens a fresh connection; we do not hold connections open.

Opting out

Any one of these stops probing immediately — no confirmation needed:

• robots.txt: a Disallow covering your MCP path, for TooltowerBot or for *. An unreachable robots.txt (5xx) is treated as a disallow.
• DNS: a TXT record on the MCP host: tooltower-optout=1.
• Well-known file: https://<your host>/.well-known/tooltower.json containing {"optout": true}, or {"optout": "stop_contact"} to also never be contacted about this host.
• Email: abuse@tooltower.dev.

We re-read these signals at least daily and handle email requests within 1 business day.

Owners

If you run the server, you can claim it (well-known token or DNS TXT on the exact host) to see private details, raise or lower our rate, mark incidents ("planned maintenance", "false positive"), turn on a public status page and badge, or turn probing off. How we decide what "down" means is described in the methodology.