Jak GPT decyduje się wywołać narzędzie: model tool-call i rola opisów

1. Po co w ogóle rozumieć tool-call

Upraszczając: typowa aplikacja webowa żyje według schematu „użytkownik kliknął przycisk – my wywołaliśmy funkcję”. W świecie ChatGPT Apps wygląda to inaczej: użytkownik coś mówi, model rozważa i – jeśli uzna to za potrzebne – formuje ustrukturyzowane wywołanie narzędzia (tool-call).

Czyli nie piszesz:

onClick={() => callSuggestGiftsApi(formData)}

a zamiast tego:

1. Opisujesz narzędzie suggest_gifts (nazwa, opis, schemat argumentów).
2. Wyjaśniasz modelowi w system-prompt, do czego to narzędzie służy.
3. Oddajesz sterowanie modelowi: sam decyduje, kiedy i jak je wywołać.

Stąd bardzo ważne, by wcześnie zrozumieć dwie rzeczy:

1. GPT nie widzi twojego kodu backendu. Widzi tylko „nagłówek” narzędzia: nazwę, opis i schemat parametrów.
2. To, jak „mądrze” model będzie używać twojej aplikacji, niemal bezpośrednio zależy od tego, jak napiszesz te opisy. Dobre opisy to twój „prompt dla narzędzia”.

Dzisiejsza lekcja jest właśnie o tym „mózgu” pomiędzy użytkownikiem a twoim serwerem.

2. Model mentalny tool-call: co właściwie się dzieje

Zacznijmy od całościowego obrazu. Typowy scenariusz dla GiftGenius:

1. Użytkownik: „Dobierz prezent dla przyjaciela, 30 lat, budżet 100 dolarów, lubi gry wideo”.
2. GPT czyta tę wiadomość i sprawdza, jakie narzędzia są dostępne. W naszej aplikacji, na przykład, jest suggest_gifts.
3. GPT decyduje: „Aby dobrze odpowiedzieć, muszę wywołać to narzędzie”.
4. Zamiast zwykłej odpowiedzi tekstowej generuje strukturę: nazwa narzędzia + argumenty JSON.
5. Klient ChatGPT widzi: „Aha, to tool-call”, wysyła go do twojego MCP/serwera.
6. Twój serwer wykonuje logikę biznesową i zwraca wynik w formie strukturalnej.
7. GPT otrzymuje rezultat, czyta go i na jego podstawie formuje zrozumiałą odpowiedź dla użytkownika i/lub aktualizuje widżet.

Z punktu widzenia OpenAI API to ten sam mechanizm LLM-function-calling: w odpowiedzi modelu zamiast zwykłego tekstu pojawia się obiekt z name narzędzia i arguments, a finish_reason ma wartość tool_calls. Model sam nie uruchamia kodu – jedynie proponuje, które narzędzie wywołać, a rzeczywiste wywołanie wykonuje klient (ChatGPT/Apps SDK).

Wygląda to mniej więcej tak (uproszczona sekwencja):

sequenceDiagram
    participant U as Użytkownik
    participant G as GPT (model)
    participant C as klient ChatGPT
    participant S as Twój MCP/Backend

    U->>G: "Dobierz prezent dla przyjaciela..."
    G->>C: tool-call: { name: "suggest_gifts", args: {...} }
    C->>S: HTTP /mcp tools/call (suggest_gifts, args)
    S-->>C: Wynik (JSON z listą prezentów)
    C-->>G: wynik narzędzia
    G-->>U: Odpowiedź + zaktualizowany widżet

Główny wniosek: nie piszesz if (userAskedAboutGifts) callSuggestGifts(). Tworzysz narzędzie i jego opis, a decyzję podejmuje model.

3. Co widzi model: System Prompt + lista narzędzi

Aby zrozumieć, jak GPT decyduje, co zrobić, trzeba jasno wiedzieć, jakimi danymi dysponuje w momencie wyboru.

W uproszczeniu model widzi:

