Where an exact tool beats an AI model, and how to use both

Language models are good at a particular kind of task: producing fluent text, explaining a concept, drafting code, suggesting where to look. They are unreliable at a different kind, where there is exactly one right answer and no room for approximately right. The danger is not that they fail at these tasks. It is that they fail in the same confident voice they use when they are correct.

This is a guide to telling the two kinds of task apart, and to a working pattern that uses both: let the model draft, and let a tool verify.

Tasks with one right answer

A rough test is whether two competent people given the same input must produce the same output. If yes, a deterministic tool exists for it, and you should prefer the tool.

Hashes and checksums. A SHA-256 digest is the result of a computation over every byte of the input. A model does not run that computation. It predicts text that looks like a digest, and the output will be the right length and character set while being wrong. Use the hash generator, and see why you cannot reverse a hash for what a hash does and does not tell you.

Encodings. Short Base64 strings are sometimes decoded correctly. Long ones, or ones containing unusual bytes, are where errors creep in. The Base64 tool handles UTF-8 correctly and tells you when input is not valid.

Counting and measuring. Characters, words, lines and bytes are not the same number, and models are known to miscount. The text statistics tool is exact, which matters when a field has a hard limit.

Time. Converting a Unix timestamp, handling a timezone offset, or working out whether a date falls inside daylight saving time all have precise answers. Models get them wrong often enough to be a hazard. The timestamp converter is the reference, and handling timezones in code explains where the traps are.

Numbers and colors. Converting between binary, hex and decimal, or between color models, is arithmetic. The base converter and color converter do it exactly.

Validity. Whether a string is valid JSON is a yes or no question with a line number attached when it fails. The JSON formatter parses it with a real parser. A model reading a long document may tell you it looks fine when a trailing comma sits on line 412. See trailing commas in JSON.

Randomness. A model asked for a UUID or a password produces something that looks random and may repeat patterns it has seen. Use the UUID and token generator, which draws from a secure random source.

Tasks where the facts are live

A second category is not about computation but about the current state of the world. A model's knowledge stops at its training date and covers a live host, if at all, only as a snapshot from before then. What a domain's MX records are, whether a certificate expires next week, whether a DNS change has propagated: none of these can be answered from memory.

For these the answer is a lookup. toolhq's MCP server lets an agent run the lookup itself, and the same checks are available by hand in DNS Lookup, the SSL checker and the MX lookup. A worked example is in debugging DNS, SSL and mail with an AI agent.

Where the model is genuinely better

None of this is an argument against models. They are better than any tool at:

• explaining what an error means and why it happens
• drafting a first version of a regex, a query, a config or a script
• suggesting the next thing to check when you are stuck
• translating between a description of what you want and a form a tool accepts

The mistake is using them for the final answer on the first list.

The pattern: draft with the model, verify with a tool

The workflow that works is to treat the model's output as a proposal.

Regular expressions. Ask the model for a pattern, then paste it into the regex tester with real samples, including ones that should not match. Models write patterns that look right and fail on an edge case. The tester shows exactly what matches and what each group captured, and regex flags explained covers the behaviour that most often surprises people.

Cron expressions. Ask for a schedule in plain English, then paste the result into the cron generator and read the next run times. If they are not what you meant, you find out before the job runs at the wrong hour. See common cron mistakes.

Tokens. Ask the model to explain a JWT, but decode it yourself first in the JWT decoder, which runs in your browser. You see the real claims and the real expiry, and the token never goes into a chat. JWT claims explained helps you read them.

Diffs. When a model rewrites a file, compare the result with the original in the diff checker instead of trusting the summary of what changed. A quiet change in an unrelated line is exactly what a summary omits.

Config conversions. If a model converts YAML to JSON or the reverse, run the output through the YAML and JSON converter and check the result parses. YAML gotchas: the Norway problem is a good example of a conversion that looks correct and is not.

A short rule

Before you trust something a model produced, ask whether it has exactly one right answer, or whether it is a fact about the live world. If either is true, check it with a tool. If neither is true, the model is probably the right instrument.

The same thinking runs through the rest of the site, and how toolhq helps you work with AI lays out where each tool fits.