Jump to content

Connect SuperML | Leeroopedia MCP: Equip your AI agents with best practices, code verification, and debugging knowledge. Powered by Leeroo — building Organizational Superintelligence. Contact us at founders@leeroo.com.

Workflow:Openai Openai node Function Calling

From Leeroopedia
Knowledge Sources
Domains LLMs, Tool_Use, API_Integration
Last Updated 2026-02-15 12:00 GMT

Overview

End-to-end process for enabling language models to call application-defined functions (tools), with the SDK handling the multi-turn conversation loop automatically.

Description

This workflow enables a language model to interact with external systems by calling functions that you define. You describe available tools (with their parameters as JSON Schema), the model decides when and which tools to call, and your application executes the actual functions and returns results to the model. The SDK provides two approaches: a manual loop where you check for tool calls and dispatch them yourself, and the higher-level runTools() helper that automates the entire conversation loop. With runTools(), you register tool functions alongside Zod parameter schemas, and the SDK handles calling them, feeding results back, and continuing the conversation until the model produces a final text response. Both Chat Completions and Responses APIs support tool calling, with Zod integration for type-safe parameter parsing.

Usage

Execute this workflow when you want the language model to perform actions or retrieve information from external systems during a conversation. Common use cases include database queries, API calls, calculations, file operations, and any scenario where the model needs to interact with your application's capabilities. Use the manual loop for full control over tool execution, or runTools() / zodFunction() helpers for automated, type-safe tool dispatch.

Execution Steps

Step 1: Tool Definition

Define the tools (functions) available to the model. Each tool has a name, description, and a JSON Schema describing its parameters. With the Zod integration, you define parameters as Zod schemas and register the actual implementation function alongside the schema.

Key considerations:

  • Each tool needs a name, description, and parameters schema
  • Use zodFunction() helper to combine a Zod schema with its implementation function
  • For the Responses API, use zodResponsesFunction() instead
  • Provide clear descriptions so the model knows when to use each tool
  • Parameters are automatically validated against the schema before execution

Step 2: Initial Request

Send the initial user message along with the tool definitions to the model. The model analyzes the user's request and decides whether to respond directly or invoke one or more tools.

Key considerations:

  • Include system/developer messages to set context about available tools
  • The model may call zero, one, or multiple tools in a single response
  • With runTools(), the initial request and all subsequent turns are managed automatically

Step 3: Tool Execution Loop

When the model requests a tool call, execute the corresponding function with the provided arguments and return the result. This loop continues until the model produces a final text response without requesting more tool calls.

Manual loop:

  • Check message.tool_calls (or legacy message.function_call) for pending calls
  • Parse arguments, execute the function, and append results as tool/function role messages
  • Send the updated conversation back to the model
  • Repeat until no more tool calls are requested

Automated loop (runTools):

  • The SDK dispatches tool calls to your registered functions automatically
  • Results are fed back to the model without manual intervention
  • Events are emitted for each tool call and result
  • The loop terminates when the model produces a final text response

Step 4: Final Response

Extract the model's final text response after all tool interactions are complete. With runTools(), call .finalChatCompletion() to get the complete result. In manual mode, the loop ends when message.tool_calls is empty and the message has content.

Key considerations:

  • The final response incorporates information gathered from tool calls
  • Access the full message history via runner.messages for logging
  • Events like finalFunctionToolCall and content are available for monitoring

Execution Diagram

GitHub URL

Workflow Repository