what is the exact reason why json is still being output, while the tool completed successful

[f1-outsourcing]

I have this output. The output is correct, yet I am still getting this json. When I click the green checkmark the output tab opens with just single word. I assume that is correct. I don't understand why I still see this json.

[omni-front]

It's hard to diagnose the issue without more information. Can you provide details on your current configuration? Specifically, it would be helpful to know:
The version of the Continue plugin you are using.
Any configurations related to output formatting in your ~/.continue/config.yaml.
Whether there are any error messages in the console or logs that might provide additional clues.

With this information, we can better troubleshoot why the JSON is still being output despite the successful completion.

[f1-outsourcing]

v1.3.38, I just also pulled new ollama update but I don't think this changes much. I can't remember seeing error messages in the console.

I have not much in the config, just models.

# https://docs.continue.dev/reference
# https://docs.continue.dev/reference#models
name: Local Config
version: 1.0.0
schema: v1
models:
  - name: Deepseek R1 14B
..
  - name: Deepseek Coder 33B
..
  - name: llama3.1
..
  - name: Nomic Embed
..
  - name: Qwen3-Coder 30B  (eight context)
    # context length 262144
    provider: ollama
    model: qwen3-coder:30b
    apiBase: http://192.168.3.11:11434
    contextLength: 32768
    roles:
      - chat
      - rerank
      - edit
      - apply
      - summarize
    capabilities:
      - tool_use
..
  - name: Deepseek ocr 3B
..
  - name: testing
context:
  - provider: file
  - provider: code
  - provider: diff
  - provider: currentFile
  - provider: terminal
  - provider: open
    params:
      #onlyPinned: true
  - provider: clipboard
  - provider: tree
  - provider: repo-map
    params:
      includeSignatures: false # default true

I have the impression that enabling the Built-In Tools maybe confuses the model. I have the impression that when I enable these Built-In Tools I get more errors of incorrectly accessing tools often I see my external mcp tools with an xml syntax.

tools_list failed because the arguments were invalid, with the following message: Tool tools_list not found

I am trying to counter this with rules like - Never use tool_call, <tool_call>, </tool_call>, <function=...>, <parameter=...>. You can sometimes see that this is applied because it omits the <tool_call> but strangely still lists <function=...> and </tool_call>

Can it be that the Built-In tools have a different command/access than regular mcp's? Maybe this confuses the model?

I am also wondering if I disable Built-In Tools it will hinder external mcp tool discovery? I have the impression I need to do more to describe the tool calling.

[f1-outsourcing]

every day occurrences:

tools/list failed because the arguments were invalid, with the following message: Tool tools/list not found
tools_list failed because the arguments were invalid, with the following message: Tool tools_list not found

fs_replace_in_file_lines failed with the message: MCP error -32603: content must be a string
qdrant_create_collection failed because the arguments were invalid, with the following message: Tool qdrant_create_collection not found
qdrant_store failed with the message: [{"type":"text","text":"1 validation error for call[qdrant_store]\nmetadata\n Input should be a valid dictionary [type=dict_type, input_value='{\"language\": \"php\", \"sym...er.php\", \"used\": false}', input_type=str]\n For further information visit https://errors.pydantic.dev/2.13/v/dict_type"}]

I am now more working on patching mcp servers that are more lenient in accepting hallucinated tool calls, creating aliases of existing tools, also accepting both numbers and strings etc