• system prompt twojej aplikacji (omówimy szczegółowo w module 5);
• historię dialogu: wiadomości użytkownika, własne odpowiedzi, wyniki poprzednich tool-callów;
• listę dostępnych narzędzi (tools) z ich nazwami, opisami i schematami parametrów;
• dodatkowe adnotacje narzędzi (readOnly/destructive itd.).

Nie widzi natomiast:

• implementacji funkcji;
• zapytań SQL;
• struktury twoich tabel;
• zawartości prywatnego repozytorium z serwisem.

Nieco później szczegółowo porozmawiamy o MCP. Na razie wystarczy wiedzieć, że na poziomie MCP narzędzia deklaruje się jako deskryptory: każde ma name, description i inputSchema (JSON Schema). Podczas handshake klient ChatGPT pobiera od serwera MCP listę narzędzi i zaczyna postrzegać je jako dostępne „akcje”.

Przykład takiego deskryptora dla GiftGenius (uproszczony JSON):

{
  "name": "suggest_gifts",
  "description": "Dobiera pomysły na prezenty według wieku, zainteresowań i budżetu",
  "inputSchema": {
    "type": "object",
    "properties": {
      "age": { "type": "integer" },
      "budget": { "type": "number" }
    },
    "required": ["age", "budget"]
  }
}

Model „czyta” tutaj tylko tekst i strukturę: czym jest age, czym jest budget, co ogólnie robi narzędzie. Następna lekcja będzie właśnie o tym, jak sensownie opisywać inputSchema. Teraz – o tym, jak z tego opisu rodzi się decyzja „a więc wywołam suggest_gifts”.

4. Jak wygląda tool-call od strony API

ChatGPT wywołuje narzędzia (tools) twojego serwera MCP mniej więcej tak samo, jak OpenAI Agent wywołuje funkcje w twoim backendzie. W ChatGPT Apps SDK wszystko jest trochę bardziej „opakowane”, ale podstawowa mechanika jest identyczna.

Wyobraźmy sobie, że w naszym backendzie wykonujemy zwykłe żądanie do OpenAI API i przekazujemy narzędzie suggest_gifts, które model może wywołać w swojej odpowiedzi:

const response = await openai.responses.create({
  model: 'gpt-5-mini',
  messages: [
    {
      role: 'user',
      content: 'Potrzebny prezent dla przyjaciela, 30 lat, budżet 100 dolarów'
    }
  ],
  tools: [ // tutaj przekazujemy listę funkcji, które LLM może "wywołać"
    {
      name: 'suggest_gifts',
      description: 'Dobiera prezenty według wieku, budżetu i zainteresowań',
      parameters: {
        type: 'object',
        properties: {
          age: { type: 'integer' },
          budget: { type: 'number' }
        },
        required: ['age', 'budget']
      }
    }
  ]
});

Jeśli model zdecyduje się wywołać narzędzie, w odpowiedzi dostaniesz nie tekst, lecz wiadomość asystenta z czymś w rodzaju:

{
  "role": "assistant",
  "tool_calls": [
    {
      "id": "call_1",
      "name": "suggest_gifts",
      "arguments": "{\"age\":30,\"budget\":100}"
    }
  ],
  "content": []
}

W ten sposób LLM mówi twojemu backendowi, że trzeba wywołać funkcję suggest_gifts(30,100).

Ważne są tu trzy rzeczy:

1. Nazwa narzędzia (name) – model naprawdę podstawia tu ten ciąg znaków, który podałeś w opisie tools przy pierwszym żądaniu.
2. Argumenty (arguments) – łańcuch JSON zbudowany na podstawie parameters/inputSchema.
3. Brak zwykłej odpowiedzi tekstowej (na razie) – zamiast niej dostajesz strukturę do wywołania narzędzia.

W aplikacjach ChatGPT wygląda to tak samo: model zwraca „chcę wywołać suggest_gifts z takimi parametrami”, a klient (ChatGPT) wykonuje żądanie HTTP do twojego MCP/serwera: tools/call z nazwą narzędzia i argumentami.

