MCP tool calls not executed in UI chat (stops after thinking phase)

[xian-zh]

Bug Description

When using MCP tools in the UI chat, the conversation stops after the
thinking phase without actually executing the tool call.

Environment

• oMLX version: 0.3.1
• Model: Qwen3.5-35B-A3B-oQ3e
• MCP Server: brave-search (2 tools available)
• OS: macOS (Apple Silicon)

Steps to Reproduce

1. Configure MCP server in ~/.omlx/mcp.json
2. Start oMLX service
3. Open UI chat
4. Send a message requiring tool use (e.g. "请使用搜索工具查询北京今天天气")

Expected Behavior

1. Model generates tool_calls ✅
2. UI executes the MCP tool call
3. Tool result is passed back to model
4. Model generates final answer based on real search results

Actual Behavior

1. Model generates tool_calls ✅
2. UI stops after thinking phase ❌
3. No tool is executed
4. No final answer generated

Evidence

MCP connects successfully at startup:
Connected to MCP server 'brave-search' (2 tools available)
MCP manager started: 1/1 servers, 2 tools available
MCP initialized with 2 tools
GrammarCompiler initialized

API call works correctly and returns proper tool_calls:

{
  "choices": [{
    "message": {
      "tool_calls": [{
        "function": {
          "name": "brave_search__brave_web_search",
          "arguments": "{\"query\": \"北京今天天气\", \"count\": 5}"
        }
      }]
    },
    "finish_reason": "tool_calls"
  }]
}

But UI shows only the thinking content and stops,
no tool execution happens, no final response generated.
##Logs
No logs are generated in server.log when the UI stops after thinking.
The server.log only updates during initial startup and model loading.

[Skjz]

Same problem, same model, but it doesn't only happen in the UI chat — the MCP also cannot be called properly in Claude Code

[rkhozinov-wakecap]

Root Cause & Fix

I hit the same issue with Claude Code + Qwen3.5-35B-A3B via the Anthropic Messages API (/v1/messages).

Root cause: When tool calls are successfully parsed into tool_use content blocks, the raw tool call markup (e.g. <tool_call><function=write>...</tool_call> for qwen3_coder format) is still included as a text content block in the response. Clients like Claude Code see both text and tool_use blocks, process the text first, and get confused/stuck.

Example broken response:

{
  "content": [
    {"type": "text", "text": "<tool_call>\n<function=write>\n<parameter=file_path>\ntest.txt\n</parameter>..."},
    {"type": "tool_use", "id": "call_xxx", "name": "write", "input": {"file_path": "test.txt", "content": "hello"}}
  ]
}

Expected (after fix):

{
  "content": [
    {"type": "tool_use", "id": "call_xxx", "name": "write", "input": {"file_path": "test.txt", "content": "hello"}}
  ]
}

Fix in server.py — strip <tool_call> markup when tool_use blocks are present. Two locations need patching:

1. Non-streaming Messages API (~line 3217, before convert_internal_to_anthropic_response):

    # When tool calls are present, strip leftover tool call markup from text
    final_text = cleaned_text.strip() if cleaned_text else regular_content
    if tool_calls and final_text:
        import re
        stripped = re.sub(r'<tool_call>.*?</tool_call>', '', final_text, flags=re.DOTALL).strip()
        if not stripped:
            final_text = None
        else:
            final_text = stripped

2. Non-streaming Chat Completions API (~line 2064, before ChatCompletionResponse):
   Same pattern — strip <tool_call> from cleaned_text when tool_calls is non-empty.

Environment: oMLX 0.3.1, Qwen3.5-35B-A3B-6bit, Claude Code 2.1.84 via ANTHROPIC_BASE_URL=http://localhost:8790

After patching, Claude Code works perfectly — creates files, multi-turn tool calling, no stalling.