MCP za spletne klepetalnike: Povezovanje orodij z OAuth in odobritvami

MCP naredi spletne klepetalnike bolj operativne – vendar le z jasnimi mejami

MCP za AI klepetalnike ni čarobni vtičnik, ki bi spletnemu klepetalniku nenadoma zaupal poljubne sisteme. Model Context Protocol opisuje predvsem skupni vmesnik, preko katerega lahko model odkrije in kliče orodja: na primer iskanje v bazi znanja, poizvedbo o zahtevku, logiko rezervacije terminov ali interno preverjanje podatkov o izdelkih. To je privlačno predvsem za spletne klepetalnike, saj se mnogi pogovori ne končajo pri enem odgovoru. Obiskovalci sprašujejo o statusu dostave, cenah, kontaktno poti, obrazcih, razpoložljivosti ali naslednjih korakih. Brez orodij mora bot razlagati. Z orodji pa lahko, nadzorovano in sledljivo, pridobi ustrezne podatke ali sproži pripravljene akcije.

Odločilno vprašanje zato ni: Ali lahko klepetalnik uporablja orodja? Vprašanje se glasi: Katera orodja sme videti v katerem kontekstu, s katerim žetonom jih sme poklicati, s katero človeško odobritvijo jih sme izvesti in s katerim protokoliranjem jih lahko pozneje razloži? Končna specifikacija MCP z dne 28. julija 2026 zaostruje prav ta operativna vprašanja. Jedro dela brezstanstveno (stateless), zahteva ustrezne metapodatke na zahtevo ter natančno opredeljuje, kako so med seboj povezani oddaljena avtorizacija HTTP, OAuth, obsegi (scopes) in vezava žetona na ciljno občinstvo (token audience binding).

Kaj specifikacija 2026-07-28 spreminja za spletne ekipe

Najpomembnejša arhitekturna sprememba je brezstanstveno jedro (stateless core). Strežnik MCP ne sme predvidevati, da so prejšnje zahteve na isti povezavi že vzpostavile kontekst, zmožnosti odjemalca ali sejo. Vse, kar je potrebno za obdelavo, mora biti navedeno v trenutni zahtevi. Za porazdeljene spletne infrastrukture je to praktično: zahteve lahko prek izravnalnikov obremenitve (load balancers), prehodov na robu omrežja (edge gateways) ali delovnih platform padejo na različne instance. Za implementacije pa to pomeni tudi: brez skritih predpostavk o transportnih sejah, brez tihih pravic iz prejšnje povezave in brez pogovora v klepetu kot varnostne meje.

Vsaka zahteva potrebuje potrebne metapodatke _meta. Sem sodita zlasti različica protokola in zmožnosti odjemalca; informacije o odjemalcu so koristne za prikaz, beleženje in odpravljanje napak, vendar niso primerne kot varnostni dokaz. Če spletno mesto streže več instancam botov, jezikom ali strankam, je treba ta sloj metapodatkov zavestno preveriti in beležiti. Ne nadomešča strokovne avtorizacije, temveč zagotavlja, da lahko strežnik zahteve pravilno razvrsti.

Seznami orodij so dinamični, vendar ne poljubni

tools/list je v trenutni specifikaciji straniščen (paginated) in omogoča predpomnjenje. Odgovori lahko vsebujejo namige za predpomnjenje, kot sta ttlMs in cacheScope. Hkrati mora zaporedje ostati deterministično, dokler se osnovna množica orodij ne spremeni. To je več kot le kozmetika za zmogljivost: če so katalogi orodij stabilno razvrščeni, jih lahko odjemalci zanesljiveje predpomnijo, konteksti modelov pa ostanejo stabilnejši.

Pomembna je odtenek pri avtorizaciji. Množica orodij se lahko spreminja glede na zahtevo na podlagi predložene avtorizacije, na primer zato, ker žeton dovoljuje le pravice branja podatkov o podpori, ne pa tudi pravic pisanja v CRM. Vendar pa se ne sme naključno spreminjati kot stranski učinek prejšnjih zahtev na isti povezavi. Za spletne klepetalnike iz tega izhaja jasen vzorec: vidni katalog orodij nastane iz vloge, obsega (scope), najemnika (tenant), jezika, konteksta in tveganja trenutne zahteve.

