"Gemini Function Calling 400 Errors: Fix Guide"
"Your first Gemini function call works, then the second turn dies with a 400. This guide maps the five exact error strings from real GitHub issues to their root causes and fixes each with before/after code."
Your first tool call goes through fine. The tool runs, you send the result back — and the API slaps you with an HTTP 400. Every gemini function calling 400 error looks like a server problem, but it's almost always your request: the history you replayed broke one of Gemini's strict message-sequencing rules. Here are the five exact errors developers keep hitting (pulled from real GitHub issues across litellm, gemini-cli, ax, and cherry-studio), what each one means, and the before/after fix. What the errors look like Error 1 — the missing signature: 400: Function call `get_weather` in the `2` content block is missing a `thought_signature`. Error 2 — the turn-order violation: 400: Please ensure that function call turn comes immediately after a user turn. Error 3 — the parallel-call mismatch: 400: Please ensure that the number of function response parts is equal to the number of function call parts. Error 4 — the wrong role: 400: Role 'function' is not supported. Error 5 — the schema rejection: 400: Invalid value at 'tools[0].function_declarations[0].parameters.properties[x].value.any_of[0].enum[0]' (TYPE_STRING) Error 1 is the one you'll meet most often, especially on Gemini 3 models. Why it happens — the gemini function calling 400 error is a history problem, not a tools problem Gemini validates every request against the "current turn" — everything since the last plain user text message. On Gemini 3 models this validation is strict: the first functionCall part in each step of the current turn must carry its thought_signature , the encrypted trace of the model's reasoning. Rebuild the conversation history by hand — reconstructing the model's turn from name + arguments but dropping the signature — and the second turn fails even…