API discovery: Pi’s AI package lets a tool opt into provider-side JSON Schema constraints with constrainedSampling: { type: "json_schema", strict: "prefer" } or "require". The fresh schema-conversion change takes the supported strict form at the provider boundary: it closes the object, makes every property required, and represents optional non-nullable fields as nullable there while retaining the caller’s original tool definition.
Try it
Consider an internal change-request tool with required summary and optional owner and rolloutWindow fields. Your app can keep that readable, ordinary schema. On a model and provider that honor strict tools, Pi can send the tightened provider payload instead—so a model must return a closed object with each named field, using null when an optional value is absent. That is useful when you want a reliable handoff to a reviewer, ticketing API, or deployment preview without making your application schema imitate one provider’s dialect.
Copy-paste agent instruction
In a disposable TypeScript fixture using the installed @earendil-works/pi-ai version, define one Tool with a JSON Schema object that has one required field and two optional fields. Set constrainedSampling to { type: "json_schema", strict: "prefer" }. Do not mutate the application-owned parameters object. Add a stubbed provider-adapter test that captures the outbound tool schema and asserts that it is a closed object, names every property in required, and permits null for the originally optional fields. Then run the same fixture against the exact target provider/model only with non-sensitive test data. If the provider cannot honor strict mode, record the fallback; switch to strict: "require" only when a hard failure is preferable to ordinary tool calling.Test caveat
The public implementation is currently listed in Pi’s Unreleased changelog, so this is not a claim about an available package version. Strict capability is model- and adapter-specific: the README documents both fallback and rejection cases. No live provider was run for this brief. Start with the stubbed payload test, then use a disposable account and non-sensitive inputs while accounting for authentication, cost, quotas, and your provider’s own schema rules.