Tool-Backed Skills¶

Mi az a tool-backed skill?¶

Egy skill lehet tisztán nyelvi capability:

input → LLM → output

például összefoglalás vagy szövegklasszifikáció.

Sok hasznos agent skill viszont külső adatot vagy műveletet igényel:

PR Review Skill
  ├── fetch diff
  └── read file

Deployment Health Skill
  ├── read deployment state
  └── query metrics

Support Account Skill
  ├── get account
  └── get invoices

Ezek tool-backed skills: a semantic capability működéséhez külső toolokra támaszkodnak.

A legfontosabb boundary: döntés vs végrehajtás¶

Az LLM/skill eldöntheti, hogy milyen műveletre van szükség.

De a tényleges execution az alkalmazás kontrollja alatt maradjon.

User request
    ↓
Skill / LLM
    ↓
Tool request
    ↓
Application validation
    ↓
Authorization / policy
    ↓
Tool execution
    ↓
Tool result
    ↓
Skill / LLM
    ↓
Result

Ez ugyanaz az elv, amit a Foundations Tool Calling részében láttunk, csak most reusable skill boundaryként nézzük.

The model may request an action; the application decides whether and how that action is executed.

Tool selection vs tool execution¶

Tegyük fel, hogy a user kérdezi:

Miért lett elutasítva a tegnapi számlám?

A skill felismerheti:

Need current invoice data

és kérheti:

{
  "tool": "get_invoice",
  "arguments": {
    "invoice_id": "INV-1842"
  }
}

De maga az LLM ne közvetlenül fusson neki a production rendszernek.

Az app:

1. validate arguments
2. check current user's permission
3. resolve tenant/account scope
4. execute API call
5. normalize result
6. return result to skill runtime

Ez választja el a probabilistic decisiont a deterministic execution boundarytól.

Tool schema mint interface¶

Egy tool jó esetben explicit schema-val rendelkezik.

Például:

{
  "name": "get_invoice",
  "description": "Read one invoice visible to the current authenticated customer.",
  "parameters": {
    "type": "object",
    "properties": {
      "invoice_id": {
        "type": "string"
      }
    },
    "required": ["invoice_id"]
  }
}

A schema segít a modellnek helyes argumentumot előállítani, de az appnak továbbra is validálnia kell.

schema-valid arguments
        ≠
authorized operation

Például az invoice_id lehet valid string, de másik customer számlája.

Skill-level tool dependency¶

Egy skill contractja mondhatja:

requires:
- invoice_reader

A konkrét runtime pedig ezt mapeli:

invoice_reader
     ↓
Billing API adapter

vagy más környezetben:

invoice_reader
     ↓
Test fixture adapter

Ez jobb coupling, mint ha a skill konkrét REST endpointokra épülne.

Skill depends on capability
Runtime depends on implementation

Read-only és mutating toolok¶

Security szempontból nagy különbség van ezek között.

Read-only¶

get_invoice
read_file
query_metrics
get_deployment
search_documentation

A side effect kockázata kisebb, de még itt is kell authorization és data isolation.

Mutating¶

send_email
create_issue
restart_service
merge_pull_request
refund_payment
delete_resource

Itt már tényleges state change történik.

A runtime-nak érdemes ezt explicit metadata-ként ismernie.

Tool
├── risk: read-only | mutating
├── approval: required | not-required
├── idempotent: true | false
└── authorization_scope

Példa: GitHub Issue Creation Skill¶

A user:

Csinálj ebből a bug reportból GitHub issue-t.

A skill előállíthatja:

{
  "title": "Retry path may duplicate payment charge",
  "body": "...",
  "labels": ["bug", "payments"]
}

Majd tool request:

create_issue(...)

A helyes runtime:

Skill decides content
      ↓
App validates repository access
      ↓
App may request human confirmation
      ↓
Tool executes create_issue
      ↓
Tool returns issue URL/id

Nem jó boundary:

System prompt:
"Only create issues in repositories the user may access."

és aztán vakon végrehajtjuk, amit a modell kér.

Az authorizationt a GitHub credential és application policy alapján kell determinisztikusan enforce-olni.

Human approval mutating action előtt¶

Nem minden write tool igényel approvalt.

De magasabb kockázatnál nagyon hasznos pattern:

Plan / proposed action
        ↓
Human approval
        ↓
Execution

Például:

Agent wants to restart production payment-service.

A skill mondhatja:

recommended_action = restart payment-service

de a runtime:

production restart
      ↓
approval required

Az approval nem „prompt instruction”, hanem tényleges execution gate.

Tool output normalizálása¶

Egy nyers API output lehet hatalmas és zajos.

Például GitHub PR API response több száz mezőt adhat, miközben a skill csak ezt igényli:

{
  "number": 184,
  "title": "Fix retry handling",
  "state": "open",
  "base_branch": "main",
  "head_branch": "retry-fix"
}

Hasznos architektúra:

External API
    ↓
Adapter / normalization
    ↓
Tool result contract
    ↓
LLM context

Ez:

csökkenti a tokeneket,
csökkenti a couplingot,
kisebb attack surface-t ad,
stabilabb tool contractot biztosít.

Tool error nem ugyanaz, mint model error¶

A runtime-nak külön kell tudnia kezelni.

Példák:

TOOL_TIMEOUT
TOOL_UNAVAILABLE
NOT_AUTHORIZED
NOT_FOUND
RATE_LIMITED
INVALID_ARGUMENT
TRANSIENT_FAILURE

A skill ezek alapján másként reagálhat.

NOT_FOUND¶

Invoice not found.

Ne próbálja meg kitalálni a számla állapotát.

NOT_AUTHORIZED¶

User cannot access this repository.

Ne próbáljon más toolon keresztül kerülőutat találni.

TRANSIENT_FAILURE¶

Itt lehet kontrollált retry.

Retry és idempotency¶

Read operationnél retry gyakran egyszerű:

query metrics
 ↓
timeout
 ↓
retry

Write operationnél veszélyes lehet:

create refund
 ↓
timeout
 ↓
retry
 ↓
duplicate refund?

Ezért mutating tooloknál fontos az idempotency.

Például:

refund_payment(
  payment_id,
  amount,
  idempotency_key
)

A skillnek nem feltétlenül kell az idempotency mechanizmust implementálnia; ez inkább application/tool boundary.

Tool result és hallucination¶

A tool használata nem szünteti meg automatikusan a hallucinationt.

Például tool result:

{
  "status": "REJECTED",
  "reason_code": "DUPLICATE_REFERENCE"
}

A modell ezt hibásan magyarázhatja:

"A bank elutasította fedezethiány miatt."

miközben ilyen adat nem volt.

Ezért instruction:

Explain the rejection using only returned reason codes and supplied policy knowledge.
If the code meaning is unknown, say that it is unknown.

Tool = grounded data source.

Nem = guaranteed correct interpretation.

Tool granularity¶

Túl alacsony szintű toolok növelhetik az agent runtime komplexitását.

Például:

open_tcp_connection
send_http_bytes
parse_json

helyett task-orientedabb:

get_customer_invoice

Másik véglet a túl erős tool:

do_everything_in_billing_system(command: string)

Ez túl nagy attack surface.

Jó tool tipikusan:

egyértelmű responsibility,
typed input,
typed output,
limitált permission,
kiszámítható side effect.

Skill vs tool responsibility¶

Példa: Deployment Health Skill.

Skill responsibility¶

- interpret user's diagnostic goal
- decide which observations matter
- compare signals
- explain likely issue
- recommend next diagnostic action

Tool responsibility¶

get_deployment_state
query_error_rate
query_latency
read_recent_events

A tool adja a tényeket.

A skill összerakja a jelentést és a döntési logikát ott, ahol semantic reasoning kell.

Tool-backed skill több toolal¶

Például incident diagnosis:

Incident Diagnosis Skill
         │
         ├── get_deployment_state
         ├── query_metrics
         ├── query_logs
         └── read_recent_changes

A skill execution akár iteratív lehet:

read incident
 ↓
query error rate
 ↓
high error rate after deployment
 ↓
read recent deployment
 ↓
query affected endpoint logs
 ↓
produce diagnosis

Ez már közelít az agentic loop témához.

A skill azt definiálja, milyen capabilityt akarunk; a loop azt, hogyan történik több observation/action iterációban az execution.

MCP kapcsolat¶

Egy skill tool capabilityt igényelhet például:

repository_reader

Ezt a runtime különböző módon biztosíthatja:

native function call
REST adapter
connector
MCP server

Tehát:

Skill = what capability is needed and how it is used
MCP   = one possible protocol/runtime mechanism to expose tools/resources

Ezért az MCP-t nem érdemes magába a skill fogalmába belekeverni.

Anti-pattern: a modell közvetlen credentialt kap¶

Ne adjunk a skill contextjébe:

AWS_SECRET_ACCESS_KEY=...
GitHub token=...
DB password=...

A modellnek általában nincs szüksége a credential értékére.

LLM
 ↓
tool request
 ↓
trusted runtime owns credential
 ↓
external system

Ez a helyesebb boundary.

Anti-pattern: unrestricted shell tool¶

Egy generikus tool:

shell(command: string)

nagyon erős capability.

Egy deployment health skillnek lehet, hogy csak ezek kellenek:

get_deployment
get_pods
get_recent_events

A domain-specific toolok least privilege szempontból sokkal jobbak lehetnek.

Generikus shellnek lehet helye például coding agent sandboxban, de security modellje teljesen más.

Anti-pattern: tool error után találgatás¶

Gyenge:

get_balance → timeout
LLM → "Your balance is probably around 500 EUR."

Jobb:

get_balance → timeout
↓
controlled retry / fallback
↓
if unavailable:
CURRENT_BALANCE_UNAVAILABLE

A tool failure legyen explicit system state.

Takeaways¶

A tool-backed skill külső adatot vagy műveletet használ reusable capability részeként.
Az LLM kérhet tool callt; az application kontrollálja a tényleges executiont.
Tool argument schema nem helyettesíti az authorizationt és business validationt.
Read-only és mutating toolokat külön kockázati kategóriaként kezeljük.
High-risk write actionnél human approval lehet valódi execution gate.
A tool eredményt érdemes normalizálni és minimalizálni, mielőtt contextbe kerül.
Retry előtt gondoljunk idempotencyre, különösen write műveleteknél.
Tool result groundingot ad, de a modell interpretációja attól még lehet hibás.
A skill capabilityre támaszkodjon, a runtime mapelje azt konkrét provider/tool implementationre.
MCP egy lehetséges tool exposure mechanism; nem maga a skill.