MCP za web chatbotove: Povezivanje alata uz OAuth i odobrenja

MCP čini web chatbotove sposobnijima za djelovanje - ali samo uz jasne granice

MCP za AI chatbotove nije čarobni utikač koji web chatbotu odjednom povjerava bilo koje sustave. Model Context Protocol opisuje potpunije zajedničko sučelje putem kojeg model može otkriti i pozvati alate: na primjer, pretraživanje baze znanja, upit za ulaznice (tickets), logiku zakazivanja termina ili internu provjeru prema podacima o proizvodima. To je posebno privlačno za web chatbotove jer mnogi dijalozi ne završavaju jednim odgovorom. Posjetitelji pitaju o statusu dostave, cijenama, načinima kontakta, obrascima, dostupnosti ili sljedećim koracima. Bez alata bot mora objašnjavati. S alatima može, kontrolirano i razumljivo, dohvatiti relevantne podatke ili pokrenuti pripremljene akcije.

Kljucno pitanje stoga nije: Može li chatbot koristiti alate? Pitanje glasi: Koje alate smije vidjeti u kojem kontekstu, s kojim tokenom ih pozvati, s kojim ljudskim odobrenjem izvršiti i s kojim zapisnikom kasnije objasniti? Konačna MCP specifikacija od 28. srpnja 2026. pooštrava upravo ova operativna pitanja. Čini jezgru bezstanstvenom (stateless), zahtijeva relevantne metapadatke po zahtjevu te precizira kako su povezani udaljena HTTP autorizacija, OAuth, opsezi i vezanje tokena za publiku (token-audience-binding).

Što specifikacija 2026-07-28 mijenja za web timove

Najvažnija arhitekturna promjena je stateless core (jezgra bez stanja). MCP poslužitelj ne smije pretpostaviti da su prethodni zahtjevi na istoj vezi već uspostavili kontekst, mogućnosti klijenta ili sesiju. Sve što je potrebno za obradu mora biti u trenutnom zahtjevu. Za distribuirane web infrastrukture to je praktično: zahtjevi mogu pasti na različite instance iza uravnoteživača opterećenja (load balancers), edge gatewaya ili radnih platformi. Za implementacije to također znači: nema skrivenih pretpostavki o transportnim sesijama, nema tihih prava iz prethodne veze i nema razgovora u chatu kao sigurnosne granice.

Svaki zahtjev treba potrebne _meta metapodatke. To uključuje verziju protokola i klijentske mogućnosti (client capabilities); informacije o klijentu korisne su za prikaz, bilježenje i otklanjanje pogrešaka, ali nisu prikladne kao sigurnosni dokaz. Ako web stranica poslužuje više instanci botova, jezika ili korisničkih područja, ovaj sloj metapadataka treba svjesno validirati i bilježiti. On ne zamjenjuje poslovnu autorizaciju, ali osigurava da poslužitelj može ispravno klasificirati zahtjeve.

Popisi alata su dinamični, ali ne i proizvoljni

tools/list u trenutnoj je specifikaciji paginiran i može se predmemorirati (cacheable). Odgovori mogu nositi upute za predmemoriju kao što su ttlMs i cacheScope. Istovremeno, redoslijed bi trebao ostati deterministički dok god se osnovni skup alata ne promijeni. To je više od kozmetike performansi: ako su katalozi alata stabilno razvrstani, klijenti ih mogu pouzdanije predmemorirati, a konteksti modela ostaju mirniji.

Važna je nijansa u autorizaciji. Skup alata smije varirati po zahtjevu na temelju predstavljene autorizacije, na primjer jer token dopušta samo prava čitanja podataka podrške, ali ne i prava pisanja u CRM. Međutim, ne smije nasumično fluktuirati kao nuspojava prethodnih zahtjeva na istoj vezi. Za web chatbotove iz toga proizlazi jasan uzorak: vidljivi katalog alata proizlazi iz uloge, opsega (scope), zakupca (tenant), jezika, konteksta i rizika trenutnog zahtjeva.

