Fix: Exclude tool params for models without function calling support (#21125)

[AtharvaJaiswal005]

Summary

Fixes #21125

JSON-configured providers (like PublicAI/EuroLLM) inherit get_supported_openai_params from OpenAIGPTConfig, which always includes tool-related parameters (tools, tool_choice, function_call, functions, parallel_tool_calls). This causes issues when models on these providers don't actually support function calling — the params are incorrectly advertised as supported, leading to API errors.

Changes

• litellm/llms/openai_like/dynamic_config.py: Override get_supported_openai_params in the dynamically generated JSONProviderConfig class to check supports_function_calling() and remove tool-related params when the model doesn't support it.
• tests/test_litellm/llms/openai_like/test_json_providers.py: Added 2 regression tests — one verifying tool params are excluded when function calling is not supported, another verifying they're included when it is.

Approach

Follows the same pattern already used by OVHCloud (litellm/llms/ovhcloud/chat/transformation.py) and Fireworks AI (litellm/llms/fireworks_ai/chat/transformation.py) — both check supports_function_calling() before including tool params.

Test Plan

• test_tool_params_excluded_when_function_calling_not_supported — mocks supports_function_calling → False, asserts tool params removed
• test_tool_params_included_when_function_calling_supported — mocks supports_function_calling → True, asserts tool params present
• All 8 existing JSON provider tests pass
• No regressions

Future Suggestion

Currently, the supported params list in OpenAIGPTConfig is hardcoded — every time OpenAI adds or changes a parameter, the base class needs a manual update. A potential improvement could be to allow JSON-configured providers to define their own supported_params list directly in providers.json, making each provider's capabilities fully data-driven instead of relying on inheritance from a hardcoded base class. This would also allow per-provider param customization without needing code changes. Happy to help with this if it's something the team is interested in!

Note: Open to any feedback or changes!

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Feb 15, 2026 9:25am

[CLAassistant]

All committers have signed the CLA.

[greptile-apps]

Greptile Summary

This PR fixes an issue where JSON-configured providers (e.g., PublicAI/EuroLLM) incorrectly advertised tool-related parameters as supported even when the underlying model doesn't support function calling, leading to API errors.

• Overrides get_supported_openai_params in the dynamically generated JSONProviderConfig class to check supports_function_calling() and remove tool-related params (tools, tool_choice, function_call, functions, parallel_tool_calls) when the model doesn't support it
• Follows the same pattern established by OVHCloud and Fireworks AI provider implementations
• Adds two mock-only regression tests verifying the behavior in both directions (supported and unsupported)
• Minor style note: the code uses inline imports inside the method body, which deviates from the project's preference for module-level imports per CLAUDE.md

Confidence Score: 4/5

• This PR is safe to merge — it's a targeted fix that follows established patterns in the codebase with no regressions expected.
• Score of 4 reflects: correct logic following the OVHCloud/Fireworks AI pattern, proper mock-only tests, no impact on existing behavior for models that support function calling. Minor deductions for inline imports (style) and a redundant try/except wrapper.
• No files require special attention — litellm/llms/openai_like/dynamic_config.py has minor style concerns but no functional issues.

Important Files Changed

Filename	Overview
litellm/llms/openai_like/dynamic_config.py	Overrides get_supported_openai_params to check supports_function_calling() and strip tool-related params when unsupported. Follows established patterns (OVHCloud, Fireworks AI). Minor style issues: inline imports and redundant try/except.
tests/test_litellm/llms/openai_like/test_json_providers.py	Adds two well-structured mock-only regression tests verifying tool params are excluded/included based on function calling support. Tests correctly use unittest.mock.patch without making real network calls.

Flowchart

flowchart TD
    A["get_supported_openai_params(model)"] --> B["super().get_supported_openai_params(model)"]
    B --> C["Call supports_function_calling(model, provider.slug)"]
    C --> D{supports FC?}
    D -->|Yes| E["Return full supported_params list"]
    D -->|No| F["Remove tool-related params:<br/>tools, tool_choice, function_call,<br/>functions, parallel_tool_calls"]
    F --> G["Log debug message"]
    G --> H["Return filtered supported_params"]
    C -->|Exception| I["Default _supports_fc = False"]
    I --> F

Loading

_{Last reviewed commit: 43cdcee}

[greptile-apps]

_{2 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Inline imports should be at module level

Per CLAUDE.md, imports should be placed at the top of the file rather than inside methods. verbose_logger is already imported at the top of the sibling json_loader.py file, confirming it's safe at module level. The supports_function_calling import from litellm.utils is used inline in a few other provider files (bedrock, sambanova) — likely to avoid circular imports — so that one may be justified. Consider moving at least verbose_logger to the top-level imports.

Suggested change

	from litellm._logging import verbose_logger
	from litellm.utils import supports_function_calling
	from litellm.utils import supports_function_calling

Context Used: Context from dashboard - CLAUDE.md (source)

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[AtharvaJaiswal005]

Good catch! Moved verbose_logger to the top-level imports. Kept supports_function_calling as an inline import to avoid circular imports (same pattern used in other provider files like bedrock and sambanova). Fixed in 83f4d30.

[greptile-apps]

Redundant try/except — supports_function_calling already handles errors

The underlying _supports_factory function in litellm/utils.py already has a comprehensive try/except block that catches all exceptions and returns False when a model isn't found (lines 2526-2537 of utils.py). This outer try/except is therefore redundant. It's not harmful, but it obscures the fact that the utility function is designed to handle missing models gracefully.

If you want to keep defensive coding here for safety, that's fine — but be aware that the except Exception: _supports_fc = False path should never actually be reached under normal conditions.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[AtharvaJaiswal005]

You're right _supports_factory already catches all exceptions and returns False for missing models, so the outer try/except was unnecessary. Removed it. Fixed in 83f4d30.