An OpenAI tool Mistral rejected: the SDK's strict: null
TL;DR: mistral-common's Function.from_openai rejected any tool definition containing "strict": null. That is exactly what the OpenAI SDK produces by default when you dump a tool. My fix (PR #396) was merged by the Mistral AI maintainers on October 21, 2026, and will ship in the next release after 1.12.0. Until then, there is a one-line workaround (below).
The symptom
You are moving agents from OpenAI to Mistral, or running an OpenAI-compatible gateway in front of Mistral models. Your tools are typed with the OpenAI SDK, then converted by mistral-common:
from openai.types.shared import FunctionDefinition
from mistral_common.protocol.instruct.tool_calls import Function
tool = FunctionDefinition(name="get_weather", parameters={"type": "object"})
Function.from_openai(tool.model_dump())
On mistral-common 1.12.0:
pydantic_core._pydantic_core.ValidationError: 1 validation error for Function
strict
Input should be a valid boolean [type=bool_type, input_value=None, input_type=NoneType]
The tool is valid. Tool.from_openai and ChatCompletionRequest.from_openai(tools=...) fail the same way, because they call the same function.
The cause
In the OpenAI schema, strict is optional and nullable, so the SDK dumps it as None when you don't set it:
{'name': 'get_weather', 'description': None, 'parameters': {'type': 'object'}, 'strict': None}
Function.from_openai already replaced None with defaults for parameters and description, but not for strict. On the Mistral side, strict is a boolean that defaults to False, so Pydantic rejected None.
This is a silent integration bug: each library is right on its own, and the failure only shows up where they meet.
The fix
Two lines in Function.from_openai: when strict is None, drop the field so that the model falls back to its default (False).
if filtered.get("strict") is None:
filtered.pop("strict", None)
True and False behave as before. Two tests cover Function.from_openai and Tool.from_openai with "strict": None. The full suite (1,294 tests), ruff and mypy all pass.
Timeline:
- issue #393 on October 20 (minimal reproduction);
- PR #396 the same day;
- merged on October 21.
If you are on 1.12.0 today
Until the next release, dump your tools without null fields:
Function.from_openai(tool.model_dump(exclude_none=True))
If your tools arrive as raw JSON (in a gateway, for example), drop strict when it is null before converting.
A second report, fixed differently by Mistral
The same day I reported an inconsistency in the tokenizers (issue #395). Tekkenizer.decode still accepted the legacy integer special token policies (0, 1, 2), but id_to_byte_piece rejected them.
I had proposed aligning id_to_byte_piece with decode. The maintainers confirmed the bug and chose the opposite approach: they removed the integer backward compatibility everywhere (PR #402, October 21). It is their design call, and a consistent one.
What it means for you: if your code calls decode(..., special_token_policy=1), it will fail with the next release. Switch to the enum, or to its string value, now:
from mistral_common.tokens.tokenizers.base import SpecialTokenPolicy
tokenizer.decode(tokens, special_token_policy=SpecialTokenPolicy.KEEP) # or "keep"
Key takeaways
- A tool dumped by the OpenAI SDK contains "strict": None. mistral-common 1.12.0 rejects it, and the next release accepts it.
- Workaround today: model_dump(exclude_none=True).
- Integer special token policies (0, 1, 2) are going away: use SpecialTokenPolicy.
- When migrating from OpenAI to Mistral, test the conversion of your tools exactly as your code produces them, not only hand-written dicts.
Related
This is the second contribution merged by Mistral AI, after PR #349 on offline tokenizers (article). Other fixes are awaiting review: Three silent bugs in Mistral AI's Python libraries.
---
Zakaria Khchiche, freelance Data & AI Tech Lead: 200+ AI agents in production (Copilot Studio, Azure AI Foundry, Azure OpenAI), contributor to Microsoft Agent Framework and Mistral AI. LinkedIn · Website
*Want your team to build agents like these? I run a hands-on Copilot Studio training (in French, with Spar-x, Qualiopi-certified, eligible for OPCO funding in France): zakariakhchiche.github.io and a free AI Act article 4 kit: zakariakhchiche.github.io
Mentions
An OpenAI tool Mistral rejected: the SDK's strict: null TL;DR: mistral-common's Function.from_openai rejected any tool definition containing "strict": null. That is exactly what the OpenAI SDK produces by default when you dump a tool. My fix (PR #396) was merged by the Mistral AI maintainers on October 21, 2026, and will ship in the next release after 1.12.0. Until then, there is a one-line workaround (below). The symptom You are moving agents from OpenAI to Mistral, or running an OpenAI-compatible gateway in front of Mistral models. Your tools are typed with the OpenAI SDK, then converted by mistral-common: from openai.types.shared import FunctionDefinition from mistral_common.protocol.instruct.tool_calls import Function tool = FunctionDefinition(name="get_weather", parameters={"type": "object"}) Function.from_openai(tool.model_dump()) On mistral-common 1.12.0: pydantic_core._pydantic_core.ValidationError: 1 validation error for Function strict Input should be a valid boolean [type=bool_type, input_value=None, input_type=NoneType] The tool is valid. Tool.from_openai and ChatCompletionRequest.from_openai(tools=...) fail the same way, because they call the same function. The cause In the OpenAI schema, strict is optional and nullable, so the SDK dumps it as None when you don't set it: {'name': 'get_weather', 'description': None, 'parameters': {'type': 'object'}, 'strict': None} Function.from_openai already replaced None with defaults for parameters and description, but not for strict. On the Mistral side, strict is a boolean that defaults to False, so Pydantic rejected None. This is a silent integration bug: each library is right on its own, and the failure only shows up where they meet. The fix Two lines in Function.from_openai: when strict is None, drop the field so that the model falls back to its default (False). if filtered.get("strict") is None: filtered.pop("strict", None) True and False behave as before. Two tests cover Function.from_openai and Tool.from_openai with "strict": None. The full suite (1,294 tests), ruff and mypy all pass. Timeline: - issue #393 on October 20 (minimal reproduction); - PR #396 the same day; - merged on October 21. If you are on 1.12.0 today Until the next release, dump your tools without null fields: Function.from_openai(tool.model_dump(exclude_none=True)) If your tools arrive as raw JSON (in a gateway, for example), drop strict when it is null before converting. A second report, fixed differently by Mistral The same day I reported an inconsistency in the tokenizers (issue #395). Tekkenizer.decode still accepted the legacy integer special token policies (0, 1, 2), but id_to_byte_piece rejected them. I had proposed aligning id_to_byte_piece with decode. The maintainers confirmed the bug and chose the opposite approach: they removed the integer backward compatibility everywhere (PR #402, October 21). It is their design call, and a consistent one. What it means for you: if your code calls decode(..., special_token_policy=1), it will fail with the next release. Switch to the enum, or to its string value, now: from mistral_common.tokens.tokenizers.base import SpecialTokenPolicy tokenizer.decode(tokens, special_token_policy=SpecialTokenPolicy.KEEP) # or "keep" Key takeaways - A tool dumped by the OpenAI SDK contains "strict": None. mistral-common 1.12.0 rejects it, and the next release accepts it. - Workaround today: model_dump(exclude_none=True). - Integer special token policies (0, 1, 2) are going away: use SpecialTokenPolicy. - When migrating from OpenAI to Mistral, test the conversion of your tools exactly as your code produces them, not only hand-written dicts. Related This is the second contribution merged by Mistral AI, after PR #349 on offline tokenizers (article). Other fixes are awaiting review: Three silent bugs in Mistral AI's Python libraries. --- Zakaria Khchiche, freelance Data & AI Tech Lead: 200+ AI agents in production (Copilot Studio, Azure AI Foundry, Azure OpenAI), contributor to Microsoft Agent Framework and Mistral AI. LinkedIn · Website *Want your team to build agents like these? I run a hands-on Copilot Studio training (in French, with Spar-x, Qualiopi-certified, eligible for OPCO funding in France): zakariakhchiche.github.io and a free AI Act article 4 kit: zakariakhchiche.github.io