Opisi alata nisu osnova za povjerenje

MCP alati opisuju svoje ime, svoje ulaze, opcionalno izlaze i anotacije. Ovi metapodaci pomažu modelu i korisničkom sučelju da razumiju funkciju. Međutim, oni nisu sigurnosno sidro. Specifikacija jasno kaže da klijenti moraju tretirati anotacije alata kao nepouzdane, osim ako ne dolaze od pouzdanih poslužitelja. Alat koji sebe opisuje kao samo za čitanje (read-only) i dalje mora biti napravljen na strani poslužitelja tako da ne izvršava nikakve nuspojave pisanja.

To vrijedi i za strukturirane rezultate. outputSchema pomaže u validaciji odgovora umjesto samo davanja slobodnog teksta modelu. Unatoč tome, poslužitelji moraju provjeriti ulaze, kontrolirati pristup, postaviti ograničenja brzine (rate limits) i očistiti izlaze. Web chatbot ne bi trebao preuzimati rezultate alata nefiltrirane u vidljive odgovore, osobito kada su uključeni vanjski API-ji, podaci o korisnicima ili sadržaji bliski HTML-u.

OAuth: MCP poslužitelj je zaštićeni resurs

Kod udaljenog HTTP MCP-a raspodjela uloga je ključna. Zaštićeni MCP poslužitelj djeluje kao OAuth poslužitelj resursa (Resource Server). MCP klijent djeluje u ime vlasnika resursa (Resource Owner), obično korisnika ili organizacije. Poslužitelj za autorizaciju (Authorization Server) komunicira s korisnikom ako je potrebno i izdaje tokene pristupa (Access Tokens). MCP poslužitelj mora pružiti svoje metapodatke zaštićenog resursa (Protected Resource Metadata) kako bi klijenti mogli otkriti odgovarajući poslužitelj za autorizaciju. Poslužitelj za autorizaciju pruža barem jedan od postupaka otkrivanja, OAuth Authorization Server Metadata ili OpenID Connect Discovery; MCP klijent mora podržavati oba.

Za produktne timove to znači: chatbot ne bi trebao sam upravljati lozinkama, API ključevima ili tuđim tokenima ako je predviđen OAuth tijek. Trebao bi voditi korisnika do jasnog odobrenja, nakon toga koristiti namjenski token pristupa i vidljivo ograničiti njime dopuštene alate. Za registraciju klijenta preferiraju se Client ID Metadata Documents; dinamička registracija klijenta (Dynamic Client Registration) ostaje samo radi unazad stvorene kompatibilnosti i zastarjela je (deprecated). Osobito kod integracija kao što su kalendar, CRM, helpdesk, pohrana dokumenata ili sustavi trgovina, ovo je odvajanje važno jer se isti razgovor često prebacuje između javnih pitanja i akcija ovisnih o računu.

Tokeni moraju biti vezani za ciljni resurs

Trenutna specifikacija autorizacije zahtijeva indikatore resursa prema RFC 8707. Klijent mora postaviti parametar resource u zahtjevima za autorizaciju i token te time navesti kanonski URI MCP poslužitelja za koji je token namijenjen. MCP poslužitelj mora provjeriti je li token pristupa izdan točno za njegov resurs. Tokeni se ne smiju prenositi putem query stringa, već pripadaju u Authorization zaglavlje.

Ovo vezanje za publiku (audience binding) sprječava opasan prečac: token namijenjen usluzi A ne smije se prihvatiti niti proslijediti usluzi B. Web chatbotovi stoga trebaju čistu granicu tokena po MCP poslužitelju i po okruženju. Pregled (Preview), Staging i Produkcija ne bi trebali koristiti istu publiku (audience) ako predstavljaju različite resurse. Isto tako, agregator koji spaja više MCP poslužitelja ispred jednog modela ne bi smio miješati tokene.

Opsezi (scopes) su UX i sigurnosni ugovor

