GitHub Repo
LangChain Community Reports ChatOllama May Omit Tool Names, Causing Parallel Call Results to Lose Source Labels
A community reproduction posted October 6 suggests ChatOllama may omit the tool-name field used by Ollama when sending tool results. The report includes intercepted requests and prompt-rendering comparisons, but maintainers have not confirmed the issue and no fix has been merged.
On October 6, the LangChain community reported that ChatOllama in langchain-ollama may preserve tool-result values while losing the identity of the tool that produced them. The reported environment included langchain-ollama 1.1.0, Ollama Python SDK 0.6.3, and Ollama 0.35.1. The author says this can cause Gemma 4’s prompt rendering to label the source as unknown. Public report
The reproduction intercepts requests through a simulated HTTP transport, creates two tool calls for temperature and humidity, then sends results with names and call IDs. The intercepted tool messages contain only the role and content. The author’s analysis is that the conversion layer relies on an ID field that the SDK’s message structure does not preserve, while the supported tool_name field is left unset. A rendering comparison also shows that adding the name restores the source label. This demonstrates a serialization mismatch in the reported case; it does not quantify how often real agents give incorrect answers. Reproduction and analysis
The difference in semantics between the two interfaces is key. LangChain’s documentation says ToolMessage.tool_call_id links a call to its reply, which is especially useful for parallel tool calls. Ollama’s official examples explicitly set tool_name when returning results, including in single-call, parallel, and multi-turn agent flows. The engineering implication is that correct pairing inside the framework does not guarantee that the model receives the same information after conversion to the provider’s format. LangChain message definition, Ollama tool-calling documentation
For local agents, missing source labels could make results harder for the model to interpret when different tools return short numbers or similar text. Developers should inspect the requests actually sent and validate result attribution with multi-tool cases. The author proposes populating the field from the message name, then looking up prior calls by ID when no name is available. As of this check, the issue remains open and has no linked fix. Watch for maintainer confirmation, regression tests, and a release; this report should not be taken to mean that all models are affected. Issue status