5. Jak dokładnie model decyduje: narzędzie czy tekst

Kiedy GPT w ogóle pamięta o twoich narzędziach?

Mechanika w uproszczeniu jest taka:

1. Model widzi kolejną wiadomość użytkownika i bieżący kontekst.
2. W środku ma „warstwę”, która generuje następną wiadomość asystenta, ale zamiast zawsze zwracać zwykły tekst model może wybrać jedną z opcji zakończenia:
   • zwykłą odpowiedź tekstową (finish_reason: "stop");
   • jedno lub kilka tool-callów (finish_reason: "tool_calls");
   • czasem inne warianty (np. „potrzebna jest jeszcze wiadomość użytkownika”).
3. Na ten wybór wpływa:
   • na ile prośba użytkownika przypomina zadania opisane w twoich narzędziach;
   • na ile opis narzędzia jasno mówi „użyj mnie właśnie w takim przypadku”;
   • dane z app system prompt, które w Apps SDK są ustawiane w konfiguracji.

Mówiąc po ludzku: model „przymierza” twoje narzędzie do bieżącej prośby. Jeśli opis brzmi: „Dobiera prezenty według wieku i zainteresowań”, a użytkownik prosi o „analizę budżetu państwa”, model nawet nie spróbuje go wywołać. Jeśli opis jest zbyt rozmyty – „robi fajne rzeczy” – model nie zrozumie, przy jakich prośbach w ogóle warto go używać.

Ciekawostka: model nie ma obowiązku wywołać narzędzia, nawet jeśli je opisałeś. GPT może uznać: „Tu wszystko jest jasne, odpowiem sam, bez tool-calla”. Dlatego dalej w kursie będziemy się aktywnie ćwiczyć w pisaniu takich opisów narzędzi, które sprawiają, że użycie narzędzia jest dla modelu maksymalnie oczywiste i opłacalne.

6. Nazwa narzędzia: dlaczego tool1 to zły pomysł

Nazwa narzędzia to w istocie identyfikator, którego model będzie używał w swoich wywołaniach. Wydawałoby się, że to czysto techniczne pole, ale w praktyce nazwa mocno wpływa na zachowanie modelu.

Jeśli nazwiesz narzędzie tool1, model nic z tego nie zrozumie. To dla niego po prostu ciąg znaków. Jeśli nazwiesz je suggest_gifts, search_products albo fetch_user_orders, sama nazwa daje silny sygnał, o co chodzi w narzędziu.

Pomyśl, jak sam czytasz obcy kod. Widząc funkcję calculateCartTotal, mniej więcej wiesz, czego się po niej spodziewać. Model potrzebuje takiego samego „kotwicznego znaczenia”.

Dla GiftGenius sensowne nazwy narzędzi to:

suggest_gifts
search_products
get_product_details
create_order

Dobrze, jeśli nazwa jest:

• krótka, ale treściwa;
• w jednolitym stylu (snake_case, łacina, czasownik_rzeczownik);
• odzwierciedla jedno konkretne działanie.

Złym pomysłem jest mieszanie różnych działań w jednym narzędziu, np. do_all_gift_stuff. Modelowi trudniej zrozumieć, kiedy go użyć, a w kolejnych lekcjach zobaczymy, jak to psuje schemat argumentów i utrudnia debugowanie.

7. Opis narzędzia: twój prompt dla modelu

Jeśli nazwa to nagłówek, to description jest mini‑dokumentacją, ale nie dla człowieka‑programisty, tylko właśnie dla GPT. Programista przeczyta kod; model – nie. Opiera się na tekście opisu przy wyborze, kiedy wywołać narzędzie i jakie argumenty tam wstawić.

Ważne, by pisać opis w stylu „instrukcji zastosowania”:

• kiedy używać narzędzia;
• jakie ma ograniczenia;
• czego nie powinno robić.

Weźmy nasze suggest_gifts. Oto trzy warianty opisów.

