ValidationError
pydantic.ValidationError (openai.types.ToolParameter validation)
Stack trace
pydantic_core._pydantic_core.ValidationError: 1 validation error for ToolParameter code_interpreter (type=value_error.union.discriminated_union_tag_invalid, discriminator='type', tag='code_interpreter', discriminator_alias='type', expected_tags='builtin_tool', received_tag=None) The tool object must have type='code_interpreter' with no 'input_schema' field for builtin tools.
Why it happens
The Responses API expects builtin tools like code_interpreter to be defined as simple objects with only type='code_interpreter', without an input_schema. Developers often confuse the Responses API tool format with the Assistants API or Function Calling format, which require schemas. The Responses API validates tool objects strictly: any unexpected fields or missing type values cause ValidationError at the API level.
Detection
Log the full tool object before calling client.responses.create() and inspect its structure. Responses API validation happens at request time, so add defensive assertions checking that tool.type is exactly 'code_interpreter' for builtin tools and that no input_schema key is present.
Causes & fixes
tool.input_schema field present on code_interpreter tool (copy-pasted from Function Calling format)
Remove input_schema entirely. Builtin tools like code_interpreter have no configurable parameters. Only include type='code_interpreter'.
tool.type is missing or set to None instead of the string 'code_interpreter'
Explicitly set type='code_interpreter' as a string. Do not use an enum or dict: pass the literal string value.
tool object is nested incorrectly in the tools array (e.g., wrapped in extra dict layers)
Pass a flat list of tool objects: tools=[{'type': 'code_interpreter'}]. Each tool must be a direct dict at the array level, not nested.
Using Assistants API tool format (with Tool.CODE_INTERPRETER or full schema) instead of Responses API format
Switch to the Responses API builtin tool syntax: pass {'type': 'code_interpreter'} as a plain dict, not a Tool class or Enum.
Code: broken vs fixed
import os
from openai import OpenAI
client = OpenAI(api_key=os.environ.get('OPENAI_API_KEY'))
# BROKEN: code_interpreter tool includes input_schema (Assistants API format)
tools = [
{
'type': 'code_interpreter',
'input_schema': { # ❌ This field is NOT allowed in Responses API
'type': 'object',
'properties': {'code': {'type': 'string'}},
'required': ['code']
}
}
]
response = client.responses.create(
model='gpt-4o',
messages=[{'role': 'user', 'content': 'Calculate 2 + 2'}],
tools=tools # ❌ ValidationError: input_schema not allowed for builtin tools
)
print(response.content)import os
from openai import OpenAI
client = OpenAI(api_key=os.environ.get('OPENAI_API_KEY'))
# FIXED: code_interpreter tool has only type field, no input_schema
tools = [
{
'type': 'code_interpreter' # ✅ Builtin tools need only type field
}
]
response = client.responses.create(
model='gpt-4o',
messages=[{'role': 'user', 'content': 'Calculate 2 + 2'}],
tools=tools # ✅ Valid tool definition for Responses API
)
print(f"Response received: {response.content}")
print(f"Tool calls: {[block for block in response.content if hasattr(block, 'type') and 'tool_use' in str(block.type)]}")Workaround
If you must support both Assistants API and Responses API code paths, conditionally build the tool object: For Responses API, use {'type': 'code_interpreter'}. For Assistants API, use the full Tool schema with input_schema. Use a version check or separate functions to manage both formats without mixing them.
Prevention
Always check the official Responses API tool documentation (openai.com/docs/guides/responses-api) before building tool objects. Responses API tool format differs from Assistants API and Function Calling: builtin tools are configuration-free. Use type hints (Pydantic models from openai.types) in your code to catch structural errors at development time, not at API call time.