Csevegési eszközök

A Csevegés lehetővé teheti, hogy a modell eszközöket hívjon. Egy engedélyezett eszközökkel futó forduló natív, többkörös ciklust futtat: a modell eszközt kér, a Libre WebUI a hívó felhasználó identitásával és jogosultságaival végrehajtja, az eredmény visszakerül a modellhez, és a ciklus a modell válaszáig folytatódik — fordulónként legfeljebb nyolc körrel, körönként legfeljebb nyolc hívással. A Leállítás megszakítja a modellhívást, a folyamatban lévő eszközhívásokat és a függő jóváhagyási várakozásokat.

Az eszközhívások normalizált eseményekként (chat.tool-call.v1, chat.tool-result.v1, chat.approval.v1) rögzítődnek, amelyek azonos módon haladnak a privát WebSocket-útvonalon és a tartós eseményfolyamon, így a frissítés vagy újracsatlakozás ugyanazt az állapotot játssza vissza. A befejezett forduló a hívásokat korlátozott eredmény-előnézetekkel együtt az asszisztens üzenetében tárolja.

Eszközök engedélyezése

Az eszközök alapértelmezés szerint ki vannak kapcsolva. A rendszergazda a Beállítások → Felhasználókezelés → Hozzáférés és szabályzatok → Eszközhozzáférés alatt nyitja meg őket (csak rendszergazdák vagy minden felhasználó számára); ezután minden forduló a szerkesztő villáskulcsán keresztül választja őket. A választó egy főkapcsolót, valamint beépített eszközönként és regisztrált szerverenként egy jelölőnégyzetet tartalmaz, így a forduló pontosan a kiválasztott eszközökkel fut. A választó szűkítheti a profil kötéseit, de soha nem bővítheti. A privát (inkognitó) csevegések soha nem kínálnak eszközöket: az eszközhívás kifelé irányuló művelet, és jóváhagyásokat, valamint auditbejegyzéseket hagyhat maga után.

Az Eszközhozzáférés kapcsoló azonnal mentődik. Kattintson rá, vagy fókuszálja a Tab, és váltsa a Space billentyűvel. A hozzáférés módosítása a Beállítások ablakot és annak görgetési pozícióját a helyén hagyja.

Egy asszisztensprofil (perszóna) korlátozhatja a kínált eszközöket: a kötött eszközszerverek, a beépített eszközök egy részhalmaza, a kötött készségek és tudásgyűjtemények szűkítik, hogy mit lát a modell a profilt használó munkamenetekben.

Beépített eszközök

A Csevegés tizenhárom saját eszközt tartalmaz (mind csak olvasható, kivéve a jegyzeteket és naptárt módosító eszközöket, amelyek a mellékhatás-jóváhagyási folyamaton mennek keresztül):

• web_search — a rendszergazda által beállított keresőmotor, amely tiszteletben tartja a webes keresés hozzáférési módját.
• search_documents — hibrid keresés a felhasználó feltöltött dokumentumaiban és tudásgyűjteményeiben, beleértve a vele megosztott gyűjteményeket (a profilkötések korlátozhatják a gyűjteményeket); minden szakasz a töredékére és forráshelyére hivatkozik.
• list_documents — felsorolja a csevegés hatókörébe tartozó dokumentumokat ID-val, típussal és mérettel, így a modell eldöntheti, mit olvasson.
• read_document — ID és eltolás alapján egy elérhető dokumentum korlátozott ablakát olvassa, a forráshely címkéjével; olyan fájlok bejárásához, amelyekből a visszakeresés önmagában nem ad választ.
• load_skill — slug alapján betölti egy készség teljes utasításait; az eszköz leírása tartalmazza a felhasználó engedélyezett készségeinek manifestjét, így a készségek addig nem töltődnek be, amíg a modellnek nincs rájuk szüksége. Ha a készség kísérőfájlokat tartalmaz, a betöltött utasítások fájlleltárral zárulnak.
• read_skill_file — slug és relatív útvonal alapján elolvas egy készséghez mellékelt kísérőfájlt, így egy nagy referenciadokumentum addig nem foglal kontextust, amíg a modell ténylegesen meg nem nyitja.
• list_notes — felsorolja a felhasználó saját és megosztott jegyzeteit az ID-jukkal.
• read_note — ID alapján elolvassa egy jegyzet teljes tartalmát.
• create_note — jegyzetet hoz létre (mellékhatással jár, jóváhagyást igényel).
• update_note — lecseréli egy jegyzet tartalmát; az előző állapot visszaállítható verzióként megmarad, így a modell szerkesztése mindig visszafordítható (mellékhatással jár, jóváhagyást igényel).
• list_calendar_events — felsorolja a felhasználó saját és megosztott naptáreseményeit egy epoch-ezredmásodperc tartományban.
• create_calendar_event — naptáreseményt hoz létre (mellékhatással jár, jóváhagyást igényel).
• delete_calendar_event — ID alapján töröl egy naptáreseményt (mellékhatással jár, jóváhagyást igényel).