Zbyt szeroki:

"Dobiera prezenty."

Model nie zrozumie, przy jakiej okazji, dla kogo, z jakimi parametrami. Takie narzędzie może „konkurować” w głowie modelu z jego ogólną wiedzą o prezentach i często zdecyduje się odpowiedzieć po prostu tekstem.

Zbyt wąski:

"Dobiera prezenty tylko dla młodszych braci na urodziny."

Tu de facto zabroniliśmy używać narzędzia prawie zawsze. Każdy inny scenariusz – mama, kolega, rocznica – już „nie pasuje” i model będzie unikał wywołania.

Optymalny:

"Używaj tego narzędzia, gdy trzeba dobrać prezenty dla osoby na podstawie wieku, typu relacji (przyjaciel, partner, kolega itp.), budżetu i zainteresowań.
Nie wywołuj go w pytaniach niezwiązanych z prezentami (np. polityka lub pogoda)."

Tutaj jasno opisano, co robi narzędzie, jakie są do tego parametry i kiedy je wywoływać, a także dodano warunek negatywny – dla jakich zapytań lepiej go nie dotykać.

Model „lubi” takie wyraźne ramy. Im jaśniej wskażesz, przy jakich sformułowaniach użytkownika (intencjach) narzędzie jest właściwe, tym bardziej przewidywalne będzie zachowanie aplikacji.

Mini‑ćwiczenie

Możesz teraz, nie odchodząc od monitora, wziąć swoją przyszłą aplikację (być może nie o prezentach) i wymyślić dla jednego z jej narzędzi trzy opisy: bardzo szeroki, bardzo wąski i zbalansowany. Następnie przetestuj, jak GPT zachowuje się z różnymi wersjami.

8. Schemat argumentów: jak pomaga w podjęciu decyzji

Szczegółowo o JSON Schema będziemy mówić w następnej lekcji, ale dla zrozumienia tool-callów ważne jest choćby ogólne przeczucie.

Kiedy model decyduje się wywołać narzędzie, musi:

1. Zrozumieć, jakich argumentów to narzędzie w ogóle oczekuje.
2. Wydobyć te wartości z tekstu użytkownika (lub z kontekstu).
3. Uformować JSON z tymi argumentami.

Dla tego celu w opisie narzędzia jest schemat parametrów (inputSchema), który mówi modelowi:

• jakie są pola (age, budget, relationship_type, interests itd.);
• które pola są obowiązkowe (required);
• jakie są typy (integer, number, string, tablice itd.);
• czasem – jakie wartości są dopuszczalne (enum) oraz objaśnienia pól (description).

Najprostszy interfejs TypeScript dla parametrów suggest_gifts może wyglądać tak:

interface SuggestGiftsParams {
  age: number;
  relationship_type: 'friend' | 'partner' | 'colleague';
  budget: number;
  interests?: string[];
}

Na poziomie modelu zamienia się to w JSON Schema, a model już po nazwie i opisie każdego pola domyśla się, że:

• age należy brać z fraz „30 lat”, „dla nastolatka” itp.;
• budget z „budżet 100 dolarów”, „do 50 euro”;
• relationship_type z „przyjaciel”, „kolega”;
• interests – z „lubi gry wideo”.

Jeśli podasz schemat bez opisów i z abstrakcyjnymi nazwami pól (a, b, c), model znacznie częściej będzie się mylił przy wypełnianiu argumentów. Wrócimy do tego w module o lokalizacji i podpowiedziach UX. Kluczowa myśl jest prosta: schemat to nie tylko walidacja na backendzie, to przede wszystkim podpowiedź dla modelu, co gdzie wstawić.

Omówiliśmy, jak schemat pomaga modelowi poprawnie złożyć argumenty. Ale poza „co i jak wywoływać” ważne jest jeszcze „czy wolno to wywołać właśnie teraz i jak bardzo to bezpieczne”. Tu do gry wchodzą uprawnienia i metainformacje o narzędziach.

