Gemini missing thought_signature After a Tool Call: How to Fix It

If Gemini works on the first request but returns a missing thought_signature error after a function call, inspect the model content saved between requests. Return the original function-call part with its signature before appending the function response. Saving only the function name and arguments can discard state needed for the next turn.

This guide targets tool-call continuations and follows Google’s thought-signature documentation, checked September 14, 2026. Requirements differ across model generations and APIs. Do not assume that every Gemini model returns the same HTTP 400 whenever a signature is absent.

Locate the field for your actual interface

The error may use snake_case even when the native REST payload uses camelCase. In the native generateContent JSON structure, thoughtSignature belongs to the part alongside functionCall. Python SDK objects commonly expose thought_signature. A compatibility endpoint may carry metadata in a provider-specific extension instead.

Do not move a field to a guessed location merely because the error spells its name differently. A successful first call only proves that the first request was accepted. The continuation is where a text-only history store or adapter may lose required state.

Keep the model turn before adding the tool response

The model’s complete content belongs in the history before the following user content containing the actual function response. Google’s function-calling guide is the reference for constructing those turns. Preserve the parts in their original order rather than reconstructing them from a chat widget.

Conceptually, the continuation is:

user: original task
model: original returned content, including functionCall and signature-bearing part
user: functionResponse containing the real result
model: next response

This is a synthetic sequence, not an executable request or a trace from a live API test. The real call must use the response received for that task. Never replace the signature with a random string or an example copied from someone else’s conversation.

Parallel calls do not mean a signature on every call

For the currently documented Gemini 3 tool workflow, the first function-call part of each step carries the required signature. In a parallel call response, the first function-call part carries that signature; the later function-call parts do not each need one. A validator that demands a separate signature on every parallel part can therefore reject a correct response.

Preserve the original group, such as call one with its signature followed by call two, and then return the corresponding function results. Do not rearrange the history into call one, result one, call two, result two when the two calls came from one parallel model turn. Sequential steps are different: each new model step must preserve its own returned state.

This distinction matters for middleware that normalizes all tools into individual messages. A convenient generic representation can lose the original grouping. Keep enough information to reproduce the native sequence for the endpoint you are calling.

The SDK can only preserve what you keep

Official SDK chat handling can manage signatures when you retain the full response and history. If your application converts the response to text, extracts only function arguments, or stores a reduced JSON schema, those guarantees no longer describe your whole application.

Inspect three objects: the response received from the provider, the history saved by your application, and the next request actually serialized. Identify the first boundary where the signature-bearing part disappears or changes. Common investigation points include database schemas, message filters, callback handlers and adapters between different API families.

For a minimal reproduction, use a harmless function that returns a fixed local value. It should have no external side effects. The purpose is to exercise one complete function round, not to rerun a payment or deployment while debugging a serializer. This article does not claim that a particular third-party client version has been fixed.

Turning thinking down is not a universal workaround

Do not assume that a minimal thinking setting removes the tool-workflow signature requirement. Follow the thinking documentation for the specific model and interface. Changing a generation setting is not the same as restoring state that has already been discarded.

Google documents special handling for some imported trajectories, but a special bypass marker is not the normal repair for an application losing its own model response. First correct the history preservation path. Otherwise the same application can continue to discard useful metadata while hiding one validation symptom.

Also distinguish missing signatures from malformed function responses. A wrong result name, missing call correspondence or invalid tool schema may produce a different error. Record the full status and error body so that a generic HTTP 400 does not send you down the wrong diagnostic path.

Verify the repair without claiming more than you tested

After correcting serialization, run the same small function workflow on the exact route and SDK version that failed. Confirm that the continuation is accepted and the function result is reflected in the answer. If you rely on parallel functions, add a separate parallel case; a single-call success does not validate that path.

Document whether the test was local schema validation or a real API call. Syntax checks cannot prove provider acceptance. If a gateway is involved, do not claim it repairs missing client state unless you tested that behavior and can explain the mechanism.

For model cost and access information, see the Gemini 3.8 API guide. For another provider’s similarly named error, use the Claude signature guide; native Claude fields cannot simply be copied into Gemini messages.

Frequently asked questions

Must every parallel function call have a signature?

No. The documented Gemini 3 parallel workflow places the required signature on the first function-call part of the step. Preserve the returned group unchanged.

Why is the error snake_case but REST uses camelCase?

Error terminology and SDK property names can differ from native REST field names. Use the schema of the interface receiving your request.

Will changing providers solve it?

Not necessarily. If the client drops required state before sending the request, changing the destination does not restore that state. Inspect the request path first.