Eszközszerverek

A rendszergazdák a Beállítások → Eszközök alatt regisztrálják a külső eszközszervereket (az induló sablonok előre kitöltik az űrlapot, többek között egy biztonságos nyilvános bemutató API-val):

• OpenAPI: egy JSON OpenAPI 3.x specifikáció egyszer letöltődik, majd SHA-256 kivonattal rögzítődik. Minden művelet eszközzé válik; a GET műveletek csak olvashatóként, minden más mellékhatásként osztályozódik, amíg a rendszergazda eszközönként felül nem írja. A végrehajtás a rögzített műveletből építi újra a hívást — a modell argumentumai soha nem választják ki a célt.
• MCP (Streamable HTTP): a szerver eszközlistája JSON-RPC-n keresztül töltődik le és ugyanígy rögzítődik. Az annotations.readOnlyHint csak olvashatóként jelöli az eszközt. Az stdio MCP-szerverek szándékosan nem támogatottak: a webfolyamaton belül soha nem futnak külső folyamatok.

A módosított leltár csak akkor lép érvénybe, amikor a rendszergazda frissíti a szervert, ami továbblépteti a rögzített verziót és megőrzi az eszközönkénti felülírásokat. A szerverenkénti elérhetőség lehet csak rendszergazdák számára, minden felhasználó számára vagy jogosultságalapú a közös erőforrás-jogosultsági modellen keresztül (felhasználói és csoportjogosultságok az eszközszerveren).

Hitelesítő adatok

A hitelesítést igénylő szerverek felhasználónkénti hitelesítő adatokat használnak (bearer token vagy megnevezett fejléc). Minden titkos érték további hitelesített adatokkal titkosított, amelyek a pontos felhasználóhoz és szerverhez kötik; minden felhasználó a Beállítások → Eszközök alatt adja meg, és soha nem osztódik meg fiókok között.

Interaktív OAuth (MCP)

Egy MCP-szerver mindenkit saját magának is bejelentkeztethet. Regisztrálja Interactive OAuth hitelesítési móddal, és a Libre WebUI beolvassa a szerver WWW-Authenticate kihívását, követi a védett erőforrás metaadataihoz, majd az authorization server metaadataihoz, és dinamikusan regisztrál egy klienst (RFC 7591), ha az authorization server kínál regisztrációt. Az automatikusan klienst nem regisztráló szolgáltatók a regisztrációs űrlapon rendszergazda által megadott kliensazonosítót (és opcionálisan titkot) kapnak; a titok a felderített végpontok mellett titkosítva tárolódik.

Ezután mindenki megnyomja a Connect gombot a szerver kártyáján, és átirányítódik a szolgáltatóhoz. A folyamat PKCE-t (S256) használ CSRF state-tel, a PKCE verifier pedig egy HttpOnly, az adott egy szerverre korlátozott cookie-ban van tárolva. A visszahívás a kódot a szerveren váltja be, a tokeneket ugyanazzal a felhasználó-és-szerver kötéssel titkosítva tárolja, mint egy statikus titkot, és egy állapotjelzővel küldi vissza a böngészőt az alkalmazásba — a hozzáférési és frissítési tokenek soha nem érik el az oldalt. A hozzáférési tokenek automatikusan frissülnek a lejárat előtt egy perccel, személyenként és szerverenként egyszer, akkor is, ha több eszközhívás versenyez. Amikor a frissítés lehetetlen, az eszközhívás újracsatlakozásra kérve tér vissza, névtelen hiba helyett. A Disconnect eltávolítja az adott személy tokenjeit, és a regisztrációt érintetlenül hagyja; a szerver törlése a felderített konfigurációt is elfelejti.