Opisi orodij niso podlaga za zaupanje

Orodja MCP opisujejo svoje ime, vnose, neobvezno izhode in anotacije. Ti metapodatki pomagajo modelu in uporabniškemu vmesniku razumeti funkcijo. Vendar niso varnostno sidro. Specifikacija jasno pravi, da morajo odjemalci obravnavati anotacije orodij kot nezanesljive, razen če prihajajo iz zaupanja vrednih strežnikov. Orodje, ki se opisuje kot namenjeno samo za branje, mora biti na strani strežnika vseeno zgrajeno tako, da ne izvajal nobenih pisalnih stranskih učinkov.

To velja tudi za strukturirane rezultate. Shema outputSchema pomagajo preveriti odgovore in modelu ne predajajo le prostega besedila. Kljub temu morajo strežniki preveriti vnose, nadzorovati dostop, nastaviti omejitve hitrosti (rate limits) in očistiti izhode. Spletni klepetalnik ne bi smel nefiltrirano prevzemati rezultatov orodij v vidne odgovore, zlasti če so vključeni zunanji API-ji, podatki strank ali vsebine, blizu HTML-ju.

OAuth: Strežnik MCP je zaščiten vir

Pri oddaljenem HTTP MCP je delitev vlog ključnega pomena. Zaščiten strežnik MCP deluje kot OAuth Resource Server. Odjemalec MCP deluje v imenu lastnika vira (Resource Owner), torej običajno uporabnika ali organizacije. Authorization Server komunicira z uporabnikom, če je potrebno, in izdaja dostopne žetone (Access Tokens). Strežnik MCP mora zagotoviti svoje podatke Protected Resource Metadata, da lahko odjemalci odkrijejo ustrezen Authorization Server. Authorization Server zagotavlja vsaj enega od postopkov odkrivanja, OAuth Authorization Server Metadata ali OpenID Connect Discovery; odjemalec MCP mora podpirati oba.

Za produktne ekipe to pomeni: klepetalnik sam ne bi smel upravljati gesel, ključev API ali tujih žetonov, če je predviden potek OAuth. Uporabnika mora voditi do jasne odobritve, nato uporabiti namenski dostopni žeton in vidno omejiti orodja, ki so s tem dovoljena. Za registracijo odjemalcev imajo prednost dokumenti Client ID Metadata Documents; dinamična registracija odjemalcev (Dynamic Client Registration) ostaja le zaradi vzvratne združljivosti in je opuščena (deprecated). Zlasti pri integracijah, kot so koledar, CRM, služba za pomoč, odlagališče dokumentov ali trgovinski sistemi, je ta ločitev pomembna, saj se isti pogovor pogosto spreminja med javnimi vprašanji in dejanji, odvisnimi od računa.

Žetoni morajo biti vezani na ciljni vir

Trenutna specifikacija avtorizacije zahteva indikatorje virov (Resource Indicators) po RFC 8707. Odjemalec mora v zahtevah za avtorizacijo in žetone nastaviti parameter resource in s tem navesti kanonični URI strežnika MCP, za katerega je žeton namenjen. Strežnik MCP mora preveriti, ali je bil dostopni žeton izdan natanko za njegov vir. Žetoni se ne smejo prenašati preko poizvedbenega niza (query string), temveč spadajo v glavo Authorization Header.

Ta vezava na ciljno občinstvo preprečuje nevarno bližnjico: žeton, namenjen storitvi A, ne sme biti sprejet ali posredovan storitvi B. Spletni klepetalniki zato potrebujejo čisto mejo žetonov za vsak strežnik MCP in za vsako okolje. Predogled (Preview), Staging in Produkcija ne bi smeli uporabljati istega ciljnega občinstva, če predstavljajo različne vire. Prav tako agregator, ki združuje več strežnikov MCP pred enim modelom, ne bi smel mešati žetonov.

Obsegi (Scopes) so pogodba o uporabniški izkušnji in varnosti

