The Model Sends 'Next Tuesday,' Not a Date: Typing Tool Parameters

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

▶ Watch on YouTube & subscribe to The Stack Underflow

You wire up a book_appointment tool. It needs a date. You test it, and the model calls the tool with "next Tuesday" sitting in the date field — not 2026-07-28, not anything your downstream system can parse. So you do what feels reasonable: you add a line to the system prompt. “Please always send dates in YYYY-MM-DD format.” It works, sometimes. Then a longer conversation pushes that instruction out of the model’s effective attention, or a slightly different phrasing throws it, and "next Tuesday" is back in your logs. This is a schema problem wearing a prompting costume, and it’s exactly the kind of question Domain 2 of the Claude Certified Architect exam is built to test.

The one-sentence version: A tool’s JSON schema is the contract the model is compiling its output against — type, format, and an example constrain what comes out; a prompt note is only ever a suggestion the model can forget.

The question

A tool needs a calendar date, but the model keeps passing “next Tuesday” as free text. Best fix?

• A) Add a note in the system prompt asking nicely
• B) Tighten the JSON schema — type:string, format:date, with an example
• C) Parse the free text yourself downstream
• D) Raise the temperature

Pause here and pick an answer before you scroll — this is Domain 2 (Tool Design & MCP Integration, ~18% of the exam), and the value is in reasoning through why, not just landing on the letter.

The answer

The correct option is B — tighten the JSON schema. Specifically: type the parameter as a string, constrain it with format: "date", and give the field a description with a concrete example. The schema isn’t documentation the model politely reads and might follow — it’s the structural target the model is generating tokens against when it emits a tool call. Constrain the target, and the output that lands in the target changes.

Here’s the mechanism, as a schema-to-output diagram:

BEFORE — loose schema
{
  "date": { "type": "string" }
}
        │
        ▼
  model output:  "date": "next Tuesday"     ← valid JSON, useless value

AFTER — tightened schema
{
  "date": {
    "type": "string",
    "format": "date",
    "description": "ISO 8601 calendar date, e.g. 2026-07-20"
  }
}
        │
        ▼
  model output:  "date": "2026-07-21"       ← same model, same prompt, typed field

Nothing else changed between the two calls — not the model, not the surrounding system prompt, not the temperature. The only thing that moved is the shape of the contract the model is filling in. That’s the core Domain 2 idea worth internalizing: the schema is the guardrail. Constrain the input — don’t hope for it.

Three things are doing the work in the fixed version, and each earns its place:

Drop any one of the three and the failure mode returns in a slightly different shape: no format and you might get 07/21/26 instead of ISO 8601; no example and you might get a full ISO datetime with a spurious timezone; no type at all and you’re back to unconstrained free text.

Why the other options fail

• A) A system-prompt note. This is an instruction, and instructions compete with everything else in the context window — the conversation history, other tool results, the rest of the system prompt. It’s advisory, not structural. It can work in a short, simple conversation and quietly stop working the moment the context gets longer or the phrasing of the user’s request shifts. You’re hoping the model remembers a request; the schema makes the request unnecessary because the field itself won’t compile the wrong shape.
• C) Parse the free text downstream. This looks pragmatic — write a little natural-language-date parser and normalize "next Tuesday" yourself. But now you’ve built and you own a parsing layer that has to track every phrasing a user or model might produce: “next Tuesday,” “in two weeks,” “the 21st,” “tomorrow,” across locales and languages. You’ve moved the fix to the most expensive place to make it — after the fact, in code you maintain — when the schema could have prevented the ambiguous value from ever being generated.
• D) Raise the temperature. This is a distractor aimed at anyone who conflates “the model isn’t doing what I want” with “the model needs to be more creative.” Temperature controls sampling randomness across token choices; it has nothing to do with structural correctness. Raising it makes output less predictable, which is the opposite of what a structured field needs. If anything, tool-calling generation benefits from lower temperature, not higher.

The concept behind it

Zoom out from dates specifically, and the pattern generalizes to every tool parameter you’ll ever design: the JSON schema is not metadata about the tool — it’s an active constraint on generation. When Claude (or any tool-calling model) decides to call a function, it isn’t filling in a form after the fact; it’s generating structured output where the schema shapes what tokens are even plausible next. A tighter schema narrows the space of valid completions toward the value you actually need.

This shows up across parameter design generally, not just for dates:

LOOSE TYPING                         TIGHT TYPING
─────────────                        ────────────
"status": string                     "status": {
                                        "type": "string",
   → "shipped", "Shipped",              "enum": ["pending","shipped","delivered"]
     "done", "complete", "SHIPPED"    }
                                         → exactly one of three known values

"amount": string                     "amount": { "type": "number" }
                                         → no "twenty bucks", no currency symbols
                                           baked into the string

"date": string                       "date": { "type":"string", "format":"date" }
                                         → resolved calendar date, not "soon"

The same reasoning extends to enum for closed sets of options, minimum/maximum for numeric bounds, and pattern for values with a fixed shape like an order ID or a ZIP code. In every case the move is identical: instead of writing a stricter English sentence hoping the model complies, you write a stricter schema so the non-compliant output stops being a reachable output. This is the same discipline covered in required vs optional tool parameters — a required field is JSON Schema doing enforcement work that a prompt reminder can only ever approximate — and in writing tool descriptions that work, where the same principle applies to the description text itself: write for the model’s generation process, not for a human reader skimming documentation.

It’s worth being precise about where the line sits. Schema typing constrains shape and format — it can force a string to look like 2026-07-21, force a number to be a number, force a value into an enum. It cannot verify business meaning — a syntactically valid ISO date can still be in the past for a future-only booking tool, or a valid enum value can still be the wrong one for the user’s actual intent. That’s a downstream validation concern, layered on top of, not instead of, a well-typed schema. The schema’s job is to shrink the space of malformed values to as close to zero as JSON Schema allows; your application logic’s job is to check the remaining, well-formed values for correctness.

There’s also a tool-selection angle worth flagging, since it’s easy to conflate with typing. If the model is calling the wrong tool entirely, that’s a description problem — see why Claude picks the wrong tool. If the model is calling the right tool with a malformed argument, that’s a schema problem, and it’s this page’s whole point. Different failure, different fix — misdiagnosing one as the other is a common way to spend an afternoon rewriting a description when the schema was the actual leak.

FAQ

Does format: "date" actually validate anything, or is it just a hint? It depends on the layer. In raw JSON Schema, format keywords are commonly annotation-only by default — they document intent but many validators don’t reject non-conforming values unless you turn on strict format assertion. What it reliably does is shape the model’s generation toward the documented format, because the schema (including format and the description) is part of what the model reads to decide what to emit. Pair it with real validation in your application code if you need hard enforcement, not just better-shaped output.

Should I use format: "date" or write my own regex pattern for dates? format: "date" is the standard, portable signal, and it’s what tool-calling models are most likely to have seen consistently in training and documentation. A custom pattern regex works too and can be stricter, but it’s more to maintain and easier to get subtly wrong (leap years, month lengths). Default to format: "date" with an example in the description; reach for a pattern only when you need something format doesn’t express.

What if the tool genuinely needs to accept relative language, like “in 3 days”? Then that’s the schema’s job to say so explicitly — describe the field as accepting either an ISO date or a small set of relative expressions, and enumerate them if the set is closed. The failure in this question isn’t relative language existing; it’s relative language leaking into a field the schema quietly promised would be a resolved date. If you want relative resolution, do it deliberately: either have the model resolve it before calling the tool (with today’s date given in context) or accept the relative string and resolve it yourself downstream — but make that choice explicit in the schema, not an accident of a loose type: "string".

Is this the same fix for numbers, currencies, and IDs, or is date-typing special? Same fix, different keywords. Numbers get type: "number" instead of a string that might contain “twenty bucks.” Closed sets get enum. Fixed-shape identifiers get pattern. Dates get format: "date". The underlying principle — narrow the schema so the invalid value is no longer a reachable output — is identical across all of them; only the specific JSON Schema keyword changes.

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 2, question 2 of 10 — Tool Design & MCP Integration. If you haven’t already, start with the Claude Certified Architect exam guide for how all five domains fit together, and MCP explained on one diagram for the protocol layer that sits underneath every tool call discussed here. Two close companions in this same domain: required vs optional tool parameters, which is the same “schema over hope” argument applied to whether a field is present at all, and writing tool descriptions that work, which applies it to the description text the model reads before it ever fills in a parameter. If the failure you’re debugging is the model calling the wrong tool rather than filling a field badly, see why Claude picks the wrong tool instead. Browse all tutorials for the rest of the series.