9. Uprawnienia i kontekst: nie każde narzędzie jest zawsze dostępne

Poza nazwą, opisem i schematem argumentów narzędzia mają jeszcze jeden ważny wymiar – bezpieczeństwo i dostęp. Narzędzia w prawdziwej aplikacji mocno różnią się poziomem „ryzyka”. Co innego – szukanie prezentów w publicznym katalogu, co innego – obciążenie karty użytkownika.

Apps SDK i MCP pozwalają odzwierciedlić to w opisie narzędzi i adnotacjach – np. oznaczać je jako read-only albo destructive.

Idea jest taka:

• Narzędzia, które tylko czytają publiczne dane (search_products, get_weather), można wywoływać bez dodatkowych potwierdzeń.
• Narzędzia, które coś zmieniają (create_order, cancel_order, charge_user), oznacza się jako „destrukcyjne”. Interfejs ChatGPT może poprosić użytkownika o dodatkowe potwierdzenie („Czy na pewno chcesz złożyć zamówienie?”), a sam model będzie rzadziej je proponował bez wyraźnej prośby.

W przyszłych modułach, gdy będziemy konfigurować MCP, zobaczysz, jak te adnotacje (_meta, destructiveHint, readOnlyHint) wyglądają w rzeczywistych deskryptorach JSON, jak wpływają na UX i na to, jak ChatGPT formuje dialogi „Are you sure?” przed wywołaniem. Teraz wystarczy zrozumieć:

• GPT uwzględnia nie tylko tekst opisu, ale także metainformacje o bezpieczeństwie.
• Narzędzie wymagające uwierzytelnienia nie będzie używane, dopóki użytkownik nie będzie zalogowany (albo dopóki aplikacja nie otrzyma potrzebnego tokenu).

To jeszcze jeden czynnik wpływający na decyzję „uruchomić narzędzie czy nie”: nawet jeśli z sensem narzędzie pasuje, może być niedostępne ze względu na uprawnienia i model wybierze inną drogę.

10. Skąd w ogóle biorą się narzędzia w ChatGPT

Z punktu widzenia architektury narzędzie może trafić do modelu dwoma głównymi ścieżkami.

Po pierwsze, z konfiguracji twojej aplikacji ChatGPT. Gdy rejestrujesz aplikację, wskazujesz, które serwery MCP (i ich narzędzia) są do niej podłączone lub jakie wbudowane tools ma sama aplikacja. Przy starcie sesji ChatGPT pobiera tę konfigurację i wie, jakie narzędzia są w ogóle dostępne.

Po drugie, bezpośrednio z MCP. MCP (Model Context Protocol) definiuje standardowy sposób, w jaki klient (w naszym przypadku ChatGPT/Apps SDK) dowiaduje się, co potrafi twój serwer: wykonuje żądanie tools/list, otrzymuje JSON z opisami narzędzi i przechowuje je jako capabilities. Szczegóły omówimy w osobnym module o MCP, teraz ważne jest tylko zrozumienie ogólnej idei.

Schematycznie:

flowchart LR
  A[ChatGPT Client] -->|handshake| B[MCP Server]
  B -->|tools/list| A
  A -->|przekazuje listę| G[GPT Model]

Po tym lista narzędzi staje się częścią kontekstu dla modelu. Jeśli zmienisz schemat lub opis narzędzia na serwerze i zrestartujesz aplikację, nowy deskryptor trafi do ChatGPT przy następnym handshake’u i model zacznie podejmować nowe decyzje o wywołaniu.

I ważna praktyczna myśl: gdy zmieniasz tylko backend (implementację narzędzia), model o tym nie wie. Ale gdy zmieniasz name/description/schema, realnie zmieniasz „mózg” aplikacji. Czasem bardziej opłaca się poprawić jedną linijkę w description niż pisać 200 linii kodu z heurystykami.

11. Zastosowanie w GiftGenius: tworzymy narzędzie, które model będzie chciał wywoływać

