Tool calling: jak agenci AI korzystają z narzędzi

Czym jest tool calling?

Tool calling (inaczej function calling lub tool use) to kluczowa zdolność, dzięki której agent AI wychodzi poza samo generowanie tekstu. LLM otrzymuje czytelne maszynowo opisy narzędzi, funkcji, API i źródeł danych, a w razie potrzeby tworzy ustrukturyzowane wywołanie z parametrami, które wykonuje otaczająca aplikacja. Wynik wraca do modelu jako obserwacja, a model planuje na tej podstawie kolejny krok. W ten sposób LLM z generatora tekstu staje się podmiotem, który działa.

Trzy najważniejsze odpowiedzi na start:

• Co dzieje się technicznie? Model nie zwraca ciągłego tekstu, tylko ustrukturyzowane wywołanie: nazwę funkcji oraz argumenty w formacie JSON. Aplikacja wykonuje to wywołanie i przekazuje wynik z powrotem do modelu.
• Kto właściwie wywołuje narzędzie? Nie sam LLM. Model proponuje wywołanie; faktyczne wykonanie, łącznie ze sprawdzeniem uprawnień i walidacją, odbywa się w otaczającym kodzie. To rozdzielenie jest podstawą każdej architektury bezpieczeństwa.
• Dlaczego to kluczowa zdolność agentów? Bez tool use LLM pozostaje doradcą, który potrafi tylko mówić. Dopiero tool calling zmienia silnik rozumowania w agenta, który postrzega, planuje, działa i obserwuje, czyli realizuje pełną pętlę Perceive → Reason → Act → Observe.

Konkretny przykład: sprawdzenie dostępności i rezerwacja terminu

Załóżmy, że agent ma zarezerwować klientowi termin konsultacji. Model dostaje dwa narzędzia, każde z nazwą, opisem i schematem parametrów:

1. get_availability(date: string): zwraca wolne terminy dla danej daty.
2. book_appointment(slot_id: string, customer_email: string): rezerwuje termin.

Przebieg:

1. Reason: Użytkownik pisze: „Czy w przyszły wtorek przed południem jest jeszcze wolny termin?”. Model rozpoznaje, że najpierw potrzebuje informacji o dostępności.
2. Act: Zamiast odpowiedzi tekstowej model zwraca ustrukturyzowane wywołanie: get_availability(date: "2026-06-16").
3. Execute: To aplikacja, a nie model, wywołuje prawdziwe API kalendarza i otrzymuje dwa wolne terminy.
4. Observe: Wynik (["09:00", "10:30"]) trafia z powrotem do modelu jako obserwacja.
5. Loop: Model zadaje pytanie doprecyzowujące albo, po potwierdzeniu, wywołuje book_appointment(...).

Ważne: krok zapisu (book_appointment) jest nieodwracalny w swoich skutkach. Właśnie tutaj, zanim agent wykona akcję, potrzebny jest krok human-in-the-loop lub krok potwierdzenia.

Mechanika function calling

We wszystkich popularnych API modeli LLM function calling działa według tego samego podstawowego wzorca, niezależnie od dostawcy:

1. Definicja narzędzia: Każde narzędzie opisuje się za pomocą JSON Schema: nazwa, opis celu w języku naturalnym i typowane parametry. Ten opis to jedyna informacja, na podstawie której model decyduje, czy i jak użyje narzędzia.
2. Wybór narzędzia: W kroku rozumowania model wybiera odpowiednie narzędzie i uzupełnia parametry. Korzysta przy tym wyłącznie z dostarczonych opisów oraz kontekstu rozmowy.
3. Ustrukturyzowane wyjście: Zamiast prozy model zwraca obiekt czytelny maszynowo. Jeśli aktywny jest tryb strict lub Structured Outputs, dostawca za pomocą constrained decoding wymusza zgodność argumentów ze schematem. Bez tego trybu model może wygenerować nieprawidłowe argumenty. Executor waliduje parametry w obu przypadkach, ponieważ argumenty zgodne ze schematem nie gwarantują ani dopuszczalnych wartości, ani niezbędnych uprawnień.
4. Wykonanie & obserwacja: Wywołanie zostaje wykonane, wynik wraca do modelu, a pętla trwa, dopóki cel nie zostanie osiągnięty albo nie zadziała kryterium przerwania (limit iteracji, błąd, guardrail).

Najważniejszy wniosek z praktyki: gdy agent działa błędnie, przyczyna zwykle nie leży w modelu, lecz w definicji narzędzia. Anthropic formułuje tę zasadę bez ogródek: jeśli inżynier, czyli człowiek, nie potrafi jednoznacznie powiedzieć, którego narzędzia użyć w danej sytuacji, agent też tego nie potrafi.

