Variable: llama3JsonToolCallParser

const llama3JsonToolCallParser: ToolCallParserFn;

Defined in: src/batteries/llm/chat_common/tool_parsers.ts:882

Parse bare top-level JSON tool call(s) — {"name":"x","parameters":{…}} (or "arguments"), optionally wrapped in a ```json … ``` fence (a common small-model emission — verified via the real-model matrix on Qwen2.5-Coder-0.5B). The weakest signal, so it is gated hard: after un-fencing, the output must be ONLY top-level JSON object(s) AND every callee must be a real tool (ctx.toolNames). Runs after every marker-anchored family in 'auto'.

Remarks

Parallel calls. Small Llama-family / Qwen-Coder models emit MULTIPLE calls as several top-level objects separated by , / ; / whitespace (verified on the real-model matrix: Llama-3.2-1B → {…}; {…}, Qwen2.5-Coder-0.5B → a fenced {…},\n{…}). So we string-aware brace-scan the (un-fenced) text into successive balanced {…} objects, accepting only the separators above between them — if any NON-separator prose sits between or around the objects, the whole thing declines (the hard whole-output gate, so this never false-positives on JSON embedded in a sentence).

Disambiguation, NOT authorization. This parser is marker-free, so it must distinguish a tool call from arbitrary JSON content. It does that STRUCTURALLY: whole-output-is-object(s) + each object has a string name. It deliberately does NOT check the callee against ctx.toolNames — whether a requested tool is allowed is the consumer's decision, not the parser's. An unknown-tool call is surfaced like any other; the dispatch layer already replies "Tool not found: … Available tools: …" so the model can self-correct. Silently dropping the call here would hide both the request and that feedback loop.