Połączmy teraz wszystko z naszą aplikacją szkoleniową GiftGenius. Załóżmy, że mamy już serwer MCP albo warstwę backend, w której rejestrujemy narzędzia. Zarejestrujmy narzędzie suggest_gifts za pomocą server.registerTool(...).

Prosty szkic w TypeScript (na razie bez realnej logiki):

// pseudo-mcp-server/tools/suggestGifts.ts
server.registerTool(
  'suggest_gifts', //nazwa narzędzia
  {
    title: 'Dobór prezentów',
    description:
      'Używaj tego narzędzia, aby dobrać pomysły na prezenty według wieku, ' +
      'typu relacji i budżetu. Nie wywołuj go dla pytań niezwiązanych z prezentami.',
    inputSchema: { //opis parametrów narzędzia
      type: 'object',
      properties: {
        age: { type: 'integer', description: 'Wiek odbiorcy w latach' },
        relationship_type: {
          type: 'string',
          description: 'Typ relacji: friend, partner, colleague'
        },
        budget: {
          type: 'number',
          description: 'Maksymalny budżet na prezent w walucie użytkownika'
        }
      },
      required: ['age', 'budget']
    }
  },
  async ({ age, relationship_type, budget }) => { //kod funkcji/narzędzia
    // Rzeczywista logika będzie później
    return { suggestions: [] };
  }
);

Zwróć uwagę na detale, które przemyśleliśmy już na tym etapie, choć logika to na razie „zaślepka”:

• Nazwa: suggest_gifts, a nie tool1.
• Opis: wprost wyjaśnia, kiedy wywoływać narzędzie, a kiedy nie.
• Opisy pól: pomagają modelowi poprawnie zmapować tekst użytkownika na argumenty.

W efekcie, gdy użytkownik napisze „Dobierz prezent dla kolegi za 50 euro”, model zobaczy, że:

• istnieje narzędzie o nazwie suggest_gifts z opisem o doborze prezentów;
• ma ono pola age, relationship_type, budget;
• budget to „maksymalny budżet na prezent”, a relationship_type – „typ relacji: friend, partner, colleague”.

Nawet jeśli użytkownicy będą wyrażać się nieprecyzyjnie („do pięćdziesiątki”, „dla partnera w projekcie”), model będzie miał wystarczający kontekst, by spróbować poprawnie złożyć JSON z argumentami.

Gdy nasze narzędzie zacznie działać „naprawdę” (w module o backendzie i MCP), będziesz się już świetnie orientować w temacie: GPT będzie je wywoływać przewidywalnie, po prostu dlatego, że dobrze zaprojektowaliśmy interfejs i opis.

12. Mała praktyka dla ciebie

Aby temat nie pozostał czysto teoretyczny, polecam zrobić mały eksperyment zaraz po lekcji.

Najpierw weź jeden ze swoich scenariuszy GiftGenius albo wymyśl nową aplikację. Wypisz na kartce lub w edytorze jedną funkcję, którą wyraźnie chcesz dać modelowi – coś w rodzaju search_products, find_hotels, calculate_shipping.

Następnie wymyśl dla tego samego narzędzia trzy pary „nazwa + opis”:

1. Bardzo abstrakcyjna nazwa i opis.
2. Zbyt konkretny (niemal special‑case).
3. Dobrze zbalansowana nazwa + opis, gdzie jasno powiedziane jest, kiedy wywoływać narzędzie i czego nie powinno robić.

Potem – opcjonalnie – możesz, korzystając ze zwykłego OpenAI SDK, wykonać proste żądanie z tymi wariantami i zobaczyć, jak zmienia się zachowanie modelu: czy narzędzie jest wywoływane i jak wypełnia argumenty. W badaniach na ten temat właśnie takie ćwiczenie pokazano dla suggest_gifts.

13. Typowe błędy przy projektowaniu tool-call i opisów

