Toolformer learned tool calls before APIs standardised them

Self-supervised tool use in the research paper

The Toolformer paper, submitted in February 2023, addresses a specific gap: large language models are strong at few-shot text tasks but unreliable at things like arithmetic or looking up current facts. Its method has a model generate candidate calls to external tools, such as a calculator, a question-answering system, search engines, a translator or a calendar, insert the call and its result into example texts, and keep only the insertions that measurably reduce the model's loss on the following tokens. Training on this self-filtered data, the paper states, requires nothing more than a handful of human-written demonstrations per tool, rather than large-scale annotation.

What the paper reported

The paper reports that the resulting model showed substantially improved zero-shot performance across the tasks it tested, in several cases competitive with larger models that had no tool access, while stating this did not come at the cost of the model's core language-modelling ability. These results describe the specific tools and tasks the paper built and tested; the method decides whether to call a tool and with what arguments, but does not itself guarantee the tool's output is correct, only that using it reduced loss on the paper's own held-out text.

What the API standardised, and what it still requires

Separately, OpenAI's announcement, whose text refers to the gpt-4-0613 model as introduced the month before a July 2023 update notice was appended to it, describes a Chat Completions API feature, released with the gpt-4-0613 and gpt-3.5-turbo-0613 model snapshots, in which a developer supplies function definitions and the model returns a structured JSON object naming a function and its arguments rather than free text. The current developer guide, describing the feature as retrieved on 16 September 2026, is explicit that the model does not execute the function itself: the calling application must run the named function with the supplied arguments and return the result to the model in a further turn. Toolformer's contribution was a training method for deciding when and how to call a tool from within the model's own weights; the function-calling API is a separate, later interface convention for the surrounding application to parse that decision reliably, and neither removes the need for the calling code to validate what the tool actually returns.

• Does the deployed system validate a tool's output before acting on it, or trust the model's call unconditionally?
• Is the model deciding to call a tool based on training like Toolformer's, or only responding to a fixed schema it was prompted with?
• What happens in the application when the model requests a function that does not exist or supplies malformed arguments?

A model proposing a well-formed tool call is a necessary step, documented separately by the research paper and the vendor interface; it is not, by itself, a correctness or safety guarantee for what happens after the call executes.