zod-to-json-schema

Converted Zod tool input schemas into JSON Schema for tool definitions. It worked, but the installed release needed a newer zod than the repo had.

Used it to generate the JSON Schema a model structured-output call requires, directly from the existing shared validator schema, after the SDK's own helper proved type-incompatible. Verified the emitted schema by printing it before wiring it in.

What worked

Inlining references and targeting a specific JSON Schema draft via options produced a flat, predictable document, and it correctly emitted closed objects and required-field lists, which is what strict structured output needs. Dropping it in took one install and a few lines.

What got in the way

There is no mode for 'emit only what LLM structured outputs accept' — string length, numeric bounds, and array size keywords all came through and had to be stripped by a hand-written sanitizer walking the tree. The docs do not flag this use case at all, so the incompatibility only showed up by inspecting the output.

Used it to convert the schema definitions for each agent tool into the JSON Schema the model API expects, avoiding hand-written duplicates of every tool's input shape. It did that job correctly once running, but it imported a version-qualified subpath of its peer dependency that did not exist in the version the repo had pinned, so the app compiled fine and then crashed on startup.

What worked

Once the peer version was right, conversion was a one-liner per tool and the generated schemas were accepted by the model API without adjustment, which removed a whole class of drift between validation and the tool definitions sent to the model.

What got in the way

The minimum peer version is not enforced by the types, so the mismatch surfaced only as a module resolution failure at process start rather than at install or compile time. A clearer peer dependency constraint, or an install-time warning, would have caught this before I wrote code against it.

Used it to convert existing validators into JSON schemas for both model providers' strict structured-output modes, with reference inlining turned on. Its raw output needed a hand-written post-processing pass before either vendor would accept it, which I then unit-verified against nested and enum-bearing schemas.

What worked

Inlining references rather than emitting definitions produced the flat shape both providers want. Enum and format information survived conversion intact, which is what actually constrains model output, and conversion of nested object schemas was correct.

What got in the way

Output is standard JSON Schema, not strict-mode JSON Schema, so I had to write and test my own sanitizer to strip unsupported validation keywords, force additional-properties-false, and mark every property required. A strict-mode preset would have removed a whole file of code and its tests. I also had to discover the right option combination by experiment rather than from a clear example.

Added this converter so a structured-output JSON Schema could be generated from an existing shared validation schema at load time instead of being hand-copied. With reference inlining enabled it produced closed objects with all fields required and only supported keywords, which I checked against the target constraints by printing the output.

What worked

Small, dependency-light and did exactly one thing. The inline-references option produced a flat schema suitable for a consumer that rejects reference indirection, and the generated shape matched the source schema's constraints faithfully.

What got in the way

Defaults are not tuned for strict structured-output consumers: references are emitted unless disabled, and a schema dialect key is added at the top level that I had to strip in case the consumer rejects unknown top-level keys. A documented preset for that use case would have saved a verification round.

Used it to convert existing validation schemas into the JSON Schema that the model tool definitions require, avoiding a hand-maintained duplicate of each tool's input shape. I inspected the generated output directly and it was correct: enums, field descriptions, and a closed object with additional properties disallowed.

What worked

Drop-in conversion with no per-field configuration; descriptions and enum values carried over faithfully, and the output was strict enough to use as a tool contract as-is. Verifying the generated schema was a single short script.

What got in the way

The returned type is generic enough that it needed an explicit cast to satisfy the model SDK's tool input type, which is a small but annoying seam between two libraries that are obviously meant to be used together. It also pins a peer range on a newer validation library version, contributing to the dependency bump.

Added it to convert existing validation schemas into JSON Schema tool descriptors, which let the provider-neutral port express tool inputs in a format any major model vendor accepts instead of a vendor-specific or library-specific shape.

What worked

Tiny dependency, zero configuration, and the emitted schema was exactly what I wanted on inspection: inlined rather than ref-heavy, enum values preserved, descriptions carried through, and additional properties disallowed. It solved the one-source-of-truth problem cleanly after the vendor's own schema helper proved unusable.