Egy olyan szerver, amely elutasítja a hitelesítés nélküli eszközlistázást, továbbra is regisztrálva marad: a leltára az első sikeres kapcsolódáskor (és bármely rendszergazdai frissítéskor) rögzítődik, így semmi nem kerül felkínálásra egy modellnek, mielőtt ismertté válna.

Kimenőforgalmi szabályzat

Minden eszközkérés maga oldja fel a célját, elutasítja a privát, loopback- és metaadat-címtereket, majd a feloldott címhez rögzíti a kapcsolatot, így a DNS-újrakötés nem irányíthatja át a hívást. Az átirányítási válaszok elutasításra kerülnek. A válaszok mérete korlátozott, minden hívás szigorú időkorláttal rendelkezik. Pontos belső gazdagépnevek engedélyezhetők a TOOLS_PRIVATE_NETWORK_ALLOWLIST segítségével (vesszővel elválasztva); az engedélyezett gazdagépek rögzítve és korlátozva maradnak. Az eszköz kimenete nem megbízható szövegként kerül vissza a modellbe.

Jóváhagyások

A csak olvasható eszközök kérdés nélkül futnak. A mellékhatással járó eszköz szünetelteti a fordulót, és megkérdezi a felhasználót: egyszer engedélyezi, erre a csevegésre engedélyezi, mindig engedélyezi ezt az eszközt ezen a szerveren, vagy elutasítja. A döntések tartósak — a „mindig” jogosultság túléli az újraindítást, és a Beállítások → Eszközök alatt visszavonható —, a függő kérés pedig két perc után lejár, amit a modell elutasításként lát. Az elutasítás és az időtúllépés soha nem hajtja végre a hívást. Minden döntés és hívás kitakart biztonsági auditeseményt hagy maga után.

Példák

Először kapcsolja be a villáskulcs kapcsolóját a szerkesztőben; az alábbi példák mind normál csevegési üzenetek.

web_search — információ keresése

Mi változott a legújabb SQLite-kiadásban? Válasz előtt keress az interneten.

A modell például {"query": "SQLite latest release changelog"} lekérdezéssel hívja a web_search eszközt, a híváskártya megjeleníti a kapott találatrészleteket, a válasz pedig hivatkozik a találtakra. Ehhez a webes keresésnek beállítva és a fióknál engedélyezve kell lennie.

search_documents — kérdezés saját fájlokról

Töltsön fel PDF-et, vagy adjon dokumentumokat egy tudásgyűjteményhez, majd:

Keresd meg a dokumentumaimban a felmondási záradékot, és idézd pontosan.

A modell {"query": "termination clause"} argumentummal hívja a search_documents eszközt, és a forrásdokumentummal megjelölt egyező szakaszokat kap, így a válasz idézheti és megjelölheti őket.

load_skill — mentett készség alkalmazása

Hozzon létre készséget a Beállítások → Készségek alatt (például $release-notes néven, amely leírja a kívánt kiadási jegyzetstílust), majd:

Készíts kiadási jegyzeteket ehhez az eltéréshez a $release-notes használatával.

A modell látja a készséget a manifestjében, a load_skill {"slug": "release-notes"} hívással letölti a teljes utasításokat, és követi őket. A szerkesztőben beírt $ automatikusan kiegészíti a készségslugokat.

OpenAPI-szerver — például időjárási API

1. Beállítások → Eszközök → Szerver regisztrálása: név Weather, típus OpenAPI, alap-URL https://api.example-weather.dev, specifikáció URL-je https://api.example-weather.dev/openapi.json, hitelesítési mód bearer.

2. A specifikáció rögzítődik, műveletei pedig eszközként jelennek meg — például getForecast (GET, csak olvasható) és createAlert (POST, mellékhatás).

3. Minden használni kívánó felhasználó saját API-kulcsát menti a szerver kártyáján.

4. A csevegésben:

   Milyen idő lesz Montrealban ezen a hétvégén?

   A modell meghívja a weather__getForecast {"city": "Montreal"} eszközt, amely azonnal fut — a csak olvasható eszközök nem kérnek jóváhagyást.

   Értesíts, ha ma este -20 alá esik.

   A weather__createAlert mellékhatással jár, ezért a forduló egy jóváhagyási kártyán megáll: Engedélyezés egyszer, Engedélyezés erre a csevegésre, Mindig engedélyezés vagy Elutasítás. A választásig semmi nem kerül elküldésre.