Błąd №1: Nazywanie narzędzi tool1, handler, doStuff.
Taki naming jest całkowicie bezużyteczny dla modelu. GPT nie zgaduje „intencji programisty” po nazwie pliku; potrzebuje semantycznie zrozumiałej nazwy. Jeśli podasz zestaw tool1, tool2, tool3 bez opisów, narzędzie praktycznie nie będzie wywoływane: model zwyczajnie nie zrozumie, co każde z nich robi, i albo je zignoruje, albo wybierze losowo.

Błąd №2: Traktowanie description jak komentarza dla ludzi.
Wielu pisze w opisie coś formalnego w rodzaju „Funkcja doboru prezentów”, uznając, że szczegóły i tak są znane z kodu. Ale kodu model nie widzi – widzi tylko tekst opisu i schemat argumentów. Nieprecyzyjny opis staje się źródłem halucynacji: GPT albo spróbuje odpowiedzieć sam, gdy trzeba było wywołać narzędzie, albo wywoła narzędzie w dziwnych sytuacjach.

Błąd №3: Opis zbyt szeroki albo zbyt wąski.
Jeśli piszesz „Robi fajne rzeczy”, model nie rozumie granic zastosowania. Jeśli piszesz „Dobiera prezent tylko dla młodszego brata na 18. urodziny”, de facto zakazujesz używać narzędzia prawie zawsze. Optymalny opis wyznacza wyraźny obszar zadań (dobór prezentów według szeregu parametrów), listę kluczowych parametrów (wiek, relacja, budżet, zainteresowania) i zastrzega, dla jakich klas pytań narzędzia nie używać.

Błąd №4: Ignorowanie schematu argumentów jako części „promptu”.
Niektórzy programiści postrzegają JSON Schema wyłącznie jako sposób walidacji po stronie serwera. W rzeczywistości model aktywnie analizuje nazwy pól, ich typy i opisy, aby zrozumieć, jakie dane należy wydobyć z tekstu użytkownika. Jeśli nazwiesz pole x bez opisu i zrobisz je opcjonalnym, GPT zacznie wypełniać je chaotycznie albo wcale. Poprawny schemat z jasnymi nazwami i krótkimi opisami znacznie zmniejsza liczbę niepoprawnych tool-callów.

Błąd №5: Oczekiwanie, że model „musi” wywołać narzędzie.
Programiści czasem się dziwią: „Dlaczego GPT nie wywołał mojego narzędzia, skoro jest?”. Odpowiedź niemal zawsze jest jedna: z opisu lub system promptu nie wynika, że narzędzie jest potrzebne właśnie do takiego pytania, albo tekst prośby wpadł w obszar, w którym model uznał, że łatwiej mu odpowiedzieć samodzielnie.

Błąd №6: Mieszanie kilku różnorodnych działań w jednym narzędziu.
Kusi, by stworzyć uniwersalne manage_orders, które i wyszukuje zamówienia, i tworzy nowe, i anuluje stare. Dla człowieka da się to jeszcze objaśnić, ale dla modelu powstaje mgliste narzędzie bez wyraźnych granic. GPT gorzej rozumie, kiedy je wywołać, i trudniej wypełnia argumenty – bo w środku robi się mnóstwo pól opcjonalnych. Lepiej rozdzielić takie działania na kilka węższych narzędzi (get_order, create_order, cancel_order) z jasnymi opisami i schematami.

Błąd №7: Nieuwzględnianie uprawnień i bezpieczeństwa w projekcie narzędzia.
Jeśli opisujesz narzędzie, które może wykonywać destrukcyjne działania (obciążenie środków, usuwanie danych), ale nie oznaczasz go jako destructive i nie ograniczasz obszaru użycia w opisie, tworzysz ryzyko. Interfejs ChatGPT nie poprosi o dodatkowe potwierdzenie, a model może zdecydować się wywołać narzędzie nawet w „granicznych” scenariuszach. Właściwe adnotacje i ostrożny opis („używaj tylko po wyraźnej zgodzie użytkownika”) pomagają ograniczyć takie ryzyka już na poziomie tool-calla.