Repository navigation
Description
Description
The addAdditionalPropertiesToJsonSchema function in @ai-sdk/provider-utils forcibly adds additionalProperties: false to all object schemas during tool serialization. This breaks tool calling for xAI/Grok models because xAI's validator explicitly rejects additionalProperties: false in tool schemas.
xAI's structured output docs state:
additionalPropertiesdefaults tofalsealready- schemas with boolean property schemas like
falseare rejected
So the AI SDK is adding something that xAI explicitly rejects, even though xAI's default behavior is already what the AI SDK is trying to enforce.
Root Cause
In @ai-sdk/provider-utils, the addAdditionalPropertiesToJsonSchema function unconditionally sets additionalProperties: false on all object-type schemas:
function addAdditionalPropertiesToJsonSchema(jsonSchema2) {
if (jsonSchema2.type === "object" || ...) {
jsonSchema2.additionalProperties = false; // <-- This breaks xAI
...
}
}This function is called during tool schema serialization for all providers, with no provider-specific opt-out.
Impact
Any application using the AI SDK with xAI/Grok models and tool calling will fail with:
[xAI] Invalid request content: Schema validation failed: [standard_violation] /properties/properties/additionalProperties: property schema 'false' is not supported
This affects:
- Direct xAI provider usage (
@ai-sdk/xai) - OpenRouter xAI models (
@openrouter/ai-sdk-provider) - Any other OpenAI-compatible provider routing to xAI
Investigation
We spent significant time debugging this in OpenCode and confirmed:
- The AI SDK re-adds
additionalProperties: falseAFTER any application-level sanitization - The binary bundles all dependencies at build time, so runtime interceptors don't work
- The conflict exists at the AI SDK level, not the application level
Full investigation: anomalyco/opencode#23704
Suggested Fix
Add provider-specific schema serialization options to the AI SDK, such as:
- Provider-level opt-out: Allow providers to disable
addAdditionalPropertiesToJsonSchemafor specific models - xAI-specific handling: Skip adding
additionalProperties: falsewhen targeting xAI models - Configuration option: Add a
strictToolSchemasor similar option to provider constructors
Since xAI defaults to additionalProperties: false anyway, skipping it for xAI targets preserves intended strictness while avoiding the validator rejection.
Workaround (for now)
Applications can disable tool calling for xAI models via config:
{
"provider": {
"openrouter": {
"models": {
"x-ai/grok-4.1-fast": {
"tool_call": false
}
}
}
}
}But this is not a real solution — it just disables tools entirely for xAI models.
Related
- OpenCode issue: OpenRouter xAI/Grok tool schemas fail when additionalProperties: false is emitted anomalyco/opencode#23704
- Similar Grok 3 issue (different error): Grok 3 model fails with "Invalid grammar request" error when using streamText with tools #8024
Activity
fix(xai): strip additionalProperties from tool schemas for xAI compat…
aayush-kapoor commentedon May 7, 2026
do you have a reproduction example for this? would be easy to verify fix
aayush-kapoor commentedon May 14, 2026
attached a repro script in the attached PR
fix(xai): stop emitting additionalProperties flag (#15283)
fix(xai): stop emitting additionalProperties flag (#15283)
github-actions commentedon May 14, 2026
🚀 Published in:
ai7.0.0-canary.138@ai-sdk/angular3.0.0-canary.138@ai-sdk/cohere4.0.0-canary.44@ai-sdk/devtools1.0.0-canary.24@ai-sdk/gateway4.0.0-canary.81@ai-sdk/langchain3.0.0-canary.138@ai-sdk/llamaindex3.0.0-canary.138@ai-sdk/otel1.0.0-canary.84@ai-sdk/react4.0.0-canary.139@ai-sdk/rsc3.0.0-canary.139@ai-sdk/svelte5.0.0-canary.138@ai-sdk/vue4.0.0-canary.138@ai-sdk/workflow1.0.0-canary.55@ai-sdk/xai4.0.0-canary.62fix(xai): stop emitting additionalProperties flag (#15283)
lgrammel commentedon Jul 22, 2026
Identify issue type
Identified as Bug
Confidence: High
Rationale
This is a concrete interoperability failure in existing xAI/Grok tool-calling behavior, not merely a request for a new option. The suggested configuration and provider-specific handling are proposed fixes for that failure.
Evidence
additionalProperties: falseto object schemas.