Tool Calling: Ako AI Agents používajú nástroje

Čo je Tool Calling?

Tool Calling (nazývané aj Function Calling alebo Tool-Use) je kľúčová schopnosť, vďaka ktorej AI Agent prekračuje rámec čistého generovania textu. LLM dostane strojovo čitateľné popisy nástrojov – funkcií, API, dátových zdrojov – a v prípade potreby vygeneruje štruktúrované volanie s parametrami, ktoré okolitá aplikácia vykoná. Výsledok prúdi ako pozorovanie späť do modelu, ktorý následne naplánuje ďalší krok. Týmto spôsobom sa z LLM stáva z generátora textu konajúci aktér.

Tri kľúčové odpovede na úvod:

• Čo sa technicky deje? Model nevracia súvislý text, ale štruktúrované volanie: názov funkcie plus argumenty vo formáte JSON. Aplikácia toto volanie vykoná a výsledok vráti späť do modelu.
• Kto vlastne volá? Nie samotné LLM. Model volanie navrhuje; samotné vykonanie – vrátane kontroly oprávnení a validácie – je v réžii okolitého kódu. Toto oddelenie je základom každej bezpečnostnej architektúry.
• Prečo je to kľúčová schopnosť agentov? Bez Tool-Use zostáva LLM poradcom, ktorý vie len rozprávať. Až Tool Calling robí z Reasoning-Engine agenta, ktorý vníma, plánuje, koná a pozoruje – plný loop Perceive → Reason → Act → Observe.

Konkrétny príklad: skontrolovať dostupnosť a rezervovať termín

Predpokladajme, že agent má zákazníkovi rezervovať konzultačný termín. Modelu sú poskytnuté dva nástroje, každý s názvom, popisom a schémou parametrov:

1. get_availability(date: string) – vráti voľné sloty pre daný dátum.
2. book_appointment(slot_id: string, customer_email: string) – rezervuje slot.

Priebeh:

1. Reason: Používateľ napíše „Mali by ste budúci utorok dopoludnia čas?“. Model rozpozná, že najprv potrebuje dostupnosť.
2. Act: Namiesto textovej odpovede vráti model štruktúrované volanie: get_availability(date: "2026-06-16").
3. Execute: Aplikácia – nie model – zavolá skutočné kalendárové API a dostane dva voľné sloty.
4. Observe: Výsledok (["09:00", "10:30"]) sa privedie ako pozorovanie späť do modelu.
5. Loop: Model sformuluje doplňujúcu otázku alebo – po potvrdení – zavolá book_appointment(...).

Dôležité: zapisujúci krok (book_appointment) je v zmysle účinku nezvratný. Práve sem patrí Human-in-the-Loop alebo potvrdzovací krok, predtým než agent akciu vykoná.

Mechanika Function Calling

Function Calling sa vo všetkých bežných LLM-API riadi tým istým základným vzorom, nezávisle od poskytovateľa:

1. Tool-Definition: Každý nástroj je popísaný cez JSON-schému – názov, popis účelu v prirodzenom jazyku a typizované parametre. Tento popis je jedinou informáciou, na základe ktorej model rozhoduje, či a ako nástroj použije.
2. Tool-Selection: Model v kroku reasoning vyberie vhodný nástroj a vyplní parametre. Využíva pritom výhradne dodané popisy plus kontext konverzácie.
3. Štruktúrovaný výstup: Namiesto prózy dodá model strojovo čitateľný objekt. Constrained Decoding, resp. generovanie viazané na schému, zaisťuje, že výstup zodpovedá očakávanému formátu.
4. Execution & Observation: Volanie sa vykoná, výsledok sa vráti, loop beží ďalej, kým sa nedosiahne cieľ alebo nezasiahne kritérium ukončenia (Loop-Limit, chyba, Guardrail).

Najdôležitejší poznatok z praxe: keď agent koná nesprávne, príčina spravidla nie je v modeli, ale v Tool-Definition. Anthropic formuluje smernicu ostro – ak ani ľudský engineer nedokáže jednoznačne povedať, ktorý nástroj sa má v danej situácii použiť, nedokáže to ani agent.

Z toho vyplývajú tri pravidlá návrhu:

• Obmedziť Tool-Count: 3-7 aktívne načítaných nástrojov je v roku 2026 Best Practice; približne od 10 nástrojov začína merateľná degradácia výberu nástroja. V interných MCP-evaluáciách Anthropic stúpla Tool-Selection-Accuracy s dynamickým vyhľadávaním nástrojov z 49 % na 74 % (Opus 4), resp. zo 79,5 % na 88,1 % (Opus 4.5).
• Vyhnúť sa prekrývaniu: Dva nástroje, ktoré by mohli vierohodne odpovedať na tú istú požiadavku, sú problémom, ktorý nevyrieši žiaden Prompt. Jasná klauzula „kedy-nepoužiť“ v popise je najúčinnejšou, často zabudnutou súčasťou.
• Jednoznačné názvy a parametre: Výstižné názvy a úzko typizované parametre znižujú chybné interpretácie skôr, než vôbec vzniknú.

Vzťah k MCP: štandard pre pripojenie nástrojov

Bez štandardu sa musí každá integrácia nástroja zapájať jednotlivo – na každého agenta, na každé API, na každý dátový zdroj vlastný Glue-Code. Model Context Protocol (MCP) rieši tento M-na-N problém: definuje jednotný protokol, cez ktorý agent (MCP-klient) štandardizovane komunikuje s nástrojmi a dátovými zdrojmi (MCP-server).

MCP je tak „ako“ za Tool Calling, akonáhle nástroje už nie sú vo vlastnom kóde, ale poskytujú sa ako opätovne použiteľné servery. MCP-server poskytuje nástroje, zdroje a Prompts; agent ich objaví za behu a volá cez ten istý vzor Function-Calling. Úroveň zrelosti je vysoká: špecifikácia MCP je dostupná vo verzii 2025-11-25; projekt bol v decembri 2025 odovzdaný Linux Foundation (Agentic AI Foundation) a existuje už viac než 10 000 MCP-serverov.

Zatiaľ čo MCP štandardizuje spojenie Agent ↔ Tool, komplementárny protokol A2A (Agent-to-Agent) upravuje komunikáciu Agent ↔ Agent v Multi-Agent-systémoch. A2A je od júna 2025 takisto pod Linux Foundation a podporuje ho viac než 150 organizácií. Pre čisté Tool Calling je relevantným štandardom MCP; A2A sa stáva dôležitým až na úrovni L5 (Multi-Agent).

Bezpečnosť: Tool-Permissions ako povinnosť, nie ako možnosť

Akonáhle sa agent dotkne reálnych systémov – zapisuje do databáz, odosiela e-maily, vykonáva kód – stáva sa bezpečnosť nástrojov centrálnou požiadavkou. Dobrá správa: keďže LLM volania len navrhuje a okolitý kód ich vykonáva, kontrolný bod sa nachádza presne tam, kam patrí.

Tri Pitfalls z praxe sú obzvlášť časté: zaobchádzať s agentmi deterministicky, hoci výber nástroja je probabilistický; neprevádzkovať žiadnu Observability, takže chyby v loope zostávajú neviditeľné; a nezabezpečiť žiaden Human-in-the-Loop pri nezvratných akciách. V compliance-citlivých DACH-kontextoch sa pridáva: zapisujúce akcie nad osobnými údajmi sa dotýkajú povinností GDPR a automatizované rozhodnutia s právnym účinkom môžu spadať pod čl. 22 GDPR (informačné, nie právne poradenstvo).

Záver

Tool Calling je mechanizmus, ktorý premieňa LLM na agenta: model navrhuje štruktúrované volania, kód ich vykonáva, výsledok poháňa ďalší krok. O kvalite sa rozhoduje na troch miestach – pri presných, neprekrývajúcich sa definíciách nástrojov, pri štíhlej aktívnej sade nástrojov (3-7) s dynamickým Discovery a pri bezpečnostnej architektúre z Least Privilege, validácie, potvrdzovacích krokov a Observability. MCP na to dodáva otvorený štandard, ktorý posúva pripojenie nástrojov od jednotlivých integrácií k opätovne použiteľným serverom. Kto ovláda tieto základy, stavia agentov, ktorí v produkcii konajú spoľahlivo a kontrolovane.