You're building a tool that extracts structured data from invoices uploaded by accounting clerks. About 5% of the time, the model returns JSON that's missing closing braces or has trailing commas, causing your downstream parser to crash.
What's the most reliable fix?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
When you use tool_use with a JSON schema, the model is constrained to produce output that matches the schema — JSON syntax errors are structurally eliminated. This is the most reliable approach for guaranteed schema-compliant output. Note that this prevents syntax errors but not semantic errors (like a number going in the wrong field) — those need separate validation. But for the specific problem of malformed JSON, tool use is the right answer.
Asking the model to "make sure JSON is valid" relies on probabilistic compliance for a problem that has a deterministic solution. The model is trying to produce valid JSON; it's failing 5% of the time. More instructions won't fix what is fundamentally a constraint problem.
JSON repair libraries are useful as a last-resort safety net, but using them as your primary approach hides the fact that your extraction is producing malformed output. You're treating the symptom and accepting that some fields will be guessed at by a repair library, which can introduce subtle data corruption.
Few-shot examples can reduce error rates, but they don't structurally eliminate them — they're still probabilistic. For format correctness, structural constraint (tool use) beats demonstration (examples) every time.