Tool Calling: Ako AI Agents používajú nástroje
Tool Calling (nazývané aj Function Calling) 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 (Tools, API, dátové zdroje) a v prípade potreby vygeneruje štruktúrované volanie s parametrami, ktoré aplikácia vykoná. Výsledok prúdi 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, ktorý vníma, rozhoduje a spúšťa akcie v reálnych systémoch.
Key Takeaways
- ✓Tool Calling je most medzi LLM a vonkajším svetom: model vráti štruktúrované volanie (názov funkcie plus parametre v JSON-schéme), aplikácia ho vykoná a výsledok privedie ako pozorovanie späť do Reasoning-Loop (Perceive-Reason-Act-Observe).
- ✓LLM nevolá nástroje samo - navrhuje volanie. Vykonanie, validácia a oprávnenia sú v réžii okolitého kódu. Práve tam patria Tool-Permissions, validácia vstupov a Human-in-the-Loop pri nezvratných akciách.
- ✓Najčastejším zdrojom chýb nie sú modely, ale nejasné alebo prekrývajúce sa definície nástrojov. Presné názvy, jednoznačné popisy a klauzula kedy-nepoužiť pôsobia silnejšie než akýkoľvek Prompt-trik.
- ✓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. Dynamický Tool-Discovery namiesto statického plného osadenia udržiava výber ostrý.
- ✓Model Context Protocol (MCP) je otvorený štandard pre pripojenie nástrojov: agent môže cez MCP-servery štandardizovane pristupovať k nástrojom a dátovým zdrojom bez toho, aby pre každú integráciu písal vlastný Glue-Code.
- ✓Bezpečnosť nie je doplnok: Least-Privilege-Scopes na každý nástroj, Allowlists, potvrdzovacie kroky pri zapisujúcich alebo nezvratných akciách a Observability nad všetkými Tool-Calls sú povinnosťou, akonáhle sa agent dotkne reálnych systémov.
Č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:
get_availability(date: string), vráti voľné sloty pre daný dátum.book_appointment(slot_id: string, customer_email: string), rezervuje slot.
Priebeh:
- Reason: Používateľ napíše „Mali by ste budúci utorok dopoludnia čas?“. Model rozpozná, že najprv potrebuje dostupnosť.
- Act: Namiesto textovej odpovede vráti model štruktúrované volanie:
get_availability(date: "2026-06-16"). - Execute: Aplikácia, nie model, zavolá skutočné kalendárové API a dostane dva voľné sloty.
- Observe: Výsledok (
["09:00", "10:30"]) sa privedie ako pozorovanie späť do modelu. - 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:
- 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.
- Tool-Selection: Model v kroku reasoning vyberie vhodný nástroj a vyplní parametre. Využíva pritom výhradne dodané popisy plus kontext konverzácie.
- Š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.
- 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í.
Aspekt | Riziko bez ochrany | Opatrenie |
|---|---|---|
Oprávnenia (Scopes) | Agent získa plný prístup cez jeden API-token | Least Privilege: na každý nástroj len minimálne nutné Scopes, oddelené Credentials pre každý nástroj |
Validácia volania | Model vygeneruje neprípustné alebo škodlivé parametre | Allowlists, validácia schémy a rozsahu hodnôt v Executore, nie v modeli |
Nezvratné akcie | Agent maže, rezervuje alebo odosiela bez kontroly | Human-in-the-Loop / potvrdzovací krok pri zapisujúcich a nevratných Calls |
Prompt-/Tool-Injection | Manipulovaná odpoveď nástroja riadi agenta | Untrusted Output zapuzdriť, karanténa, nepokladať neoverený výstup nástroja za príkaz |
Spätná sledovateľnosť | Chybné správanie sa nedá zrekonštruovať | Observability: každé Tool-Call logovať s parametrami, výsledkom a kontextom rozhodnutia |
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.
Často kladené otázky
Aký je rozdiel medzi Tool Calling a Function Calling?
Volá LLM nástroje samo?
Čo má MCP spoločné s Tool Calling?
Koľko nástrojov by mal mať agent súčasne?
Ako sa zabezpečujú volania nástrojov?
Aký je najčastejší zdroj chýb pri Tool Calling?
Related Articles
Ísť hlbšie?
Získajte nové analýzy priamo do schránky, alebo sa pozrite, ako tieto poznatky nasadzujeme pre firmy.