Opsezi bi trebali započeti malo. Specifikacija preporučuje korištenje uputa o opsegu iz WWW-Authenticate izazova i dopuštanje tijeka korak-po-korak (step-up flow) u slučaju nedostatka prava. Praktički to znači: posjetitelj prvo može raditi s alatima za čitanje. Tek kada akcija trebate više prava, poput izrade ulaznice (ticket), pisanja datoteke ili pripreme narudžbe, sustav ciljano traži dodatno odobrenje.

Dobar dizajn privole ne navodi samo naziv integracije, već i učinak: Koji se podaci čitaju? Koja se akcija priprema? Pohranjuje li se nešto izvan sustava, šalje li se ili trajno mijenja? Za osjetljive operacije korisnik bi trebao vidjeti stvarnu potvrdu i imati mogućnost odbijanja. To nije pojedinačno pravno savjetovanje, već tehničko pravilo oblikovanja: odobrenja moraju biti razumljiva ljudima, primjenjiva za poslužitelje i slijediva za revizije.

Pouzdanija arhitektura za web chatbotove s MCP-om

Robustna arhitektura odvaja model, fasadu alata i ciljne sustave. Web chatbot ne razgovara izravno sa svakim trećim pružateljem usluga, već s MCP klijentom ili gatewayem koji kontrolira verziju protokola, mogućnosti klijenta, status autorizacije, ograničenja brzine i opservabilnost. Iza toga leže MCP poslužitelji za pojedinačne integracije ili stručna područja. Svaki poslužitelj deklarira samo alate dopuštene za trenutni zahtjev i ponovno validira svaki poziv.

Fasada alata trebala bi koristiti stabilna imena, uske ulazne sheme i jasne izlazne sheme. Imena alata moraju biti dovoljno jedinstvena, osobito ako više poslužitelja nudi slične funkcije kao što su search, create ili lookup. Kod agregacije pomaže imenski prostor (namespace) ili prefiks. Parametri bi trebali biti oblikovani tako da model ne mora izmišljati tajne sirove podatke. Ako se postupak proteže kroz više zahtjeva, poslužitelj bi trebao vratiti eksplicitnu, kratkotrajnu ručku (handle) i ponovno je autorizirati pri svakom sljedećem pozivu.

Drugi gradivni element je korisničko sučelje. Posjetitelji bi trebali vidjeti kada se alat poziva, koji se ulazi šalju i kada je potrebno odobrenje. Za čiste pristupe čitanju često je dovoljan transparentan status. Za akcije pisanja, naplatne, vanjske ili osobne akcije potrebna je svjesnija potvrda. Specifikacija ostavlja uzorke sučelja otvorenima, ali jasno zahtijeva da aplikacije omoguće ljudsku kontrolu nad pozivima alata.

Kontrolni popis za uvođenje MCP-a za AI chatbotove

1. Izradite inventar alata: Koje sustave treba povezati, koji su alati samo za čitanje, koji mijenjaju podatke i koji trebaju ljudsku potvrdu?
2. Definirajte opsege (scopes): Podijelite prava prema akcijama, a ne prema internim timovima. Alat za upit statusa treba drugačije opsege od alata za izradu, izmjenu ili slanje.
3. Provjerite OAuth otkrivanje: Testirajte Protected Resource Metadata, Authorization Server Metadata, registraciju klijenta i preusmjeravanja (Redirect-URIs) po okruženju.
4. Prisilno postavite vezanje za publiku: Prihvatite tokene samo za kanonski MCP poslužiteljski URI, nikada ih ne prosljeđujte za pogrešne resurse i nikada ih ne stavljajte u URL-ove.
5. Učinite tools/list determinističkim: Testirajte stabilno razvrstavanje, paginaciju, upute za predmemoriju i filtre autorizacije zajedno.
6. Držite sheme uskima: Validirajte ulaze, koristite strukturirane izlaze i po zadanim postavkama onemogućite automatsko mrežno učitavanje vanjskih $ref ciljeva; opcionalno samo s popustljivom listom (allowlist), vremenskim ograničenjem, ograničenjem veličine i bilježenjem.
7. Izgradite odobrenja u UI-ju: Učinite vidljivima naziv alata, svrhu, ulaze, ciljni sustav, nadogradnju opsega i opciju odbijanja.
8. Ukorijenite opservabilnost: Bilježite ID zahtjeva, naziv alata, opseg, odluku, pogreške, kašnjenje (latency) i vrstu rezultata, bez nepotrebnog spremanja osjetljivog sadržaja.
9. Vježbajte puteve pogrešaka: Tretirajte 401, 403, istekle tokene, nedostajuće opsege, nepoznate ručke, vremenska prekoračenja i odbijena odobrenja kao normalna stanja proizvoda.
10. Započnite malo: Prvo pustite uživo jedan do dva niskorizična alata za čitanje, a zatim postupno dodajte nadogradnje korak-po-korak, akcije pisanja i daljnje integracije.

