[Bug]: Responses API → Chat Completions bridge drops tool names and forwards unsupported tool types (custom, shell)

[TopherMayor]

What happened?

When using use_chat_completions_api: true to bridge the Responses API to Chat Completions for providers that don't support /v1/responses (e.g., DeepSeek, Z.AI/GLM, MiniMax), two bugs in transform_responses_api_tools_to_chat_completion_tools cause failures:

Bug 1: Unsupported tool types forwarded as-is

When Codex or other clients send tools with type: "custom" (a valid Responses API tool type per the OpenAI SDK's CustomToolParam), the else branch in transform_responses_api_tools_to_chat_completion_tools passes them through unchanged:

# Current code (line ~1411)
else:
    chat_completion_tools.append(
        cast(Union[ChatCompletionToolParam, OpenAIMcpServerTool], tool)
    )

Providers like DeepSeek reject this: tools[0].type: unknown variant 'custom', expected 'function'.

Bug 2: Function tool names lost during transformation

When clients send tools in Chat Completion format nested under the Responses API (which Codex does), the transformation only reads name from the top level of the tool dict:

# Current code (line ~1394)
"name": typed_tool.get("name") or "",  # Returns "" when name is nested under "function"

The Responses API FunctionToolParam has name at the top level ({"type": "function", "name": "read"}), but Codex sends Chat Completion-style tools even in Responses API requests: {"type": "function", "function": {"name": "read", ...}}. The transformation ignores the nested function.name, resulting in tools[0].function.name: empty string.

Expected behavior

1. Non-standard tool types (custom, shell, etc.) should be dropped during Responses API → Chat Completions transformation, not forwarded.
2. Function tool names should be read from both tool.name (Responses API format) AND tool.function.name (Chat Completion format) to handle both styles.

Reproduction

# config.yaml
model_list:
  - model_name: deepseek-v4-pro
    litellm_params:
      model: deepseek/deepseek-v4-pro
      api_key: os.environ/DEEPSEEK_API_KEY
      drop_params: true
      use_chat_completions_api: true

curl -X POST http://localhost:4000/v1/responses \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-pro",
    "input": "list files",
    "max_output_tokens": 20,
    "tools": [
      {"type": "custom", "name": "shell", "description": "run shell"},
      {"type": "function", "function": {"name": "read", "description": "read file", "parameters": {"type": "object", "properties": {"path": {"type": "string"}}}}}
    ]
  }'

Results in:

BadRequestError: DeepseekException - Invalid 'tools[0].function.name': empty string

Proposed fix

In litellm/responses/litellm_completion_transformation/transformation.py, transform_responses_api_tools_to_chat_completion_tools:

# Fix 1: Drop unknown tool types instead of forwarding
else:
    pass  # Drop custom/shell/other unsupported types

# Fix 2: Read function name from both formats
elif tool.get("type") == "function":
    typed_tool = cast(FunctionToolParam, tool)
    _fn = tool.get("function") or {}
    parameters = dict(_fn.get("parameters") or typed_tool.get("parameters") or {})
    if not parameters or "type" not in parameters:
        parameters["type"] = "object"
    chat_completion_tool: Dict[str, Any] = {
        "type": "function",
        "function": {
            "name": _fn.get("name") or typed_tool.get("name") or "",
            "description": _fn.get("description") or typed_tool.get("description") or "",
            "parameters": parameters,
            "strict": _fn.get("strict") or typed_tool.get("strict") or False,
        },
    }

Why drop_params: true doesn't fix this

drop_params strips unsupported top-level request parameters. It does not traverse the tools array to filter tool types or fix tool field mapping.

LiteLLM version

v1.83.14

Related issues

• [Bug]: tools[].custom.eager_input_streaming: Extra inputs are not permitted — Bedrock rejects custom tool fields for Haiku 4.5 #23825 (custom tool fields forwarded to Bedrock — same class of bug, different provider path)

[Artyum]

I'm still seeing this issue on the latest versions.

Environment:

Cursor 3.13.25 (latest)
LiteLLM ghcr.io/berriai/litellm:main-latest (LiteLLM 1.95.0)
OpenAI GPT-5.6 (gpt-5.6-luna, also reproduced with other GPT-5.6 models)
OpenAI-compatible BYOK via LiteLLM

The LiteLLM Playground works correctly with the same model, so the upstream OpenAI endpoint and LiteLLM configuration appear to be fine.

In Agent mode, Cursor sends POST /chat/completions with a Chat Completions payload, but one of the tools is still Responses-style:

{
  "type": "custom",
  "name": "ApplyPatch",
  "format": {
    "type": "grammar",
    ...
  }
}

OpenAI rejects the request with:

Missing required parameter: 'tools[7].custom'

[david-melville]

Independent reproduction against Azure confirms this remains present in LiteLLM 1.93.0, and the relevant function on main still reads only the top-level fields.

One important completeness point: preserving only nested name and description avoids Azure's immediate empty-string 400, but it still silently replaces a nested JSON schema with {"type": "object"} and forces strict=False. A nested tool with required properties can therefore be accepted while the model receives the wrong contract.

For the Chat-Completions-nested shape, the bridge needs to preserve all four fields with top-level precedence:

• name
• description
• parameters, including properties and required
• strict, including an explicit false

That makes the more complete normalization in #28696, or an equivalent implementation, preferable to a name/description-only fix. A regression test should assert nested required properties and strict=True, plus top-level-wins behavior when both shapes are populated.