MCP veebisaidi vestlusbotidele: tööriistade ühendamine OAuth-i ja kinnitustega

MCP muudab veebisaidi vestlusbotid teovõimelisemaks – kuid ainult selgete piiridega

MCP tehisintellektiga vestlusbotidele ei ole imepistik, mis usaldaks veebisaidi vestlusbotile korraga suvalisi süsteeme. Model Context Protocol kirjeldab pigem ühist liidest, mille kaudu mudel saab tööriistu avastada ja välja kutsuda: näiteks otsing teadmusbaasis, piletipäring, kohtumiste broneerimise loogika või sisemine kontroll tooteandmete suhtes. Veebisaidi vestlusbotide puhul on see eriti atraktiivne, sest paljud dialoogid ei lõpe ühe vastusega. Külastajad küsivad tarnestaatuse, hindade, kontaktivõimaluste, vormide, kättesaadavuse või järgmiste sammude kohta. Ilma tööriistadeta peab bot selgitama. Tööriistadega saab ta kontrollitult ja jälgitavalt hankida asjakohaseid andmeid või algatada ettevalmistatud toiminguid.

Seetõttu ei ole otsustav küsimus: kas vestlusbot saab tööriistu kasutada? Küsimus on: milliseid tööriistu tohib ta millises kontekstis näha, millise tokeniga välja kutsuda, millise inimese kinnitusega täita ja millise logimisega hiljem selgitada? Lõplik MCP spetsifikatsioon seisuga 28. juuli 2026 teravdab täpselt neid käitusküsimusi. See muudab tuuma olekutuks, nõuab päringu kohta asjakohaseid metaandmeid ning täpsustab, kuidas kaug-HTTP-autoriseerimine, OAuth, skoobid ja tokeni sihtrühma sidumine (audience binding) omavahel seostuvad.

Mida muudab spetsifikatsioon 2026-07-28 veebilehtede tiimidele

Kõige olulisem arhitektuurne muudatus on olekutu tuum (stateless core). MCP-server ei tohi eeldada, et varasemad päringud samal ühendusel on juba loonud konteksti, kliendi võimekused või sessiooni. Kõik, mida töötlemiseks vaja, peab sisalduma praeguses päringus. Hajutatud veebitarristute puhul on see praktiline: päringud võivad koormusjaoturite, edge-väravate või worker-platvormide taga langeda erinevatele instantsidele. Rakenduste jaoks tähendab see aga ka: ei mingeid varjatud eeldusi transpordisessioonide kohta, ei mingeid vaikivaid õigusi eelmisest ühendusest ega vestlust kui turvapiiri.

Iga päring vajab nõutavaid _meta-metaandmeid. Nende hulka kuuluvad eelkõige protokolli versioon ja kliendi võimekused (client capabilities); kliendi teave on abiks kuvamisel, logimisel ja silumisel, kuid ei sobi turvatõendiks. Kui veebisait teenindab mitut boti instantsi, keelt või kliendialat, tuleks seda metaandmete kihti teadlikult valideerida ja logida. See ei asenda ärilist autoriseerimist, kuid tagab, että server saab päringuid õigesti klassifitseerida.

Tööriistade nimekirjad on dünaamilised, kuid mitte suvalised

tools/list on praeguses spetsifikatsioonis lehitsetav (paginated) ja vahemällu salvestatav. Vastused võivad kanda vahemälu vihjeid nagu ttlMs ja cacheScope. Samal ajal peab järjekord jääma deterministlikuks seni, kuni aluseks olev tööriistade hulk ei muutu. See on enamat kui lihtsalt jõudluse kosmeetika: kui tööriistakataloogid on stabiilselt sorditud, saavad kliendid neid usaldusväärsemalt vahemällu salvestada ja mudeli kontekstid jäävad rahulikumaks.

Oluline on autoriseerimise nüanss. Tööriistade hulk võib päringu kohta varieeruda vastavalt esitatud autoriseeringule, näiteks kuna token annab ainult lugemisõigused tugiandmetele, kuid mitte kirjutamisõigusi CRM-i. See ei tohi aga kõikuda juhuslikult samal ühendusel tehtud varasemate päringute kõrvalmõjuna. Veebisaidi vestlusbotide jaoks tuleneb sellest selge muster: nähtav tööriistakataloog tekib praeguse päringu rollist, skoobist, rentnikust (tenant), keelest, kontekstist ja riskist.

Tööriistade kirjeldused ei ole usalduse alus