Exa MCP — webes keresés és letöltés

A Beállítások → Eszközök → Kezdés sablonból alatt válassza az Exa lehetőséget, amely előre kitölt egy MCP-regisztrációt ezzel:

https://mcp.exa.ai/mcp?tools=web_search_exa,web_fetch_exa

Az URL a web_search_exa és a web_fetch_exa eszközt választja ki az Exa eszközválasztó paraméterével. A sablon nem használ hitelesítést, és alapértelmezés szerint a rendszergazdákra korlátozza a hozzáférést. Ellenőrizze az űrlapot, majd a Mentés gombbal csatlakozzon, és rögzítse az eszközlistát. A sablon megnyitása vagy megszakítása nem lép kapcsolatba az Exával. A keresési lekérdezések és a kért URL-ek akkor jutnak el az Exához, amikor ezek az eszközök futnak.

MCP-szerver — például hibakövető

1. Beállítások → Eszközök → Szerver regisztrálása: név Issues, típus MCP, alap-URL https://mcp.example-tracker.dev/mcp, hitelesítési mód header, a fejléc neve X-Api-Key.

2. Az eszközlista rögzítődik; a szerver által csak olvashatóként jelölt eszközök (például search_issues) szabadon futnak, minden más (például create_issue) előbb jóváhagyást kér.

3. A csevegésben:

   Keresd meg a „database lock” kifejezést említő nyitott hibajegyeket, és hozz létre egy újat, amely összefoglalja a mintát.

   Az issues__search_issues azonnal fut; az issues__create_issue a jóváhagyási kártyán megmutatja a pontos argumentumokat, így engedélyezés előtt elolvasható, mi kerülne beküldésre.

Környezeti változók

Változó	Hatás
TOOLS_ACCESS_MODE	Az eszközfunkciót admins vagy all-users értékre rögzíti, és zárolja a rendszergazdai kapcsolót.
TOOLS_PRIVATE_NETWORK_ALLOWLIST	Pontos gazdagépnevek, amelyeket az eszközszerverek privát címre oldhatnak fel (vesszővel elválasztva).

Határok

• Az eszközhívások a WebSocket-útvonalon (a privát munkamenet átvitele tervezetten kizárt) és a tartós csevegések által használt tartós generálási útvonalon futnak. A régi REST streaming endpoint nem futtatja az eszközciklust.
• A csatorna @model említések ugyanazt a ciklust futtatják az említő tag saját katalógusa ellen, egy különbséggel: nincs kit megkérdezni, így egy mellékhatással járó eszköz állandó jóváhagyás nélkül azonnal elutasításra kerül, várakozás helyett. A csak olvasható eszközök szokásosan futnak.
• A Work agentek ugyanazokat a szervereket hívják ugyanazon az átjárón át: csak hálózatot használó futásoknál, a tárolt hitelesítő adat nélküli szerverek már a felajánláskor kiszűrődnek, a mellékhatással járó eszközöket pedig a Work jóváhagyásai szabályozzák.
• A Gemini és az agent CLI modellek nem kapnak eszközöket; az Ollama, az OpenAI-kompatibilis, a Responses-API és az Anthropic szolgáltatók igen.
• Az interaktív OAuth csak MCP-nél elérhető: egy OpenAPI-szerver továbbra is statikus, felhasználónkénti hitelesítő adatot használ. A folyamat az authorization-code grant PKCE-vel; a device-code és a client-credentials folyamatok nem elérhetők, és egy olyan authorization server, amely nem tesz közzé metaadatot (vagy nincs regisztrációs végpontja és nincs rendszergazda által megadott kliensazonosítója sem), nem köthető össze.
• A felderített OAuth-végpontoknak https-nek kell lenniük; a sima http csak loopback esetén elfogadott, fejlesztés közben ugyanazon a gépen futó szolgáltatónál.
• A visszairányítási URI a BASE_URL-ből (vagy az első CORS_ORIGIN-ból) származik, így ennek az értéknek a böngésző által ténylegesen elért címnek kell lennie, és regisztrálva kell lennie azoknál a szolgáltatóknál, amelyek rögzített visszairányítási URI-kat használnak.