GPT-5.2 fails to call tools properly

Hey,
We’ve recently switched to gpt-5.2 in our agent solution. During tests we observed that sometimes agent is not producing tool calls but includes tool input json as part of preamble message. Does anyone experienced similar issue?

You can see it on the trace screenshot below. Here is the schema of the tool:

{
“name”: “contact_agent”,
“description”: “Communicate with recipient (sub-agent) by sending a message.”,
“strict”: true,
“parameters”: {
“properties”: {
“recipient”: {
“description”: “The recipient of the message.”,
“title”: “Recipient”,
“type”: “string”
},
“content”: {
“description”: “The message to send to recipient.”,
“title”: “Content”,
“type”: “string”
}
},
“required”: [
“recipient”,
“content”
],
“title”: “contact_agent_args”,
“type”: “object”,
“additionalProperties”: false
}
}

In the Discourse software, you can enclose text in three backtick characters on their own lines:

```json
your copied code or string
```

And then receive a code fence presentation of the original text without alteration except for syntax highlighting:

{
  "name": "contact_agent",
  "description": "Communicate with recipient (sub-agent) by sending a message.",
  "strict": true,
  "parameters": {
    "properties": {
      "recipient": {
        "description": "The recipient of the message.",
        "title": "Recipient",
        "type": "string"
      },
      "content": {
        "description": "The message to send to recipient.",
        "title": "Content",
        "type": "string"
      }
    },
    "required": [
      "recipient",
      "content"
    ],
    "title": "contact_agent_args",
    "type": "object",
    "additionalProperties": false
  }
}

The suggestion I would have is that in a developer-provided function, you avoid the use of “recipient”, as that is already an internal name. Then that the function be wholly described within in description fields, saying what it will do and what it is good for, when it shall be called, and what action will result and what will be returned. This one tells the AI nothing.

Then eliminate field like “title” that do not match the tool name itself.

Also, do not refer to “preamble” in any prompting. In your main tool description field, if you want announcement first, simply indicate, “the user must be informed of your intention to invoke this function tool method before you then automatically send to it in the same response”.

See if the AI model calls tools properly when they describe their usefulness fully in a self-contained manner that is not otherwise referred to in prompting.

Hey @_j
The recipient is string alias of agent that should be contacted - the supervisor have list of allowed agents + their descriptions in the prompt.

This issue is not about this specific tool (I’ve just used it as example). The issue is that the agent didn’t generate a tool call, but instead it included tool call input in intermediate message that is being generated between tool calls. This issue is not present in gpt-5.1, therefore I ‘m wondering if anyone else experienced similar case and if this is something acknowledged.

@podkova103 Yeah exactly, we are having the same issue on gpt-5.2. Tool calls are outputted in text-delta events in random xml or json like strucutres instead of proper tool call event.

Just wanted to say that we are experiencing the same thing. It will output the function arguments as content instead of proper tool calls. This happens maybe 30% of the time on a very simple tool call.

We are observing the same issue with gpt-5.2, in particular gpt-5.2-chat-latest. It seems to fail to parse harmony response format and returning it as an unparsed text
[some text] <commentary to=functions.end_conversation 彩神争霸如何 不中反json 全民彩票json="{}" 天天中彩票appjson>

Same issues with `gpt-5.4`.

Has anybody figured out a workaround yet?

Same issues with gpt-5.2 on Azure AI.

In my case, this was a setup issue caused by a bug elsewhere in the code. The tools definitions got nulled before passing them to the .ChatCompletion → the LLM was hallucinating the tool calls in the text response.

I am observing this with gpt-5.2 as well:

This is the format in which i am observing the text, which is leaking into the final user-facing response

{
type: "text",
text: {"recipient_name":"functions.<tool_name>","results":[{"title":<title_text_1>, "snippet":"","source":<source_text>","date":},{"title":"<title_text_2>","snippet":<snippet_text_2>,"source":<source_text_2>,"date":<date_text_2>}]}
}

I am not able to reproduce the error deterministically but it is occurring very frequently.

Hey everyone! sorry for the delayed response, and thanks for sharing this example.

If you’re still seeing this with GPT-5.2, please check that the tool definitions are included in the outgoing API request and compare the raw API response with what your application displays. Our function-calling guide may help you review the setup.

If the issue persists, please contact support@openai.com with an example request and response, removing sensitive information.

-GS

That’s okay. I’m sure six months later, for a symptom of the AI understanding the specification of the function tool provided in the AI request and then having a token-prediction fault in the post-training on tool-calling and not producing the required output shape for the API backend to package the tool call with its ID in the proper output shape, that your advice “see if you sent tools” or “see if your app is the problem” is not advice anyone has been waiting for as the relief-providing final solution.

For the JSON appearing in the preamble, could you share a redacted wire-level capture of one failing turn, excluding credentials and sensitive payloads? That would help distinguish API-emitted text from tool events rendered as text by the agent framework or trace viewer.

A few troubleshooting steps may help narrow down the tool-calling behavior reported in this thread:

  • Check the tools actually sent with each request. One participant traced their instance to tool definitions being cleared before the API request. This is a useful check, although it doesn’t establish the cause of everyone else’s report.
  • Distinguish assistant text from structured tool calls. Responses API function calls appear as function_call output items; Chat Completions uses tool_calls. For streaming responses, tool arguments must be handled separately from text deltas. JSON appearing in an assistant message is not itself an executable tool call.
  • Separate schema enforcement from tool selection. strict: true enforces the argument schema when a function is called. It does not require a call. When a particular workflow step requires a tool, use tool_choice: "required" or select the specific function.
  • Isolate the integration layer. Comparing a minimal direct API request with the same request through an agent framework can help distinguish API behavior from parsing or display issues.

The official function-calling guide documents these controls and provides examples for both APIs and streaming.

The reports span different models and integrations, so a single underlying cause has not been established. We’re closing this topic with the guidance above. Persistent API issues can be investigated through OpenAI Support.

-GS