Wynikają z tego trzy zasady projektowe:

• Ograniczenie liczby narzędzi: W 2026 roku dobrą praktyką jest 3-7 aktywnie załadowanych narzędzi; od około 10 narzędzi zaczyna się mierzalne pogorszenie trafności wyboru narzędzia. W wewnętrznych ewaluacjach MCP firmy Anthropic dynamiczne wyszukiwanie narzędzi podniosło trafność wyboru narzędzi z 49% do 74% (Opus 4) oraz z 79,5% do 88,1% (Opus 4.5).
• Unikanie nakładania się: Dwa narzędzia, które mogłyby sensownie odpowiedzieć na to samo zapytanie, to problem, którego nie rozwiąże żaden prompt. Jasna klauzula „kiedy nie używać” w opisie to najskuteczniejszy, a często pomijany element.
• Jednoznaczne nazwy i parametry: Opisowe nazwy i ściśle typowane parametry ograniczają błędne interpretacje, zanim w ogóle się pojawią.

Związek z MCP: standard podłączania narzędzi

Bez standardu każdą integrację narzędzia trzeba okablować osobno, z własnym kodem integracyjnym dla każdego agenta, API i źródła danych. Model Context Protocol (MCP) rozwiązuje ten problem M×N: definiuje jednolity protokół, przez który agent (klient MCP) komunikuje się w ustandaryzowany sposób z narzędziami i źródłami danych (serwery MCP).

MCP to zatem „jak” stojące za tool calling, gdy narzędzia nie znajdują się już we własnym kodzie, lecz są udostępniane jako serwery wielokrotnego użytku. Serwer MCP udostępnia narzędzia, zasoby i prompty; agent wykrywa je w czasie działania i wywołuje według tego samego wzorca function calling. Poziom dojrzałości jest wysoki: aktualna specyfikacja MCP ma wersję 2026-07-28 i opiera się na bezstanowych, samodzielnych żądaniach. W grudniu 2025 roku projekt został przekazany Linux Foundation (Agentic AI Foundation), a serwerów MCP jest już ponad 10 000.

Podczas gdy MCP standaryzuje połączenie agent ↔ narzędzie, komplementarny protokół A2A (Agent-to-Agent) reguluje komunikację agent ↔ agent w systemach wieloagentowych. Od czerwca 2025 roku A2A również jest pod opieką Linux Foundation i wspiera go ponad 150 organizacji. Dla samego tool calling właściwym standardem jest MCP; A2A zyskuje znaczenie dopiero wtedy, gdy współpracuje ze sobą kilku agentów.

Bezpieczeństwo: uprawnienia narzędzi to obowiązek, nie opcja

Gdy tylko agent dotyka rzeczywistych systemów (zapisuje dane w bazach, wysyła e-maile, uruchamia kod), bezpieczeństwo narzędzi staje się kluczowym wymaganiem. Dobra wiadomość: ponieważ LLM tylko proponuje wywołania, a otaczający kod je wykonuje, punkt kontroli znajduje się dokładnie tam, gdzie powinien.

Trzy pułapki z praktyki zdarzają się szczególnie często: traktowanie agentów jak systemów deterministycznych, choć wybór narzędzia jest probabilistyczny; brak obserwowalności, przez co błędy w pętli pozostają niewidoczne; oraz brak human-in-the-loop przy działaniach nieodwracalnych. W europejskich kontekstach wrażliwych na zgodność z przepisami dochodzi jeszcze jedno: operacje zapisu na danych osobowych wiążą się z obowiązkami wynikającymi z RODO, a zautomatyzowane decyzje wywołujące skutki prawne mogą podlegać art. 22 RODO (informacyjnie, nie stanowi porady prawnej).

Podsumowanie

Tool calling to mechanizm, który zamienia LLM w agenta: model proponuje ustrukturyzowane wywołania, kod je wykonuje, a wynik napędza kolejny krok. O jakości decydują trzy elementy: precyzyjne, niepokrywające się definicje narzędzi, niewielki aktywny zestaw narzędzi (3-7) z dynamicznym wykrywaniem oraz architektura bezpieczeństwa oparta na zasadzie najmniejszych uprawnień, walidacji, krokach potwierdzenia i obserwowalności. MCP dostarcza do tego otwarty standard, który przenosi podłączanie narzędzi z pojedynczych integracji na serwery wielokrotnego użytku. Jeśli opanujesz te podstawy, zbudujesz agentów, którzy działają w produkcji niezawodnie i pod kontrolą.