MCP tööriistad kirjeldavad oma nime, sisendandmeid, valikuliselt väljundeid ja annotatsioone. Need metaandmed aitavad mudelil ja kasutajaliidesel funktsioonist aru saada. Kuid need ei ole turvaankruks. Spetsifikatsioon ütleb selgelt, et kliendid peavad käsitlema tööriistade annotatsioone ebausaldusväärsetena, välja arvatud juhul, kui need pärinevad usaldusväärsetest serveritest. Tööriist, mis kirjeldab ennast kirjutuskaitstuna, peab serveri poolel olema ikkagi ehitatud nii, et see ei teostaks kirjutavaid kõrvalmõjusid.

See kehtib ka struktureeritud tulemuste kohta. outputSchema aitab vastuseid valideerida ja mitte anda mudelile pelgalt vabateksti. Sellegipoolest peavad serverid sisendeid kontrollima, juurdepääsu juhtima, päringupiiranguid (rate limits) seadma ja väljundeid puhastama. Veebisaidi vestlusbot ei tohiks tööriista tulemusi filtrimata nähtavatesse vastustesse üle võtta, eriti kui mängus on välised API-d, kliendiandmed või HTML-ilähedane sisu.

OAuth: MCP-server on kaitstud ressurss

Kaug-HTTP-MCP puhul on rollide jaotus otsustav. Kaitstud MCP-server tegutseb kui OAuth ressursiserver (Resource Server). MCP-klient tegutseb ressursiomaniku (Resource Owner) nimel, kes on tavaliselt kasutaja või organisatsioon. Autoriseerimisserver (Authorization Server) suhtleb vajadusel kasutajaga ja väljastab juurdepääsutokeneid (Access Tokens). MCP-server peab esitama oma kaitstud ressursi metaandmed (Protected Resource Metadata), et kliendid saaksid avastada sobiva autoriseerimisserveri. Autoriseerimisserver pakub vähemalt ühte avastamismeetodit: OAuth Authorization Server Metadata või OpenID Connect Discovery; MCP-klient peab toetama mõlemat.

Tootetiimide jaoks tähendab see: vestlusbot ei tohiks ise hallata paroole, API-võtmeid ega võõraid tokeneid, kui on ette nähtud OAuth-voog. See peaks suunama kasutaja selge kinnituseni, kasutama pärast seda eesmärgipärast juurdepääsutokenit ning nähtavalt piirama sellega lubatud tööriistu. Kliendi registreerimiseks eelistatakse dokumendimetaandmeid (Client ID Metadata Documents); dünaamiline kliendi registreerimine (Dynamic Client Registration) säilib vaid tagasiühilduvuse tagamiseks ja on vananenud (deprecated). Eriti selliste integratsioonide puhul nagu kalender, CRM, kasutajatugi, dokumendihoidla või e-pood on see eraldatus oluline, sest sama vestlus vahetub sageli avalike küsimuste ja kontopõhiste toimingute vahel.

Tokenid peavad olema seotud sihtressursiga

Praegune autoriseerimisspetsifikatsioon nõuab ressursinäidikuid (Resource Indicators) vastavalt RFC 8707-le. Klient peab autoriseerimis- ja tokenipäringutes määrama parameetri resource, näidates sellega selle MCP-serveri kanoonilist URI-d, mille jaoks token on mõeldud. MCP-server peab kontrollima, et juurdepääsutoken väljastati täpselt tema ressursi jaoks. Tokeneid ei tohi edastada päringustringi (query string) kaudu, vaid need kuuluvad Authorization-päisesse.

See sihtrühma sidumine hoiab ära ohtliku otsetee: teenuse A jaoks mõeldud tokenit ei tohi teenuses B aktsepteerida ega edasi saata. Veebisaidi vestlusbotid vajavad seetõttu puhtalt piiritletud tokeneid iga MCP-serveri ja keskkonna kohta. Eelvaade (preview), staging ja toodang (production) ei tohiks kasutada sama sihtrühma (audience), kui need kujutavad endast erinevaid ressursse. Samamoodi ei tohiks mitut MCP-serverit mudeli ees ühendav agregaator tokeneid segamini ajada.

Skoobid on kasutajakogemuse ja turvalisuse kokkulepe