Tipične pogreške pri implementaciji

Najčešća pogreška je preširok prvi token. Ako web chatbot nakon prve prijave odmah dobije sveobuhvatna prava pisanja, svaka odluka modela postaje rizičnija. Bolji je minimalni početni opseg s ciljanom nadogradnjom korak-po-korak. Druga pogreška je katalog alata koji se sastoji od internih naziva sustava umjesto iz korisničkih namjera. Model radi pouzdanije s jasnim, usko opisanim akcijama nego s generičkim višenamjenskim krajnjim točkama (endpoints).

Treća pogreška je nedostatak odvajanja između povjerenja u model i povjerenja u poslužitelj. Model smije predložiti akciju, ali poslužitelj odlučuje jesu li ulazi valjani, odgovara li token i postoji li odobrenje. Četvrta pogreška je nedostatak sljedivosti. Ako je kasnije nejasno koji je alat s kojim opsegom pročitao ili izmijenio koje podatke, ne može se uredno voditi ni podrška ni sigurnost.

Daljnje produbljivanje

Ovaj post pokriva MCP integracijski sloj: stateless core, tools/list i HTTP OAuth. Sljedeći članci produbljuju generičku sigurnost alata i rad: Za model ovlaštenja odgovara AI chatbotovi: Sigurno korištenje alata s pravima i potvrđivanjem. Za konkretne pozive alata vrijedi pogledati Sigurno oblikovanje poziva alata za AI chatbotove. Ako rezultati alata trebaju ostati strojno čitljivi, odgovara Validacija strukturiranih izlaza AI chatbota. Za rad i otklanjanje pogrešaka, tehnički nastavak je Opservabilnost AI chatbota za tragove, dohvaćanje i alate.

Službeni izvori

Stručna osnova je konačna MCP specifikacija 2026-07-28: stranica o MCP Tools, MCP Authorization, službeni post The 2026-07-28 Specification i Base Protocol Overview.

Zaključak

MCP za AI chatbotove postaje vrijedan kada ga web timovi ne shvaćaju kao otvorenu kutiju s alatom, već kao kontrolirani integracijski sloj. Specifikacija 2026-07-28 dobro odgovara modernoj web infrastrukturi: zahtjevi bez stanja, popisi koji se mogu predmemorirati, usmjeriva HTTP zaglavlja i eksplicitna autorizacija po resursu. Istovremeno, čini odgovornost jasnijom. Ponude alata moraju odgovarati trenutnom tokenu, osjetljive operacije trebaju ljudsku kontrolu, a svaki poziv mora biti validiran na strani poslužitelja.

Pragmatičan početak je malen: jedan alat za čitanje, uski opseg, jasan tekst privole, determinističko otkrivanje alata i dobri zapisnici. Nakon toga mogu se priključiti i drugi alati bez pretvaranja chatbota u crnu kutiju. Tako web chatbot ne postaje nekontrolirani agent, već razumljiv asistent koji smije koristiti točno one sustave koji su odobreni za trenutnog korisnika i trenutni zadatak.