Obsegi (Scopes) bi se morali začeti majhno. Specifikacija priporoča uporabo namigov o obsegu iz izzivov WWW-Authenticate in omogočanje poteka za nadgradnjo pravic (step-up flow) ob pomanjkanju le-teh. V praksi to pomeni: obiskovalec lahko najprej dela z orodji za branje. Šele ko akcija potrebuje več pravic, kot je ustvarjanje zahtevka, pisanje datoteke ali priprava naročila, sistem ciljno zaprosi za dodatno odobritev.

Dobra zasnova privolitve (consent design) ne navaja le imena integracije, temveč tudi učinek: Kateri podatki se berejo? Katera akcija se pripravlja? Ali se kaj zunanje shranjuje, pošilja ali trajno spreminja? Za občutljive operacije bi moral uporabnik videti pravo potrditev in imeti možnost zavrnitve. To ni individualno pravno svetovanje, temveč tehnično pravilo oblikovanja: odobritve morajo biti razumljive ljudem, izvršljive za strežnike in sledljive za revizije.

Zanesljiva arhitektura za spletne klepetalnike z MCP

Robustna arhitektura ločuje model, fasado orodij in ciljne sisteme. Spletni klepetalnik ne komunicira neposredno z vsakim ponudnikom tretjih oseb, temveč z odjemalcem MCP ali prehodom, ki nadzoruje različico protokola, zmožnosti odjemalca, status avtorizacije, omejitve hitrosti in opazljivost (observability). Za tem ležijo strežniki MCP za posamezne integracije ali strokovna področja. Vsak strežnik deklarira le orodja, ki so dovoljena za trenutno zahtevo, in znova preveri vsak klic.

Fasada orodij bi morala uporabljati stabilna imena, tesne vhodne sheme in jasne izhodne sheme. Imena orodij morajo biti dovolj enolična, zlasti kadar več strežnikov ponuja podobne funkcije, kot so search, create ali lookup. Pri agregaciji pomaga imenski prostor ali predpona. Parametri morajo biti oblikovani tako, da modelu ni treba izumljati skrivnih surovih podatkov. Če postopek poteka skozi več zahtev, mora strežnik vrniti ekspliciten, kratkotrajen ročaj (handle) in ga ob vsakem naslednjem klicu znova avtorizirati.

Drugi gradnik je uporabniški vmesnik. Obiskovalci morajo videti, kdaj je orodje poklicano, kateri vnosi so poslani in kdaj je potrebna odobritev. Za čiste dostope za branje pogosto zadošča pregleden status. Za pisalne, plačljive, zunanje ali osebne akcije je potrebna zavestnejša potrditev. Specifikacija pušča vzorce vmesnika odprte, vendar jasno zahteva, da aplikacije omogočajo človeški nadzor nad klici orodij.

Kontrolni seznam za uvedbo MCP za AI klepetalnike

1. Ustvarite inventar orodij: Kateri sistemi naj bodo povezani, katera orodja so le za branje, katera spreminjajo podatke in katera potrebujejo človeško potrditev?
2. Definirajte obsege (scopes): Pravice razdelite po akcijah, ne po internih ekipah. Orodje za poizvedbo statusa potrebuje drugačne obsege kot orodje za ustvarjanje, spreminjanje ali pošiljanje.
3. Preverite odkrivanje OAuth: Preizkusite Protected Resource Metadata, Authorization Server Metadata, registracijo odjemalcev in preusmeritvene URL-je (Redirect URIs) za vsako okolje.
4. Uveljavite vezavo na ciljno občinstvo: Sprejmite žetone le za kanonični URI strežnika MCP, nikoli jih ne posredujte napačnim virom in jih nikoli ne postavljajte v URL-je.
5. Naredite tools/list determinističen: Skupaj preizkusite stabilno razvrščanje, straniščenje (pagination), namige za predpomnjenje in filtre avtorizacije.
6. Ohranite sheme tesne: Preverite vnose, uporabite strukturirane izhode in privzeto onemogočite samodejno omrežno nalaganje zunanjih tarč $ref; neobvezno le z seznamom dovoljenih (allowlist), časovno omejitvijo (timeout), omejitvijo velikosti in beleženjem.
7. Zgradite odobritve v uporabniškem vmesniku: Naredite vidno ime orodja, namen, vnose, ciljni sistem, nadgradnjo obsega in možnost zavrnitve.
8. Usidrajte opazljivost (observability): Beležite ID zahteve, ime orodja, obseg, odločitev, napako, zakasnitev in vrsto rezultata, ne da bi po nepotrebnem shranjevali občutljivo vsebino.
9. Vadite poti napak: Obravnavajte 401, 403, potekle žetone, manjkajoče obsege, neznane ročaje (handles), časovne izteke in zavrnjene odobritve kot običajna stanja izdelka.
10. Začnite majhno: Najprej zaženite eno do dve orodji za branje z nizkim tveganjem, nato postopoma dodajajte nadgradnje pravic, pisalne akcije in nadaljnje integracije.