Skoobid peaksid algama väikeselt. Spetsifikatsioon soovitab kasutada skoopide vihjeid WWW-Authenticate väljakutsetest (challenges) ning puuduvate õiguste korral lubada samm-sammulist õiguste suurendamise voogu (step-up flow). Praktiliselt tähendab see järgmist: külastaja saab kõigepealt töötada lugemisõigustega tööriistadega. Alles siis, kui toiming vajab rohkem õigusi – näiteks pileti loomiseks, faili kirjutamiseks või tellimuse ettevalmistamiseks –, küsib süsteem sihipäraselt täiendavat kinnitust.

Hea nõusoleku disain (consent design) ei nimeta mitte ainult integratsiooni nime, vaid ka selle mõju: milliseid andmeid loetakse? Millist toimingut ette valmistatakse? Kas midagi salvestatakse väliselt, saadetakse ära või muudetakse jäädavalt? Tundlike operatsioonide puhul peaks kasutaja nägema tõelist kinnitust ja saama sellest keelduda. See ei ole individuaalne õigusnõustamine, vaid tehniline kujundusreegel: kinnitused peavad olema inimestele arusaadavad, serveritele rakendatavad ja auditite jaoks jälgitavad.

Vastupidav arhitektuur veebisaidi vestlusbotidele koos MCP-ga

Tugev arhitektuur eraldab mudeli, tööriistade fassaadi ja sihtsüsteemid. Veebisaidi vestlusbot ei räägi otse iga kolmanda osapoole pakutava teenusega, vaid MCP-kliendi või -väravaga (gateway), mis kontrollib protokolli versiooni, kliendi võimekusi, autoriseerimisolekut, päringupiiranguid ja vaadeldavust (observability). Selle taga asuvad MCP-serverid üksikute integratsioonide või valdkondade jaoks. Iga server deklareerib ainult need tööriistad, mis on praeguse päringu jaoks lubatud, ja valideerib iga kutse uuesti.

Tööriistade fassaad peaks kasutama stabiilseid nimesid, kitsaid sisendskeeme ja selgeid väljundskeeme. Tööriistade nimed peavad olema piisavalt üheselt mõistetavad, eriti kui mitu serverit pakuvad sarnaseid funktsioone nagu search, create või lookup. Agregeerimisel aitab nimeruum või eesliide. Parameetrid peaksid olema kujundatud nii, et mudel ei peaks välja mõtlema salajasi toorandmeid. Kui protsess kestab üle mitme päringu, peaks server tagastama selge, lühiajalise käepideme (handle) ja autoriseerima selle iga järgneva kutse puhul uuesti.

Teine ehituskivi on kasutajaliides. Külastajad peaksid nägema, kui tööriist välja kutsutakse, milliseid sisendeid saadetakse ja millal on vaja kinnitust. Puhtalt lugemispõhise juurdepääsu puhul piisab sageli läbipaistvast olekust. Kirjutavate, tasuliste, väliste või isikuandmetega seotud toimingute jaoks on vaja teadlikumat kinnitust. Spetsifikatsioon jätab liidesemustrid lahtiseks, kuid nõuab selgelt, et rakendused peavad võimaldama inimkontrolli tööriistade kutsete üle.

MCP kasutuselevõtu kontrollnimekiri tehisintellektiga vestlusbotidele

1. Loo tööriistade inventuur: Millised süsteemid tuleb ühendada, millised tööriistad on ainult lugemiseks, millised muudavad andmeid ja millised vajavad inimese kinnitust?
2. Defineeri skoobid: Jaga õigused toimingute, mitte siseosakondade järgi. Oleku päringute tööriist vajab teistsuguseid skoope kui tööriist loomiseks, muutmiseks või saatmiseks.
3. Kontrolli OAuth-i avastamist: Testi kaitstud ressursi metaandmeid, autoriseerimisserveri metaandmeid, kliendi registreerimist ja ümbersuunamise URI-sid (redirect URIs) iga keskkonna kohta.
4. Ratsusta sihtrühma sidumine: Aktsepteeri tokeneid ainult kanoonilise MCP-serveri URI jaoks, ära kunagi edasta neid valedele ressurssidele ja ära kunagi pane neid URL-idesse.
5. Muuda tools/list deterministlikuks: Testi koos stabiilset sortimist, lehitsemist, vahemälu vihjeid ja autoriseerimisfiltreid.
6. Hoia skeemid kitsad: Valideeri sisendid, kasuta struktureeritud väljundeid ja keela vaikimisi väliste $ref sihtmärkide automaatne võrgulaadimine; valikuliselt luba see ainult lubatud nimekirja (allowlist), ajalõpu, suuruse piirangu ja logimisega.
7. Ehita kinnitused kasutajaliidesesse: Muuda nähtavaks tööriista nimi, eesmärk, sisendid, sihtsüsteem, skoobi täiendus ja keeldumise võimalus.
8. Juuruta vaadeldavus: Logi päringu ID, tööriista nimi, skoop, otsus, vead, viivitus (latency) ja tulemuse tüüp ilma tundlikku sisu vajaduseta salvestamata.
9. Harjuta veateid: Käsitle koode 401, 403, aegunud tokeneid, puuduvaid skoope, tundmatuid käepidemeid, ajalõppusid ja tagasilükatud kinnitusi kui tavalisi tooteolekuid.
10. Alusta väikeselt: Võta kõigepealt kasutusele üks kuni kaks madala riskiga lugemistööriista, seejärel lisanduvad samm-sammult õiguste suurendamine, kirjutavad toimingud ja täiendavad integratsioonid.

