09 – Tool Calling¶

A tool calling az a mechanizmus, amellyel egy LLM műveletet vagy külső capabilityt kérhet, anélkül hogy közvetlenül maga hajtaná végre azt.

A kulcs mentális modell:

LLM eldönti, mit szeretne tenni
        ↓
structured tool call
        ↓
application validálja a requestet
        ↓
application valódi kódot futtat
        ↓
tool result visszakerül a modellhez
        ↓
a modell az új információval folytatja

Az LLM nem executor. Egy decision-making komponens, amely tool invocationt javasolhat.

Miért létezik tool calling?¶

Egy LLM önmagában nem tud megbízhatóan aktuális adatbázist olvasni, emailt küldeni, privát rendszert lekérdezni, fájlt módosítani, internal API-t hívni vagy determinisztikus számítást elvégezni, hacsak ezeket a capabilityket nem tesszük elérhetővé számára.

A toolok ezt a rést hidalják át.

Példák:

get_customer(customer_id)
search_documents(query)
create_ticket(title, priority)
get_weather(location)
run_build(branch)
calculate_tax(amount, country)

A modell megkapja az elérhető toolok descriptionjét és schemáját, és kiválaszthat egyet, ha a taskhoz szükséges.

Tool definition mint contract¶

Egy toolnak világos, machine-readable contractja legyen.

Koncepcionálisan:

{
  "name": "get_order",
  "description": "Retrieve an order by its identifier",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string"
      }
    },
    "required": ["order_id"]
  }
}

Nem a pontos szintaxis a lényeg, hanem hogy az application definiálja:

a tool nevét,
mit csinál,
milyen argumentumokat fogad,
mely argumentumok kötelezők,
milyen típusokat vár.

Ez hasonló egy API contract vagy typed function signature definiálásához.

Példa: order lookup¶

User:

Where is order ORD-12345?

Az LLM training data alapján nem tudhatja az aktuális order state-et.

Kérheti:

{
  "tool": "get_order",
  "arguments": {
    "order_id": "ORD-12345"
  }
}

Az application ezután valami ehhez hasonlót hajt végre:

order = order_service.get_order("ORD-12345")

és resultot ad vissza:

{
  "order_id": "ORD-12345",
  "status": "shipped",
  "carrier": "DHL",
  "estimated_delivery": "2026-09-01"
}

A modell így már válaszolhat:

Your order has shipped with DHL and is currently estimated to arrive on September 1.

Az aktuális tény a toolból jött, nem a model training knowledge-ból.

A tool calling nem közvetlen function execution¶

Hasznos separation:

LLM layer
- choose tool
- generate arguments
- interpret tool result

Application layer
- authenticate
- authorize
- validate
- execute
- handle errors
- audit

Veszélyes architecture lenne gyakorlatilag ezt tenni:

LLM says "delete user 123"
        ↓
execute immediately

Biztonságosabb:

LLM proposes delete_user(user_id=123)
        ↓
validate schema
        ↓
authenticate caller
        ↓
check permission
        ↓
check business rules
        ↓
possibly require confirmation
        ↓
execute

A model tool choice input az application logichoz, nem authorization.

Read tool vs write tool¶

Nem minden tool azonos kockázatú.

Read-only tool¶

get_customer
search_docs
get_invoice

A failure tipikusan helytelen vagy hiányzó információt jelent.

Mutating tool¶

send_email
cancel_order
restart_server
transfer_money

A failure külső side effectet okozhat.

Mutating toolnál általában erősebb kontroll kell:

authorization,
confirmation,
idempotency,
auditing,
retry policy,
rate limits.

A tool result context¶

A tool result általában új model context lesz.

User request
    ↓
LLM
    ↓
tool call
    ↓
tool execution
    ↓
tool result
    ↓
LLM
    ↓
final answer or another tool call

Ez az agentic loop egyik alap building blockja.

A tool calling önmagában még nem feltétlen agent. Egyetlen kontrollált tool call lehet teljesen determinisztikus application workflow része.

Egy tool call vs loop¶

Egyszerű flow:

question
  ↓
LLM
  ↓
get_order
  ↓
answer

Agent-like flow:

goal
 ↓
LLM
 ↓
search_repository
 ↓
LLM
 ↓
read_file
 ↓
LLM
 ↓
run_tests
 ↓
LLM
 ↓
edit_file
 ↓
LLM
 ↓
final result

A második eset ismételten observe-olja az eredményt és kiválasztja a következő actiont. Itt kezdődik az agentic loop.

A tool schema design számít¶

Rossz tool:

execute(action: string, payload: object)

Ez nagyon széles és ambiguous interface-t ad a modellnek.

Jobb:

get_customer(customer_id)
create_support_ticket(title, description, priority)
cancel_order(order_id, reason)

A szűk tool könnyebben:

érthető,
authorizálható,
validálható,
tesztelhető,
observe-olható,
korlátozható.

Ez normál API design elv.

Infrastructure tool helyett semantic tool¶

Tegyük fel, hogy egy ordert kell refundolni.

Gyenge abstraction:

execute_sql(sql)

Jobb abstraction:

refund_order(order_id, reason)

A második megőrzi a domain boundaryt, és lehetővé teszi, hogy a determinisztikus application code enforce-olja a valódi refund rule-okat.

Hasznos elv:

Business capabilityket adj a modellnek, ne unrestricted infrastructure primitiveket, kivéve ha a széles hozzáférés szándékos és erősen sandboxolt.

Tool argument validation¶

Még schema-compatible output esetén is kell business validation.

Tool call:

{
  "tool": "transfer_credit",
  "arguments": {
    "customer_id": "C-123",
    "amount": 1000000
  }
}

Az argumentum formailag lehet helyes, miközben az amount policyt sért.

Ezért:

schema validation
       ↓
business validation
       ↓
authorization
       ↓
execution

Error handling¶

A toolok ugyanúgy hibáznak, mint bármely software dependency.

Lehetséges hibák:

timeout,
HTTP 500,
invalid arguments,
permission denied,
resource not found,
rate limit,
temporary outage.

Az application a raw infrastructure failure-t szükség esetén világos structured tool resulttá alakítsa.

Példa:

{
  "status": "error",
  "error_code": "ORDER_NOT_FOUND",
  "message": "No order exists with this identifier"
}

A modell így kérhet másik ID-t ahelyett, hogy kitalálna egy ordert.

Ne rejts fontos hibát a modell elől¶

Rossz flow:

tool fails
 ↓
application returns empty object
 ↓
LLM guesses what happened

Jobb:

tool fails
 ↓
structured failure result
 ↓
LLM understands the failure
 ↓
retry / ask user / stop

Példa: support assistant¶

Elérhető toolok:

get_customer(email)
get_recent_orders(customer_id)
create_support_ticket(customer_id, category, summary)

User:

My last order never arrived. Please open a ticket.

Lehetséges sequence:

1. LLM → get_customer(email)
2. Application validates and executes
3. Result → customer_id C-847
4. LLM → get_recent_orders(C-847)
5. Result → last order ORD-551, status shipped
6. LLM → create_support_ticket(...)
7. Application checks authorization and executes
8. Result → ticket SUP-9182
9. LLM tells the user the ticket number

A modell koordinálhatja a workflow-t, de minden valós side effect application control alatt marad.

Tool calling vs RAG¶

Különböző problémát oldanak meg.

RAG tipikusan:

retrieve relevant knowledge
        ↓
put it into context
        ↓
answer

Tool calling:

choose an external capability
        ↓
execute it
        ↓
observe the result

Egy retrieval system maga is exposed tool lehet, de koncepcionálisan a retrieval és action külön concern.

Tool calling vs MCP¶

A tool calling a model/application interaction pattern.

Az MCP egy lehetséges standardizált mód toolok és más contextual resource-ok AI clientek számára történő expose-olására.

Koncepcionálisan:

Tool calling = hogyan kér a modell capability executiont

MCP = protokoll, amely ezeket a capabilityket biztosíthatja az AI applicationnek

Nem egymással versengő fogalmak.

Tool-enabled rendszerek tesztelése¶

Több szinten tesztelj.

Schema tests¶

Elutasítja a tool a malformed argumentumot?

Authorization tests¶

Unauthorized user képes protected actiont meghívni?

Execution tests¶

Helyesen működik az underlying tool implementation?

Model behavior tests¶

Reprezentatív requesteknél a megfelelő toolt választja a modell?

End-to-end tests¶

A teljes loop a várt resultot adja unintended side effect nélkül?

Gyakorlati design szabályok¶

A toolok legyenek szűkek és szemantikailag értelmesek.
A tool callt kezeld untrusted requestként validationig.
Authorization maradjon determinisztikus application code-ban.
Válaszd szét a read-only és mutating capabilityket.
Adj explicit structured failure-t.
Mutating toolt retryra és idempotencyre tervezz.
Logold a tool nevét, biztonságosan logolható argumentumait, result statusát, latencyjét és caller contextet.
Ne adj a modellnek szélesebb permissiont a taskhoz szükségesnél.

Mentális modell¶

LLM = planner / chooser
Tool = capability contract
Application = policy + executor
External system = real world state

A fontos boundary:

Az LLM eldöntheti, mit szeretne tenni. Az application dönti el, hogy az action engedélyezett-e, és hogyan hajtható végre.