Tipične napake pri izvedbi

Najpogostejša napaka je preveč širok prvi žeton. Če spletni klepetalnik po prvi prijavi takoj prejme obsežne pisalne pravice, postane vsaka odločitev modela tvegana. Boljši je minimalni začetni obseg s ciljno nadgradnjo pravic. Druga napaka je katalog orodij, ki je sestavljen iz internih imen sistemov namesto iz namenov uporabnikov. Model deluje zanesljiveje z jasnimi, tesno opisanimi akcijami kot z generičnimi večnamenskimi končnimi točkami.

Tretja napaka je pomanjkanje ločitve med zaupanjem v model in zaupanjem v strežnik. Model lahko predlaga akcijo, vendar strežnik odloča, ali so vnosi veljavni, ali žeton ustreza in ali obstaja odobritev. Četrta napaka je pomanjkanje sledljivosti. Če pozneje ni jasno, katero orodje je s katerim obsegom prebralo ali spremenilo katere podatke, ni mogoče ustrezno upravljati niti podpore niti varnosti.

Nadaljnje poglabljanje

Ta prispevek obravnava integracijski sloj MCP: brezstanstveno jedro (stateless core), tools/list in HTTP OAuth. Naslednji članki poglabljajo generično varnost orodij in delovanje: Za model dovoljenj ustreza AI klepetalniki: Varna uporaba orodij s pravicami in potrditvami. Za konkretne klice orodij je vreden branja Varno oblikovanje klicev orodij AI klepetalnika. Če morajo rezultati orodij ostati strojno berljivi, se prilega Preverjanje strukturiranih izhodov AI klepetalnika. Za delovanje in odpravljanje napak je tehnično nadaljevanje Opazljivost AI klepetalnika za sledi, pridobivanje in orodja.

Uradni viri

Strokovna podlaga je končna specifikacija MCP 2026-07-28: stran o MCP Tools, MCP Authorization, uradni prispevek The 2026-07-28 Specification in Base Protocol Overview.

Zaključek

MCP za AI klepetalnike postane dragocen, ko ga spletne ekipe ne razumejo kot odprto skrinjo z orodjem, temveč kot nadzorovan integracijski sloj. Specifikacija 2026-07-28 se dobro prilega sodobni spletni infrastrukturi: brezstanstvene zahteve, seznami, ki jih je mogoče predpomniti, usmerjevalne glave HTTP in eksplicitna avtorizacija na vir. Hkrati jasneje opredeljuje odgovornost. Ponudbe orodij se morajo ujemati s trenutnim žetonom, občutljive operacije potrebujejo človeški nadzor, vsak klic pa mora biti preverjen na strani strežnika.

Pragmatičen začetek je majhen: eno orodje za branje, ozek obseg, jasno besedilo privolitve, deterministično odkrivanje orodij in dobri dnevniki (logs). Pozneje je mogoče priključiti dodatna orodja, ne da bi klepetalnik postal črna skatla. Tako iz spletnega klepetalnika ne nastane nenadzorovan agent, temveč sledljiv asistent, ki sme uporabljati natanko tiste sisteme, ki so odobreni za trenutnega uporabnika in trenutno nalogo.