Tüüpilised vead teostusel

Kõige sagedasem viga on liiga laiaulatuslik esimene token. Kui veebisaidi vestlusbot saab pärast esimest sisselogimist kohe ulatuslikud kirjutamisõigused, muutub iga mudeli otsus riskantsemaks. Parem on minimaalne algusskoop koos sihipärase õiguste suurendamisega (step-up). Teine viga on tööriistakataloog, mis koosneb kasutaja kavatsuste asemel sisemiste süsteemide nimedest. Mudel töötab usaldusväärsemalt selgete, kitsalt kirjeldatud toimingutega kui üldiste universaalsete lõpp-punktidega (endpoints).

Kolmas viga on mudeli usaldamise ja serveri usaldamise vahelise eraldatuse puudumine. Mudel võib toimingut ette panna, kuid server otsustab, kas sisendid on kehtivad, kas token sobib ja kas kinnitus on olemas. Neljas viga on jälgitavuse puudumine. Kui hiljem pole selge, milline tööriist millise skoobiga milliseid andmeid luges või muutis, ei saa ei kliendituge ega turvalisust korrektselt hallata.

Täiendavad süvaanalüüsid

See artikkel käsitleb MCP integratsioonikihti: olekutut tuuma, tools/list päringut ja HTTP-OAuth-i. Järgmised artiklid süvenevad üldisesse tööriistade turvalisusse ja käitamisse: õiguste mudeli jaoks sobib Tehisintellektiga vestlusbotid: tööriistade turvaline kasutamine õiguste ja kinnitustega. Konkreetsete tööriistakutsete jaoks tasub lugeda artiklit Tehisintellektiga vestlusboti tööriistakutsete turvaline kujundamine. Kui tööriista tulemused peavad jääma masinloetavaks, sobib Tehisintellektiga vestlusboti struktureeritud väljundite valideerimine. Käitamise ja tõrkeotsingu jaoks on tehniliseks jätkuks Tehisintellektiga vestlusboti vaadeldavus jälituse, otsingu ja tööriistade jaoks.

Ametlikud allikad

Erialaseks aluseks on lõplik MCP spetsifikatsioon 2026-07-28: lehekülg MCP Tools kohta, MCP Authorization, ametlik artikkel The 2026-07-28 Specification ja Base Protocol Overview.

Kokkuvõte

MCP tehisintellektiga vestlusbotidele muutub väärtuslikuks siis, kui veebisaidi tiimid ei mõista seda kui lahtist tööriistakasti, vaid kui kontrollitud integratsioonikihti. Spetsifikatsioon 2026-07-28 sobib hästi kaasaegse veebitarristuga: olekuta päringud, vahemällu salvestatavad nimekirjad, ruuditavad HTTP-päised ja selge autoriseerimine ressursi kohta. Samal ajal muudab see vastutuse selgemaks. Tööriistade pakkumised peavad sobima praeguse tokeniga, tundlikud operatsioonid vajavad inimese kontrolli ja iga kutse tuleb serveri poolel valideerida.

Pragmaatiline algus on väike: üks lugemistööriist, kitsas skoop, selge nõusolekutekst, deterministlik tööriistade avastamine ja head logid. Pärast seda saab liita täiendavaid tööriistu, ilma et vestlusbotist saaks must kast. Nii ei saa veebisaidi vestlusbotist mitte kontrollimatu agent, vaid jälgitav assistent, kes tohib kasutada täpselt neid süsteeme, mis on praegusele kasutajale ja praegusele ülesandele kinnitatud.