fix: handle tool call parse errors gracefully in server

[shanemmattner]

Problem

When a model produces tool call arguments with invalid JSON (e.g. raw regex like \d+, unescaped backslash paths), json.loads() in the tool parser raises JSONDecodeError. This exception is unhandled in parse_tools(), crashes the HTTP handler, and drops the client connection mid-response.

Affected parsers: json_tools.py, mistral.py, and any parser that calls json.loads() or raises ValueError on malformed input.

Fix

Wrap the ctx.tool_parser() call in parse_tools() with a try/except that catches JSONDecodeError, ValueError, and KeyError. On failure, the server logs a warning and skips the malformed tool call instead of crashing.

This is a 4-line change at the call site in server.py, so it covers all current and future tool parsers.

Reproduction

1. Run mlx_lm.server with a model that supports tool use (e.g. Qwen3-32B)
2. Send a prompt that causes the model to generate regex patterns in tool arguments
3. Server crashes with JSONDecodeError: Invalid \escape

Testing

Tested with Qwen3-32B-4bit across 4 prompt categories (regex-heavy, backslash paths, newline escapes, clean JSON) — all pass, server stays up, malformed tool calls are logged and skipped.

[shanemmattner]

Update: I was testing this on mlx-lm 0.25.0. After upgrading to 0.30.7, I see that some parsers (like glm47.py) now have fallback logic via ast.literal_eval().

However, json_tools.py and mistral.py still have bare json.loads() with no error handling. This PR provides a safety net at the call site that covers all parsers (current and future).

Tested on 0.30.7 — the server-level try/except still catches exceptions from parsers without fallbacks. Happy to close this if you'd prefer a different approach.

[awni]

Is there a way to send a response that the tool call did not parse properly rather than just logging it and silently continuing? Does the OpenAI API spec do anything in those cases?

Like it might be better to return a "tool call failed to parse" error so that it can be given as input to the model on the next request.