How Do You Guarantee Valid JSON? Forcing Structured Output

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 34)

▶ Watch on YouTube & subscribe to The Stack Underflow

Somewhere in most production LLM pipelines there is a try/except block wrapped around JSON.parse(), and next to it a comment that says something like “this shouldn’t happen, but just in case.” That comment is a confession. If your approach to structured output is a nicely worded instruction plus a fallback parser, you already know it can fail — you just haven’t built the contract that makes it not fail.

The one-sentence version: A prompt asking for JSON is a request the model can ignore; a forced tool call with an input_schema is a contract the API enforces.

The question

You need Claude to ALWAYS return JSON matching a fixed schema. What’s the most reliable approach?

• A) Ask “return only JSON” in the prompt
• B) Force it with tool_choice + a tool whose input_schema is your shape
• C) Raise temperature
• D) Parse and repair the text afterward

Pause here and pick an answer before you keep scrolling.

The answer

B — force it with tool_choice plus a tool whose input_schema matches the shape you need.

The mechanism is simple, and it’s the same mechanism the whole tool-use system is built on. You define a tool — not one that does anything in the real world, just a schema-shaped container — and then you tell the API it must call that tool, every time, with tool_choice set to force that specific tool rather than leaving the decision to the model. The model’s output is no longer “text that looks like JSON.” It’s a structured tool call whose arguments are validated against your input_schema before you ever see them.

LANE A — the prompt-only approach (a request)
┌────────────────────────────────────────────┐
│ System prompt: "Return only JSON. No prose." │
└────────────────────────┬───────────────────┘
                          │
                          ▼
                  Claude generates TEXT
                          │
              ┌───────────┴───────────┐
              ▼                       ▼
        looks like JSON        "Sure! Here's the JSON:
        (usually)               ```json ... ```"
              │                       │
              ▼                       ▼
        JSON.parse() OK        JSON.parse() THROWS
        (most of the time)     (sometimes — no guarantee)

LANE B — forced tool_choice (a contract)
┌──────────────────────────────────────────────────┐
│ tool_choice: { "type": "tool", "name": "emit_result" } │
│ tool: { input_schema: { type:"object",             │
│           properties: { amount:{type:"number"} },  │
│           required:["amount"] } }                  │
└────────────────────────┬─────────────────────────┘
                          │
                          ▼
              Claude MUST call emit_result
              with arguments matching the schema
                          │
                          ▼
              structured, schema-shaped result
              — every single call

The key difference: in Lane A, “JSON” is a style the model is trying to imitate because you asked nicely. Style is probabilistic — most of the time it’s fine, and then a long response, a markdown code fence, an apologetic preamble, or a stray trailing comma breaks your parser at 2 a.m. In Lane B, the tool-calling machinery itself is the enforcement point. The API is constraining generation toward a schema-valid tool call, not just hoping the model imitates one. That’s the difference between a request and a contract.

Why the other options fail

• A) “Ask ‘return only JSON’ in the prompt.” This works often enough to pass a demo and fails often enough to break production. Nothing stops the model from adding a preamble, wrapping the output in a markdown fence, or drifting on an edge-case input. It’s a style instruction, not an enforcement mechanism — there’s no validation layer between “the model tried” and “your code trusts it.”
• C) “Raise temperature.” This is backwards. Temperature controls how much randomness goes into token sampling — raising it makes output more varied and less predictable, which is the opposite of what a fixed schema needs. If anything, you’d want deterministic settings for extraction tasks, and even at temperature zero, a prompt-only approach still isn’t schema-enforced.
• D) “Parse and repair the text afterward.” Post-hoc repair (regex patches, “fix the trailing comma,” brace-balancing) is a patch on a fundamentally unreliable process, not a fix for it. Every repair rule is another thing that can silently produce wrong-but-parseable output — a repaired string can be syntactically valid JSON that’s semantically garbage. It also means you’ve built a second, undocumented parser that has to evolve every time the model’s failure mode changes.

The concept behind it

This question is really about where you place the guarantee. You can either try to get better at asking for the right shape, or you can move the shape into a place the API enforces mechanically. Forced tool use is the second path, and it works because tool_choice isn’t one setting — it’s four distinct modes, each trading off model autonomy against guaranteed structure:

For a “guarantee JSON matching a fixed schema” requirement, tool is the only mode with an actual guarantee attached. The pattern generalizes past this one question: any time an exam scenario (or a real production requirement) says “always,” “guaranteed,” “every time,” or “matching a fixed shape,” the answer is going to route through schema enforcement, not prompt phrasing. That habit of pattern-matching the requirement word to the mechanism is worth more than memorizing this specific answer — see tool_choice Explained for the full breakdown of when to force versus when to let the model decide.

It’s also worth being honest about what forced tool_choice does not guarantee. It guarantees the output is structurally valid against your schema — right types, right keys, right shape. It does not guarantee the values are correct. A forced tool can still return "amount": 42 when the real number in the document was 420 — that’s a validation and grounding problem, not a schema problem, and it’s why forcing the schema is step one of a larger pipeline that usually includes type validation (see A Number Comes Back as a String) and a bounded retry loop that feeds validation errors back to the model (see Bounded Retries for LLM Output).

FAQ

Does forcing tool_choice slow down or degrade Claude’s reasoning? Not inherently, but it does remove the option to think in prose before answering. If the task needs reasoning first, the better pattern is to let the model think in a scratchpad step and then force a tool call for the final structured answer — reasoning and structure aren’t mutually exclusive, they’re sequenced. That handoff pattern is its own exam topic; see Keep the Reasoning, Hide It From Output.

Is forced tool_choice the same thing as JSON mode in other APIs? Conceptually similar — both aim for guaranteed schema-shaped output — but the mechanism differs. Forced tool_choice works through Claude’s tool-use system: you define an input_schema and force the call, and the arguments the model produces for that call are your structured result. Always check current parameter names and schema syntax against Anthropic’s official docs before shipping, since tool-use APIs evolve.

What if the schema itself allows a field the model can’t confidently fill in? That’s a schema design problem, not a forcing problem — allow null or an “unknown” value in the schema itself, and instruct the model to use it when uncertain, rather than leaving no honest option and inviting a hallucinated guess. See Preventing Made-Up Output.

Do I still need to validate the output if I’ve already forced tool_choice? Yes. Forced tool_choice guarantees structural conformance to the schema at the API level, but you should still run your own validation before trusting values downstream, and design a bounded retry path for the rare cases where a call still comes back malformed or a value is out of range.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the CCA series

This is Domain 4 (Prompt Engineering & Structured Output, 20% of the exam), question 1 of 10. For the full five-domain map of the exam — including how D4 relates to the other domains and the current logistics (Pearson VUE, $125, retakes, 60 questions / 120 minutes, pass score 720/1000, as of mid-2026) — start with the Claude Certified Architect (CCA) Exam Guide.

Staying in Domain 4, the next questions in this set cover type validation on structured output, choosing when to force a tool versus let the model decide, and why structured output matters most when the consumer is a program, not a person. If you haven’t already, it’s also worth reading MCP Explained on One Diagram to see how tool schemas fit into the broader tool-use picture Claude operates in.

Browse all tutorials for the rest of the series.