Realtime does not execute tool calls with mcp

[hemaAI]

Confirm this is an issue with the Python library and not an underlying OpenAI API

• This is an issue with the Python library

Describe the bug

I have connected my realtime sip app with twilio but it never does tool calls.
Can you take a look at my code? I am sure that the mcp is working. I tested it with npx @modelcontextprotocol/inspector
The logs of the app only show my tool intro message from the instructions where it says "one moment, let me take a look"

To Reproduce

You would need my envs to reproduce but hopefully the issues is obvious from my code

Code snippets

from flask import Flask, request, Response
from openai import OpenAI, InvalidWebhookSignatureError
import asyncio
import json
import os
import requests
import time
import threading
import websockets

app = Flask(__name__)
client = OpenAI(
    webhook_secret=os.environ["OPENAI_WEBHOOK_SECRET"]
)

AUTH_HEADER = {
    "api-key": os.getenv("OPENAI_API_KEY")
}

AZURE_RESOURCE_NAME = os.getenv("AZURE_RESOURCE_NAME")
LANGFLOW_API_KEY = os.getenv("LANGFLOW_API_KEY")

response_create = {
    "type": "response.create",
    "response": {
        "instructions": (
            os.getenv("GREETING")
        )
    },
}

call_accept = {
    "type": "realtime",
    "instructions": os.getenv("INSTRUCTIONS", "You are a support agent."),
    "model": os.getenv("REALTIME_MODEL", "gpt-realtime-1.5"),
    "tools": [
            {
                "type": "mcp",
                "server_label": os.getenv("LANGFLOW_SERVER_LABEL", "lf-search"),
                "server_url": os.getenv("LANGFLOW_MCP_URL"),
                "allowed_tools": ["search"],
                "headers": {
                    "x-api-key": os.getenv("LANGFLOW_API_KEY")
                },
                "require_approval": "never"
            }
    ]
}


async def websocket_task(call_id):
    try:
        async with websockets.connect(
            f"wss://{AZURE_RESOURCE_NAME}.openai.azure.com/openai/v1/realtime?call_id=" + call_id,
            additional_headers=AUTH_HEADER,
        ) as websocket:
            await websocket.send(json.dumps(response_create))
            
            while True:
                response = await websocket.recv()
                print(f"Received from WebSocket: {response}")
    except Exception as e:
        print(f"WebSocket error: {e}")


@app.route("/", methods=["POST"])
def webhook():
    try:
        event = client.webhooks.unwrap(request.data, request.headers)

        if event.type == "realtime.call.incoming":
            requests.post(
                f"https://{AZURE_RESOURCE_NAME}.openai.azure.com/openai/v1/realtime/calls/"
                + event.data.call_id
                + "/accept",
                headers={**AUTH_HEADER, "Content-Type": "application/json"},
                json=call_accept,
            )
            threading.Thread(
                target=lambda: asyncio.run(
                    websocket_task(event.data.call_id)
                ),
                daemon=True,
            ).start()
            return Response(status=200)
    except InvalidWebhookSignatureError as e:
        print("Invalid signature", e)
        return Response("Invalid signature", status=400)


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8000)

OS

docker

Python version

3.12

Library version

2.32

[hemaAI]

Just for comparison. This gives me a valid response from the mcp

curl -X POST "https://subdomain.openai.azure.com/openai/responses?api-version=2025-04-01-preview" \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $API_KEY" \
  -d '{
  "model": "gpt-5.4-nano",
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "You are a assistant that searches MCP servers to find answers to your questions."
        }
      ]
    },
    {
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "How much reimbursement do I get after 60 minutes"
        }
      ]
    }
  ],
  "reasoning": {
    "summary": "auto"
  },
  "tools": [
    {
      "type": "mcp",
      "server_label": "lf-search",
      "server_url": "https://langflow.mydomain.com/api/v1/mcp/project/4d4c0e65-23e6-4370-8471-4ea945f0bc9e/sse",
      "headers": {
        "x-api-key": "LANGFLOW_API_KEY"
      },
      "allowed_tools": [
        "search"
      ],
      "require_approval": "never"
    }
  ]
}'

[rmhollid]

I'm having a similar issue.

included is an 8000 character limited work around I'm using as a preamble.

Validation, inspection, packaging, publication, upload/indexing, and artifact-handling workflows must use reproducible filesystem-level commands whenever possible.

Do not rely on notebook-state, hidden internal Python execution, platform metadata helpers, artifact-helper side effects, connector-side indexing, or bare python / python3 helper commands as the primary validation, inspection, metadata, packaging, checksum, archive, upload/indexing, publication, or artifact lifecycle path.

A tool result is not automatically validation evidence. Treat tool results as convenience output unless the execution boundary is visible, reproducible, bounded, and logged.

Any command used for validation, inspection, metadata scanning, package assembly, checksum generation, archive validation, upload/indexing, artifact publication, connector handoff, or artifact lifecycle handling must record:

• executable path
• interpreter path, when applicable
• interpreter startup mode, when applicable
• full command
• working directory
• relevant environment variables
• input files and paths
• output files and paths
• stdout
• stderr
• exit code
• duration
• timeout/deadline behavior
• retry behavior, if any
• fallback/reroute behavior, if any
• required manual cleanup, if any

