Check for existing issues

• I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

When using LiteLLM proxy with Groq models (groq/qwen/qwen3-32b) and MCP tool servers, the first tool-listing response works, but subsequent multi-turn messages fail because LiteLLM includes provider_specific_fields in the assistant message payload.

Groq's API is strict and rejects any unrecognized properties on messages, causing a BadRequestError.

The same MCP server and tools work perfectly when called directly through providers that tolerate extra fields (e.g., Anthropic Claude, Hermes).

LiteLLM config

litellm_settings:
  drop_params: true
  num_retries: 3
  request_timeout: 120

Note: drop_params: true is enabled but does not strip fields nested inside messages — it only drops top-level API parameters. This is confirmed by the docs: https://docs.litellm.ai/docs/completion/drop_params

Affected providers

• Groq — confirmed (provider_specific_fields is unsupported)
• Cohere — likely affected (see #24031 — similar pattern with index and name fields)
• Mistral — likely affected (see #5521 in agno-agi/agno — strict tool schema validation)

Workaround attempted

Tried additional_drop_params but it only supports top-level params and tools[*] paths, not messages[*].provider_specific_fields.

Suggested fix

Option A: Strip provider_specific_fields from all messages before sending to non-OpenAI providers (similar to the approach in PR #24510 for Cohere).

Option B: Extend drop_params / additional_drop_params to support message-level field stripping, e.g.:

additional_drop_params: ["messages[*].provider_specific_fields"]

Related issues

• #24031 — Cohere rejects index in tool_calls and name in tool results (same class of bug)
• #15761 — Groq tool call failures with OSS models
• #19849 — Groq qwen3-32b streaming + tools (fixed in v1.81.3+, but provider_specific_fields issue persists)
• #11001 — Groq not working with LiteLLM tool definitions

Steps to Reproduce

1. Configure LiteLLM proxy with a Groq model (e.g., groq/qwen/qwen3-32b)
2. Connect an MCP server that exposes multiple tools
3. Send a user message that triggers tool use (e.g., a query the model answers via MCP tools)
4. The model lists available tools and begins reasoning (first response succeeds)
5. On the follow-up turn (message index 7+), LiteLLM includes provider_specific_fields in the assistant message
6. Groq rejects the request with invalid_request_error

Relevant log output

### Error message


Error fetching response: Error: litellm.BadRequestError: GroqException -
{"error":{"message":"'messages.7' : for 'role:assistant' the following must be
satisfied[{'messages.7' : property 'provider_specific_fields' is unsupported}]",
"type":"invalid_request_error"}}

What part of LiteLLM is this about?

Other

What LiteLLM version are you on ?

v1.83.3.rc.1

Twitter / LinkedIn details

No response