Feature Request: Add a debug option to display OpenAI-Compatible toolcall chunks in the WebUI

[ServeurpersoCom]

Prerequisites

• I am running the latest code. Mention the version if possible as well.
• I carefully followed the README.md.
• I searched using keywords relevant to my issue to make sure that I am creating a new issue that is not already open (or closed).
• I reviewed the Discussions, and have a new and useful enhancement to share.

Feature Description

TL;DR

Add a debug option to the WebUI that displays raw toolcall chunks (like reasoning blocks) and lets users inject custom Harmony-formatted tool documentation.
A simple and transparent way to inspect model behavior and help the community improve llama.cpp.

Summary

Introduce a new WebUI Settings option to display OpenAI-Compatible toolcall chunks, similar to the existing reasoning_content (thinking blocks) display.

This idea was inspired by PR #13501 by @samolego, who did excellent exploratory work on tool calling in the WebUI.
Even though that PR was eventually closed, it sparked this simpler and safer approach: a read-only visualization of the Harmony toolcall field (if present) that fits cleanly into the existing WebUI logic.

Rationale

This feature would include a small optional text field to inject custom tool documentation. Together, the checkbox and input field would turn the WebUI into a lightweight debugging console: useful for verifying model compatibility or observing backend behavior during refactoring.

Proposal

• Add a checkbox in Settings (e.g. Show toolcall chunks).
• When enabled, the WebUI displays toolcall-related chunks as structured blocks, similar to reasoning content.
• Add an optional empty Tool prompt field to inject custom tool documentation, formatted according to the Harmony specification, directly into the JSON request. || Using the existing "Custom JSON parameters to send to the API. Must be valid JSON format." field may work!
• No runtime execution, no security implications, no additional parsing complexity — purely a read-only display option.

Benefits

• Fully consistent with the existing OpenAI-Compatible API logic.
• Helps developers debug and understand model outputs in real time.
• Zero execution risk (read-only visualization).
• Educational for those learning about tool calls and chunked responses.
• No impact on inference stability or backend performance.

@ngxson @allozaur @ggerganov

Motivation

Motivation

The main goal is transparency: allowing users to see the exact toolcall chunks emitted by models in real time, without executing anything client-side.
It provides valuable insight for debugging, education, and development of larger integrations built on top of llama.cpp.
This also aligns perfectly with ongoing refactoring work and non-regression testing, helping ensure consistent and predictable behavior across models and backend changes.

Possible Implementation

No response

[ggerganov]

I think it is a great idea to have more debugging options on the UI side. I can't comment about the specific implementation - this will depend mostly on @allozaur. But as an example, on the server-side I typically use increased verbosity with -lv 1 with various environment variables and as of recently curling the /slots endpoint with LLAMA_SERVER_SLOTS_DEBUG enabled to track the specific prompts and generations from external tools.

[samolego]

Sounds great to me :D, I'm happy to assist if needed!

[ServeurpersoCom]

[ServeurpersoCom]

Sounds great to me :D, I'm happy to assist if needed!

You can check out my proposal here: #16618
Confirmed working as expected with GPT-OSS-20B/120B and MoE-Qwen3-30B-A3B-Thinking/Instruct-2507

JSON for "Custom JSON parameters to send to the API. Must be valid JSON format." Option :

{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "simple_addition_tool",
        "description": "A dummy calculator tool used for testing multi-argument tool call streaming.",
        "parameters": {
          "type": "object",
          "properties": {
            "a": {
              "type": "number",
              "description": "The first number to add."
            },
            "b": {
              "type": "number",
              "description": "The second number to add."
            }
          },
          "required": ["a", "b"]
        }
      }
    }
  ]
}

[ServeurpersoCom]

Demo video :

ToolCallDebug-AVC750kbps.mp4

Resulting WebUI JSON :

conversation_767b7ab3-107e-4e09-8ad8-a7691e900892_hello_my_llm_.json

[ServeurpersoCom]

In this video, I’m letting GPT-OSS-120B surf freely: no special prompts, just a few explicit tool names and pure intuition.
If I had this debug option in the Svelte WebUI, I’d have saved a ton of time with all those curl -N tests (I was dumping the proxy to a JSONL file anyway, which is pretty much the same thing just JSON chunks)...

GPT-OSS-120B-Surf-AVC500kbps.mp4

[twoxfh]

In this video, I’m letting GPT-OSS-120B surf freely: no special prompts, just a few explicit tool names and pure intuition. If I had this debug option in the Svelte WebUI, I’d have saved a ton of time with all those curl -N tests (I was dumping the proxy to a JSONL file anyway, which is pretty much the same thing just JSON chunks)...
GPT-OSS-120B-Surf-AVC500kbps.mp4

@ServeurpersoCom Is there documentation or docker container to reproduce this setup? Trying to test #16618. Thanks!

[ServeurpersoCom]

@ServeurpersoCom Is there documentation or docker container to reproduce this setup? Trying to test #16618. Thanks!

I haven’t published the browser RAG system: it’s a unique prototype running only on my development server. However, this PR can already be tested: the model sends its toolcall chunks, and the WebUI now displays them properly.
Once the debug tools proposed here (and some upcoming llama.cpp refactoring) are merged, reproducing the full setup will become much easier.