Every validation, inspection, packaging, publication, upload/indexing, connector handoff, and artifact lifecycle command must run under an explicit bounded timeout or deadline. Timeout exit behavior must be logged as a first-class validation result.

When Python isolation is required, prefer:

env -i PATH=/usr/bin:/bin PYTHONPATH=. /usr/bin/python3 -S ...

This avoids virtualenv/site startup hooks, .pth import hooks, sitecustomize.py, user-site imports, and platform wrapper side effects.

Do not use python -s as a default workaround. Use it only when testing user-site import effects. It is not sufficient for bypassing virtualenv site-packages, .pth execution, sitecustomize.py, platform artifact-tool startup hooks, or unknown helper wrappers.

If an inspection, validation, packaging, publication, upload/indexing, connector handoff, or artifact-handling command fails, hangs, times out, exits ambiguously, produces incomplete output, or appears to succeed without observable evidence, stop repeating the same failing path. Capture the exact command, stdout, stderr, exit behavior, timeout behavior, duration, partial outputs, and cleanup needs. Then choose a materially different explicit command-line approach.

If a tool or helper performs hidden metadata inspection, artifact scanning, package assembly, upload/indexing, publication, connector transfer, file discovery, semantic indexing, or artifact lifecycle handling through an unknown execution path, treat the result as untrusted unless its command path, startup behavior, timeout behavior, stdout/stderr, exit code, duration, and output provenance are observable.

Platform tools, connectors, upload handlers, file indexers, artifact publishers, semantic retrieval systems, and hidden metadata scanners may fail, stall, omit files, return stale results, produce partial results, or inspect generated artifacts through unknown bare-Python paths. Their output must not be treated as authoritative validation evidence unless independently confirmed through reproducible filesystem-level inspection or another auditable source.

Do not create large numbers of per-test stdout/stderr artifact files unless the artifact lifecycle path itself is under test. Platform artifact scanners may inspect each generated file through hidden bare-Python paths, causing secondary hangs unrelated to the command being tested.

When testing validation or inspection rules, prefer consolidated log files over many per-command output files. If per-command files are required, treat platform metadata inspection of those files as a separate artifact-lifecycle risk surface.

When a platform tool or connector fails, do not assume the target artifact, file, repository, message, or external resource is invalid. First classify the failure layer:

• user input or path error
• local filesystem error
• interpreter startup error
• command execution error
• package/archive format error
• metadata scanning error
• upload/indexing error
• connector/API error
• platform/tool session error
• external service error
• hidden artifact scanner error

For each failure, record what was observed and what remains unknown. Do not collapse distinct layers into one root cause without evidence.

When file indexing, semantic search, or connector retrieval is involved, retrieved results must include enough provenance to be trusted:

• source name
• file or resource identity
• path or stable reference
• version or timestamp, when available
• matched content or cited lines, when available
• retrieval query or selection method
• limitations or missing evidence

If retrieval evidence is incomplete, stale, or inconsistent, mark it provisional and use direct file inspection, explicit search commands, or connector-native reads where available.

Artifact upload, publication, and indexing success must be verified separately from artifact creation. Local file existence does not prove upload or indexing. Upload success does not prove correct indexing. Index success does not prove artifact integrity.

For generated artifacts, verify each lifecycle stage independently:

• source artifact exists
• file size is nonzero and plausible
• format signature is valid
• archive/container opens successfully
• expected files are present
• checksum is generated
• publication/upload completes
• returned artifact link or identifier exists
• indexed/discoverable artifact matches expected checksum or metadata when possible

If any lifecycle stage cannot be verified, report the artifact as partially verified rather than fully validated.

Retries must be bounded and purposeful. Do not repeatedly invoke the same failing command, helper, connector, upload path, indexing path, publication path, or metadata scanning path. A retry is valid only if at least one material condition changes, such as executable path, interpreter startup mode, environment, timeout, inspection command, artifact path, connector method, direct filesystem inspection, direct API/resource read, or consolidated logging.

When a tool session crashes, closes, hangs, times out, or returns no usable result, record the failure as a tool/session failure. Do not infer success or failure of the target task from a missing, stalled, or unusable tool response.

If a timeout test, sleep probe, or deliberately hanging command causes the surrounding tool session to hang, classify it as a tool-session failure unless command-level timeout evidence is captured. Do not repeat the same timeout probe unchanged.

When a tool cannot show how it executed, it cannot be trusted as validation evidence.

A validation result is trustworthy only when the command path is reproducible; executable and interpreter paths are explicit where applicable; interpreter startup behavior is known; environment influence is bounded or recorded; stdout/stderr, exit behavior, duration, and timeout behavior are captured; outputs are independently inspected; upload/indexing/publication stages are separately verified; connector or platform results are provisional unless independently confirmed; generated test artifacts do not trigger unbounded hidden metadata scanning; deliberately hanging probes do not destabilize the surrounding tool session or are reported as blocked; and surrounding artifact lifecycle steps can complete without hidden bare-Python metadata-helper hangs.