Below is a current example:
[root@ai-app-0l apps]# curl http://IP:8001/v1/chat/completions
-H "Content-Type: application/json"
-H "Authorization: Bearer <your_token>"
-d '{
  "model": "qwen3.6-35b-a3b",
  "messages": [
    {"role": "user", "content": "What's the weather like in Beijing today?"}
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "Get the current weather for the specified city",
        "parameters": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name, e.g., Beijing, Shanghai"
            }
          },
          "required": ["location"]
        }
      }
    }
  ]
}'

Response:

{
  "id": "chatcmpl-a914ca7d228bc903",
  "object": "chat.completion",
  "created": 1779196243,
  "model": "qwen3.6-35b-a3b",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "\n\n<tool_call>\n<function=get_weather>\n<parameter=location>\nBeijing\n</parameter>\n</function>\n</tool_call>",
        "refusal": null,
        "annotations": null,
        "audio": null,
        "function_call": null,
        "tool_calls": [],
        "reasoning": "Here's a thinking process:\n\n1. **Analyze User Input:**\n - User asks: \"What's the weather like in Beijing today?\"\n - Key entity: Beijing\n - Request: Current weather\n\n2. **Identify Available Tools:**\n - I have one tool: 'get_weather'\n - Tool description: Get the current weather for a specified city\n - Parameters: 'location' (string, required) - City name, e.g., Beijing, Shanghai\n\n3. **Map User Input to Tool Parameters:**\n - 'location' should be \"Beijing\"\n\n4. **Execute Tool Call:**\n - Call 'get_weather' with 'location: \"Beijing\"'\n\n5. **Process Tool Response (Simulation/Expectation):**\n - Since I don't have real-time access, I'll simulate the tool call and assume it returns a reasonable weather response. However, in this environment, I will actually make the tool call and let the system handle it. I'll generate the tool call now.\n\n Tool Call:\n```json\n{\n  \"name\": \"get_weather\",\n  \"parameters\": {\n    \"location\": \"Beijing\"\n  }\n}\n```\n\n6. **Formulate Response:**\n After receiving the tool response, I will present the weather information clearly to the user in Chinese.\n - For now, I'll just make the tool call."
      },
      "logprobs": null,
      "finish_reason": "stop",
      "stop_reason": null,
      "token_ids": null
    }
  ],
  "service_tier": null,
  "system_fingerprint": null,
  "usage": {
    "prompt_tokens": 284,
    "total_tokens": 656,
    "completion_tokens": 372,
    "prompt_tokens_details": null
  },
  "prompt_logprobs": null,
  "prompt_token_ids": null,
  "ky_transfer_params": null
}

The "XML tool call" output is what Qwen models emit at the raw model layer. Almost all production inference servers convert that into standard OpenAI JSON tool_calls before returning the response — so Qwen normally works fine with NetXMS if the inference server is configured to parse tool calls. For example:

• Ollama — works out of the box for Qwen models that ship with a tool-call template in their Modelfile. Point NetXMS at the Ollama provider and it will receive normal JSON tool_calls.
• vLLM — requires starting the server with --enable-auto-tool-choice --tool-call-parser hermes (or qwen3_coder for the newer parser). Then the OpenAI-compatible endpoint returns JSON tool_calls.
• SGLang / llama.cpp server — similar flags exist.