Unexpected executableCode Instead of functionCall in Gemini Realtime WebSocket API

[vanshaj697]

Description of the bug:

Hello team,

I am working with the Gemini Realtime WebSocket API and trying to enable tool/function calling. However, instead of receiving functionCall events, the model consistently responds with executableCode blocks.

Setup

API: wss://generativelanguage.googleapis.com/ws/google.ai.generativelanguage.v1alpha.GenerativeService.BidiGenerateContent

Model: models/gemini-live-2.5-flash-preview

Configuration:

{
  "setup": {
    "model": "models/gemini-live-2.5-flash-preview",
    "generationConfig": {
      "responseModalities": ["AUDIO"],
      "temperature": 0.3,
      "maxOutputTokens": 512,
      "speechConfig": {
        "languageCode": "en-IN",
        "voiceConfig": { "prebuiltVoiceConfig": { "voiceName": "Kore" } }
      }
    },
    "systemInstruction": { "parts": [{ "text": "system instruction here" }] },
    "tools": {
      "functionDeclarations": [
        {
          "name": "get_complaint_number_tool",
          "description": "Get complaint number using consumer or mobile number.",
          "parameters": {
            "type": "object",
            "properties": {
              "consumer_number_or_mobile_number": {
                "type": "string",
                "description": "Consumer number, mobile number, or identifier"
              }
            },
            "required": ["consumer_number_or_mobile_number"]
          }
        }
      ]
    }
  }
}

Actual vs expected behavior:

Observed Behavior
When a user provides a number (e.g. 2001234567), the model does not produce a functionCall. Instead, it generates an executableCode block, such as:

{
  "language": "PYTHON",
  "code": "print(default_api.get_complaint_number_tool(consumer_number_or_mobile_number='2001234567'))"
}

Expected Behavior

The API should emit a functionCall event with structured arguments, e.g.:

{
  "functionCall": {
    "name": "get_complaint_number_tool",
    "args": {
      "consumer_number_or_mobile_number": "2001234567"
    }
  }
}

Any other information you'd like to share?

• The schema keys were confirmed as functionDeclarations (camelCase) and parameters (not parametersSchema).
• Using the same schema in REST API works as expected (returns proper functionCall).
• This behavior is reproducible even with a minimal test setup (tools + text-only prompt, no audio).
• Error logs when experimenting with different schema keys:
  • "Unknown name 'parametersSchema'"
  • "Unknown name 'function_declarations'"

Question

Is functionCall currently supported in the Realtime WebSocket API for Gemini Live models, or is it only available in the REST API?
If it is supported, could you clarify the exact JSON schema required for tool declarations in the WebSocket setup?

[Gunand3043]

Hi, I tested with the same function definition you shared, and it works correctly on my end, the API returns the expected functionCall with structured arguments. For your reference, I have attached a Gist here
, and you can also check out the live api tool calling cookbook for more examples.

Thanks.

[eyvindan]

Hi,

Looks like the functionCall is returned in toolCall (and its not part of the serverContent as expected).

{
"toolCall": {
"functionCalls": [
{
"name": "turn_on_the_lights",
"args": {},
"id": "function-call-10989268590646059680"
}
]
}
}

---

let raw = event.data;
let messageData;

if (typeof raw === 'string') {
messageData = JSON.parse(raw);
} else if (raw instanceof Blob) {
messageData = JSON.parse(await raw.text());
} else {
messageData = JSON.parse(String(raw));
}

if (messageData.toolCall){
console.log("Got toolCall", messageData);
}

[vanshaj697]

Hi, I tested with the same function definition you shared, and it works correctly on my end, the API returns the expected functionCall with structured arguments. For your reference, I have attached a Gist here , and you can also check out the live api tool calling cookbook for more examples.

Thanks.

Hi, thanks for helping me.

[github-actions]

Marking this issue as stale since it has been open for 14 days with no activity. This issue will be closed if no further activity occurs.