[lcampbell]

> The fix that worked is a schema transform at the provider boundary. For OpenAI-family models only, we rewrite every optional property to be required but nullable, using anyOf: [T, null], which gives the model an explicit way to say “not using this.”

I admit, I've only used a bastardized form of MCP, but this smells... wrong? It's not clear to me why the Typescript type definitions would have any influence on (what I presume is) JSONSchema being sent from the agent to the inference backend as part of the completion request. The MCP specification (which the OpenAI backend might not use, I don't know) has an explicit field to signify "optional" parameters in the JSONSchema; my read on this is there's a bug somewhere between the Typescript layer(??) and the generated tool description which is actually sent to the inference backend.

It's possible the inference backend has changed from "generate valid tool responses" to "generate valid tool responses according to the JSON schema [where no parameters are optional]" but it's impossible to tell without seeing the actual requests sent to the inference backend (which I didn't see in TFA).

[SwtCyber]

The thing is this isn't a schema generation or Typescript bug at all. This is just how openai's function calling works under the hood. Their weights were fine-tuned for tool use to output the most complete data structures possible. If the model sees a parameter name in the system prompt context it will try to fill it with a value, even if it is not in the required array

[avianlyric]

If it isn’t a schema generation or typescript bug, then why did changing the API types they use result in different model behaviour?

[dannyw]

Modern frontier models, including Fable/Opus and 5.6, are often very loose with tool calls, and often don’t follow your schema precisely.

For example, see this post for Claude models hallucinating properties for an edit/replace tool call in Pi: https://lucumr.pocoo.org/about/

I suspect some part of this comes from the noticed intelligence degradation when you do constrained decoding. Yes, you’re guaranteed schema validation, but you lose a lot of intelligence. It’s fine if you just want a classifier, a summary, a prompt enhancement, etc; but I’d be careful in agentic loops.

Harnesses like Claude Code do a lot of preprocessing, repairing, cleaning, etc; as the blog post shows. You usually don’t see it.

In practice it’s easier and better to just make your harness “looser” and work better with the model (they’re coming out every month or two anyway, each with their own idiosyncrasies) than to assume and force perfect correctness.

Welcome to vibe applied AI ;)

[JLO64]

I believe the post you were trying to link was this one: https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/

[bluelightning2k]

It's not typescript definitions. Presumably it's zod schemas which are both typescript types and JSONSchema for the object.

Although tbh the article makes a lot of this obvious and trivial change in syntax.