---
schema: 1
type: term
title: _function/tool calling_
description: >-
  **Function/tool calling** is when an AI model, instead of only generating
  text, invokes an external capability — such as a code interpreter — and
  incorporates its result into its response. In this material, the canonical
  example is a custom GPT rolling a **dice via the code interpreter** to
  introduce genuine randomness the model's own outputs couldn't supply.
  [^01a0f15b-3407-78e4-9a1c-de04fa55d0bf@5912]
canonical: >-
  https://liquidgold.cc/channel/everyinc/explore/term/function-tool-calling-ad138cd38fe6
markdown: >-
  https://liquidgold.cc/channel/everyinc/explore/term/function-tool-calling-ad138cd38fe6.md
llms: null
parent: 'https://liquidgold.cc/channel/everyinc/llms.txt'
channel: everyinc
updated: '2026-10-23T22:12:35.346Z'
language: null
children: []
---


# \_function/tool calling\_

Canonical: https://liquidgold.cc/channel/everyinc/explore/term/function-tool-calling-ad138cd38fe6

Parent: [Channel index](https://liquidgold.cc/channel/everyinc/llms.txt)

## Definition

**Function/tool calling** is when an AI model, instead of only generating text, invokes an external capability — such as a code interpreter — and incorporates its result into its response. In this material, the canonical example is a custom GPT rolling a **dice via the code interpreter** to introduce genuine randomness the model's own outputs couldn't supply. [^01a0f15b-3407-78e4-9a1c-de04fa55d0bf@5912]

## Why it matters in this material _Function/tool calling_ appears in this channel's material as the mechanism that lets a model reach **outside plain text generation** and invoke a capability — most concretely, the **code interpreter** that runs inside a custom GPT. ## How it shows up During the live custom-GPT build with OpenAI's Logan Kilpatrick, playtesting revealed a design gap: the game model was _always positive_, so the builders needed real stakes. The fix was to have the model call a tool — rolling a **dice via the code interpreter** — to introduce randomness into the scenario. [^01a0f15b-3407-78e4-9a1c-de04fa55d0bf@5912] That example captures the pattern worth understanding: **tool calling turns a limitation of the prompt itself into a solved problem**. Rather than trying to word a prompt so the model behaves randomly, you give it a tool whose output is genuinely random, and the model incorporates that result into its response. <Section title=“What to take from this”> - A custom GPT is _still inherently ChatGPT_ — no new raw capability — but tools like the code interpreter extend what a well-crafted prompt alone can achieve. [^01a0f15b-3407-78e4-9a1c-de04fa55d0bf@1058] - **Reach for a tool when the prompt can't produce the property you need**: randomness, computation, or verified data are classic candidates. - In the playtest-and-revise loop, a missing behavior (always-positive outcomes) was diagnosed through play and then fixed by adding a tool call — the eval loop told them _what_ the tool was for. [^01a0f15b-3407-78e4-9a1c-de04fa55d0bf@4807] </Section> <KeyPoints> - **Function/tool calling = the model invoking an external capability**, such as the code interpreter, instead of relying purely on generated text. [^01a0f15b-3407-78e4-9a1c-de04fa55d0bf@5912] - In the captured build, a **dice roll via the code interpreter** added stakes the model's own outputs couldn't provide. - Use the playtest loop to discover **when** a tool call is needed, then wire it in. </KeyPoints>