toolhq.io

All posts
7 min readby Jameel Haider

How toolhq helps you work with AI

toolhq is not an AI product. It does not run a model on what you type, and it has no chat window that answers questions. What it has is a set of small, exact tools, and AI work leans on exactly the things a language model is bad at: facts about the live internet, precise computation, and anything you would rather not paste into a chat.

This is a map of where those tools help, grouped by what you are trying to do.

1. Give your agent real lookups

A model cannot look up a DNS record. Ask it about your domain's mail setup and it will describe a plausible configuration, written confidently, that it has never seen. The fix is not a smarter model, it is a tool the model can call.

toolhq runs an MCP server that exposes eight read only network checks to any compatible assistant: dns_lookup, dns_propagation, mx_lookup, reverse_dns, ip_lookup, ip_reputation, ssl_check and http_headers. Each one runs the same code as the matching tool on the site. There is no key and no account, and it is one command in Claude Code:

claude mcp add --transport http toolhq https://toolhq.io/api/mcp

The checks are limited to 60 per minute per address, private and local address ranges are refused, and the value your agent sends, a domain or a host or a URL, is used to make the lookup and is not stored. The endpoint is in beta, so new checks may be added and responses may gain fields.

For the reasoning behind this, read what MCP is and why an agent needs real network tools. For a worked example with real output, see debugging DNS, SSL and mail with an AI agent.

2. Check the model's work with tools that are exact

Models are good at drafting and explaining. They are unreliable at tasks that have one right answer and no tolerance for approximation: a hash, a count, a timezone conversion, whether a string is valid JSON. They will often produce something of the right shape that is simply wrong.

The practical habit is to let the model do the part it is good at, then verify with a tool that cannot be wrong in that way:

  • Have the model draft a regex, then test it against real samples in the regex tester.
  • Have it write a cron expression, then read the next run times in the cron generator.
  • Have it explain a token, but decode the token yourself first in the JWT decoder.
  • Have it convert a timestamp or a color, then check it in the timestamp converter or the color converter.

Where an exact tool beats an AI model goes through this in more detail.

3. Keep sensitive input out of the chat

Debugging often means pasting something you should not: a JWT, a log with a customer email in it, a certificate, a private key you are trying to match. A chat window is a poor place for those.

Most toolhq tools process your input in the browser. Decoding a certificate, matching a key to a certificate, converting certificate formats, formatting JSON and decoding a JWT all happen on your machine. The tools that need the network, such as DNS or SSL checks, carry a badge saying so and state exactly what they send. The privacy page lists which is which, and how to verify nothing leaves your browser shows how to check for yourself rather than taking anyone's word for it.

A local tool is not a substitute for redaction. Sharing logs and API keys safely covers what to strip before anything leaves your hands, whatever you paste it into.

4. Test what you are building for AI

If you are building something an agent will use, a few tools earn their place.

The MCP Endpoint Inspector connects to an MCP server the way a client does, lists its tools, and tells you what an agent would run into: missing descriptions, duplicate names, schemas that are not objects, a URL that redirects a POST, a server that returns a web page instead of a JSON-RPC reply. Testing an MCP server before agents use it explains what it checks and why descriptions matter more than they look.

If your product receives callbacks, the webhook inspector gives you a URL that captures every request so you can see exactly what arrived. The JSON formatter and JSON to TypeScript turn the payloads you capture into something readable and typed.

5. See how AI systems treat your site

The other direction matters too: which AI crawlers are allowed to read your site, and which have you blocked without meaning to. The AI Crawler Access Checker reads your robots.txt and reports what GPTBot, ClaudeBot, PerplexityBot and a dozen others are permitted to do, separating the ones that collect training data from the ones that fetch pages to answer a user. Which AI crawlers can read your site explains how to read the result and what to change.

What toolhq does not do

Being plain about the edges is part of being useful.

  • It does not use a model on your input. The home page input recognises what you paste, such as JSON, a domain, a certificate or a timestamp, with simple pattern matching and no network call, then points you at the tool that fits.
  • The MCP server exposes eight network lookups, not everything on the site. The browser tools that parse and format data are left out on purpose, because an agent can already do that work locally.
  • A tool that runs in your browser still lives on a website. Check the page for what it says it sends, and do not paste secrets anywhere you have not decided to trust.

Where to start

Pick by situation. If your agent keeps guessing about live infrastructure, connect the MCP server. If you are about to trust something a model produced, check it with the matching tool. If you are shipping an MCP server, run it through the inspector. If you want to know how AI crawlers see your site, run the crawler checker on your domain.