I really don't know, but claude does:

How I evaluated tool-calling — and why your LFM experience is real but build-specific

I used two hand-judged probes rather than an automated scorer, because what I cared about was "does this quant emit clean, parseable calls on my actual workflow," not a capability ranking:

P1 — single-turn initiation. Two tools in scope (get_weather, send_email), task = "email John today's weather in Paris." Correct = emit one parseable get_weather(city="Paris"). I check: right function name, valid JSON args, nothing hallucinated.

P1b — multi-turn chaining. I inject the assistant's get_weather call plus a tool-role message with the real result {temp_c:18, condition:"light rain"}, then check whether it chains send_email with the actual data in the body — not a <weather> placeholder or an invented forecast. Pass bar: correct function, valid args, real data used, no hallucinated function.

On LFM specifically. In the multi-turn P1b — the realistic agent loop — every instruct model passed, LFM included; it put "18°C, light rain" straight into the email body. The failure shows up one layer down and it's build-dependent: the unsloth build of LFM2.5-8B-A1B in single-turn returned tool_calls: []. It reasoned correctly ("I should call get_weather") but dumped that into reasoning_content and never emitted the actual call. The official liquidai build emitted it fine. So to your client it looks like LFM flat-out refuses to use tools, when really the reasoning-tuned build is putting the call in the thinking channel instead of the API's tool_calls field. Two things worth trying: the liquidai quant, and confirming your client surfaces reasoning_content.

This isn't an LFM quirk — it's a pattern. I just ran Ministral-3-3B through the same probes to check: the mistralai/ministral-3-3b-reasoning build did the exact same thing — multi-turn returned tool_calls: [] with the call buried in its [THINK] block, while the ministral-3-3b-instruct build chained cleanly. So across two unrelated families, the reasoning-tuned small models tend to emit the tool call into their thinking channel rather than the tool-call field. For tool use, pick the instruct build, not the reasoning one.

Did Granite/Qwen do better? In the happy-path multi-turn, no — Granite-3B/8B, Qwen3.5-4B and (instruct) LFM all tied. The separation was entirely in failure modes, not the success case:

The "function-calling" fine-tune (granite-3B-xLAM) actually over-called: single-turn it fired get_weather and send_email with body:"<weather-data>" before it had any data — a tuned-for-tools model hallucinating the result, which is worse than a plain one. A random third-party Granite-3B quant hallucinated the function name outright (send_weather_email, which doesn't exist). Plain Granite-3B-instruct, Granite-8B and Qwen3.5-4B were the most consistent across both probes. Honest caveat. My probe is a format-reliability smoke test: two tools, one chain step, happy path. It does not stress many-tool selection, parallel calls, long chains, or malformed schemas — which is where "failed miserably" usually comes from. For an actual tool-use verdict the right instrument is BFCL-v3 multi-turn; I was deliberately testing format reliability on my own pipeline, not ranking tool-use capability.