MCP svetainės pokalbių botams: įrankių prijungimas naudojant OAuth ir patvirtinimus

MCP suteikia svetainių pokalbių botams daugiau galimybių – tačiau tik su aiškiomis ribomis

MCP Dirbtinio Intelekto pokalbių botams nėra magiškas kištukas, kuris svetainės botui staiga patikėtų bet kokias sistemas. Model Context Protocol greičiau aprašo bendrą sąsają, per kurią modelis gali atrasti ir iškviesti įrankius: pavyzdžiui, paiešką žinių bazėje, užklausą bilietų sistemoje, susitikimų registravimo logiką ar vidinį patikrinimą pagal produkto duomenis. Svetainių pokalbių botams tai itin patrauklu, nes daugelis dialogų nesibaigia tiesioginiu atsakymu. Lankytojai teiraujasi apie pristatymo būseną, kainas, kontaktus, formas, prieinamumą ar kitus žingsnius. Be įrankių botas gali tik paaiškinti. Su įrankiais jis gali – kontroliuojamai ir atsekamai – gauti svarbius duomenis arba inicijuoti paruoštus veiksmus.

Todėl esminis klausimas yra ne tas, ar pokalbių botas gali naudoti įrankius. Klausimas toks: kokius įrankius jis gali matyti konkrečiame kontekste, su kokiu autorizacijos žetonu (token) juos iškviesti, su kokiu žmogaus patvirtinimu įvykdyti ir su kokiu registravimu (logging) vėliau paaiškinti? Galutinė MCP specifikacija, priimta 2026 m. liepos 28 d., griežtai apibrėžia būtent šiuos eksploatavimo klausimus. Jis paverčia branduolį neturinčiu būsenos (stateless), reikalauja atitinkamų metaduomenų kiekvienai užklausai ir tiksliai nustato, kaip susiję nutolęs HTTP autorizavimas, OAuth, scope'ai ir token-audience susiejimas.

Ką 2026-07-28 specifikacija keičia svetainių kūrėjų komandoms

Svarbiausias architektūrinis pokytis yra būsenos neturintis branduolis (stateless core). MCP serveris negali daryti prielaidos, kad ankstesnės užklausos tuo pačiu ryšiu jau nustatė kontekstą, kliento galimybes ar sesiją. Viska, ko reikia apdorojimui, turi būti pateikta dabartinėje užklausoje. Paskirstytoms svetainių infrastruktūroms tai itin praktiška: užklausos už apkrovos balansuotojų (load balancers), kraštinių vartų (edge gateways) ar vykdytojų platformų gali patekti į skirtingus egzempliorius. Tačiau realizacijai tai reiškia: jokių paslėptų prielaidų apie transportavimo sesijas, jokių tylių teisių iš ankstesnio ryšio ir jokio pokalbio dialogo kaip saugumo ribos.

Kiekvienai užklausai reikalingi atitinkami _meta metaduomenys. Tai visų pirma apima protokolo versiją ir kliento galimybes (client capabilities); kliento informacija yra naudinga atvaizdavimui, registravimui ir derinimui, tačiau netinka kaip saugumo įrodymas. Jei svetainė aptarnauja kelis boto egzempliorius, kalbas ar klientų sritis, šis metaduomenų sluoksnis turėtų būti sąmoningai tikrinamas ir registruojamas. Jis nepakeičia funkcinio autorizavimo, tačiau užtikrina, kad serveris galėtų teisingai klasifikuoti užklausas.

Įrankių sąrašai yra dinamiški, bet ne savavališki

Dabartinėje specifikacijoje tools/list yra puslapiuojamas (paginated) ir podėliuojamas (cacheable). Atsakymuose gali būti talpyklos užuominų, pavyzdžiui, ttlMs ir cacheScope. Kartu tvarka turi išlikti deterministinė, kol nesikeičia pagrindinis įrankių rinkinys. Tai daugiau nei tik našumo kosmetika: kai įrankių katalogai yra stabiliai išrikiuoti, klientai gali juos patikimiau išsaugoti podėlyje, o modelio kontekstai išlieka stabilesni.

Svarbus niuansas yra autorizavimas. Įrankių rinkinys gali skirtis kiekvienai užklausai pagal pateiktą autorizaciją, pavyzdžiui, todėl, kad žetonas leidžia tik skaityti pagalbos duomenis, bet ne suteikia rašymo teisių CRM sistemoje. Tačiau jis negali atsitiktinai svyruoti kaip šalutinis ankstesnių užklausų poveikis per tą patį ryšį. Svetainės pokalbių botams iš to kyla aiškus sablonas: matomas įrankių katalogas formuojamas pagal dabartinės užklausos vaidmenį, scope'ą, nuomininką (tenant), kalbą, kontekstą ir riziką.

Įrankių aprašymai nėra pasitikėjimo pagrindas

MCP įrankiai aprašo savo pavadinimą, įvestis, pasirinktinai išvestis ir anotacijas. Šie metaduomenys padeda modeliui ir vartotojo sąsajai suprasti funkciją. Tačiau jie nėra saugumo garantas. Specifikacijoje aiškiai nurodyta, kad klientai privalo laikyti įrankių anotacijas nepatikimomis, nebent jos gautos iš patikimų serverių. Įrankis, apibūdinamas kaip „tik skaitymui“, vis tiek turi būti suprojektuotas serverio pusėje taip, kad neatliktų jokių rašymo šalutinių poveikių.

Tai galioja ir struktūrizuotiems rezultatams. outputSchema padeda patikrinti atsakymus, o ne tik perduoti laisvą tekstą modeliui. Nepaisant to, serveriai privalo tikrinti įvestis, kontroliuoti prieigą, nustatyti užklausų ribojimus (rate limits) ir valyti išvestis. Svetainės pokalbių botas neturėtų nekontroliuojamai perkelti įrankių rezultatų į matomus atsakymus, ypač jei susijusios išorinės API, klientų duomenys ar turinys, artimas HTML.

OAuth: MCP serveris yra apsaugotas resursas

Remote-HTTP-MCP atveju vaidmenų paskirstymas yra lemiamas. Apsaugotas MCP serveris veikia kaip OAuth resursų serveris (Resource Server). MCP klientas veikia resurso savininko (Resource Owner) vardu, t. y. paprastai vartotojo arba organizacijos. Autorizavimo serveris (Authorization Server) prireikus sąveikauja su vartotoju ir išduoda prieigos žetonus (Access Tokens). MCP serveris turi pateikti savo „Protected Resource Metadata“, kad klientai galėtų atrasti tinkamą autorizavimo serverį. Autorizavimo serveris turi pateikti bent vieną iš atradimo procedūrų: „OAuth Authorization Server Metadata“ arba „OpenID Connect Discovery“; MCP klientas privalo palaikyti abu.

Produktų komandoms tai reiškia: pats pokalbių botas neturėtų tvarkyti slaptažodžių, API raktų ar svetimų žetonų, jei numatytas OAuth srautas. Jis turėtų nukreipti vartotoją prie aiškaus patvirtinimo, vėliau naudoti tikslinį prieigos žetoną ir matomai apriboti juo leidžiamus įrankius. Klientų registravimui pirmenybė teikiama „Client ID Metadata Documents“; „Dynamic Client Registration“ paliktas tik dėl atgalinio suderinamumo ir yra nenaudotinas (deprecated). Ypač integruojant tokias sistemas kaip kalendorius, CRM, pagalbos tarnyba, dokumentų saugykla ar e-parduotuvės sistemos, šis atskyrimas yra svarbus, nes tas pats pokalbis dažnai pereina nuo viešų klausimų prie nuo paskyros priklausančių veiksmų.

Žetonai privalo būti susieti su tiksliniu resursu

Dabartinė autorizavimo specifikacija reikalauja naudoti resurso indikatorius pagal RFC 8707. Klientas autorizavimo ir žetonų užklausose privalo nustatyti parametrą resource, nurodydamas kanoninį MCP serverio URI, kuriam skirtas žetonas. MCP serveris privalo patikrinti, ar prieigos žetonas buvo išduotas būtent jo resursui. Žetonai negali būti perduodami per užklausos eilutę (query string) – jie priklauso Authorization antraštei.

Šis Auditorijos susiejimas (Audience binding) užkerta kelią pavojingam trumpinimui: žetonas, skirtas paslaugai A, negali būti priimtas ar perduotas paslaugai B. Todėl svetainės pokalbių botams reikalinga švari žetonų riba kiekvienam MCP serveriui ir kiekvienai aplinkai. Peržiūros (Preview), testavimo (Staging) ir gamybinė (Production) aplinkos neturėtų naudoti tos pačios auditorijos, jei jos atstovauja skirtingus resursus. Taip pat agregatorius, jungiantis kelis MCP serverius priešais modelį, neturėtų maišyti žetonų.

Scope'ai yra UX ir saugumo susitarimas

Scope'ai turėtų prasidėti nuo kuo mažesnių teisių. Specifikacija rekomenduoja naudoti scope'ų užuominas iš WWW-Authenticate iššūkių ir, trūkstant teisių, leisti taikyti teisių išplėtimo srautą (Step-up flow). Praktiškai tai reiškia: lankytojas iš pradžių gali dirbti su įrankiais, skirtais tik skaitymui. Tik tada, kai veiksmui reikia daugiau teisių – pavyzdžiui, sukurti bilietą, įrašyti failą ar paruošti užsakymą – sistema tikslingai paprašo papildomo patvirtinimo.

Geras sutikimo lango (Consent) dizainas nurodo ne tik integracijos pavadinimą, bet ir poveikį: kokie duomenys bus skaitomi? Koks veiksmas ruošiamas? Ar kas nors bus išsaugota išorėje, išsiųsta ar visam laikui pakeista? Jautrioms operacijoms vartotojas turėtų matyti tikrą patvirtinimą ir turėti galimybę atsisakyti. Tai nėra individuali teisinė konsultacija, o techninė projektavimo taisyklė: patvirtinimai turi būti suprantami žmonėms, užtikrinami serveriuose ir atsekami audito metu.

Patikima architektūra svetainės pokalbių botams su MCP

Tvirta architektūra atskiria modelį, įrankių fasadą ir tikslines sistemas. Svetainės pokalbių botas nebendrauja tiesiogiai su kiekvienu trečiosios šalies teikėju, o su MCP klientu arba vartais (gateway), kurie kontroliuoja protokolo versiją, kliento galimybes, autorizacijos būseną, užklausų ribojimus ir stebimumą (observability). Už jų yra MCP serveriai atskiroms integracijoms arba funkcinėms sritims. Kiekvienas serveris deklaruoja tik tuos įrankius, kurie yra leidžiami dabartinei užklausai, ir iš naujo patikrina kiekvieną iškvietimą.

Įrankių fasadas turėtų naudoti stabilius pavadinimus, griežtas įvesties schemas ir aiškias išvesties schemas. Įrankių pavadinimai turi būti pakankamai unikalūs, ypač jei keli serveriai siūlo panašias funkcijas, pavyzdžiui, search, create arba lookup. Agregavimo atveju padeda vardų erdvė arba priešdėlis. Parametrai turėtų būti suprojektuoti taip, kad modeliui nereikėtų išgalvoti slaptų neapdorotų duomenų. Jei procesas vyksta per kelias užklausas, serveris turėtų grąžinti aiškią, trumpalaikę rankenėlę (handle) ir iš naujo autorizuoti ją su kiekvienu vėlesniu iškvietimu.

Antrasis komponentas yra vartotojo sąsaja. Lankytojai turėtų matyti, kai iškviečiamas įrankis, kokios įvestys siunčiamos ir kada reikalingas patvirtinimas. Tik skaitymo prieigai dažnai pakanka skaidrios būsenos. Rašymo, mokamoms, išorinėms ar asmens duomenų operacijoms reikia sąmoningo patvirtinimo. Specifikacija palieka sąsajos modelius atvirus, tačiau aiškiai reikalauja, kad programos sudarytų sąlygas žmogaus kontrolei atliekant įrankių iškvietimus.

MCP įdiegimo atmintinė Dirbtinio Intelekto pokalbių botams

1. Sukurti įrankių inventorių: kokias sistemas reikia prijungti, kurie įrankiai skirti tik skaitymui, kurie keičia duomenis ir kuriems reikia žmogaus patvirtinimo?
2. Apibrėžti scope'us: suskirstykite teises pagal veiksmus, o ne pagal vidines komandas. Būsenos užklausų įrankiui reikia kitokių scope'ų nei įrankiui, skirtam kurti, keisti ar siųsti.
3. Patikrinti OAuth atradimą: ištestuokite „Protected Resource Metadata“, „Authorization Server Metadata“, klientų registraciją ir nukreipimo URI kiekvienoje aplinkoje.
4. Užtikrinti Auditorijos susiejimą: priimkite žetonus tik kanoniniam MCP serverio URI, niekada neperduokite jų neteisingiems resursams ir nedėkite į URL.
5. Padaryti tools/list deterministiniu: kartu ištestuokite stabilų rūšiavimą, puslapiavimą, podėlio užuominas ir autorizacijos filtrus.
6. Užtikrinti griežtas schemas: tikrinkite įvestis, naudokite struktūrizuotas išvestis ir pagal numatytuosius nustatymus išjunkite automatinį išorinių $ref tikslų užkrovimą tinklu; pasirinktinai naudokite tik su baltuoju sąrašu (allowlist), laiko limitu (timeout), dydžio ribojimu ir registravimu.
7. Sukurti patvirtinimus sąsajoje: padarykite matomus įrankio pavadinimą, tikslą, įvestis, tikslinę sistemą, scope išplėtimą ir atsisakymo galimybę.
8. Įtvirtinti stebimumą (observability): registruokite užklausos ID, įrankio pavadinimą, scope'ą, sprendimą, klaidas, vėlinimą ir rezultato tipą, be reikalo nesaugodami jautraus turinio.
9. Išbandyti klaidų scenarijus: 401, 403, pasibaigusio galiojimo žetonus, trūkstamus scope'us, nežinomas rankenėles (handles), laiko limitus ir atmestus patvirtinimus laikykite įprastomis produkto būsenomis.
10. Pradėti nuo mažų žingsnių: iš pradžių paleiskite vieną ar du mažos rizikos skaitymo įrankius, vėliau laipsniškai pridėkite teisių išplėtimą (Step-up), rašymo veiksmus ir kitas integracijas.

Dažniausios įgyvendinimo klaidos

Dažniausia klaida – per platus pirmasis žetonas. Jei svetainės pokalbių botas po pirmojo prisijungimo iškart gauna plačias rašymo teises, kiekvienas modelio sprendimas tampa rizikingesnis. Geriau naudoti minimalų pradinį scope'ą su tikslingu teisių išplėtimu. Antroji klaida – įrankių katalogas, sudarytas iš vidinių sistemų pavadinimų, o ne iš vartotojo tikslų. Modelis dirba patikimiau su aiškiais, siaurai aprašytais veiksmais nei su bendriniais universalios paskirties galiniais punktais (endpoints).

Trečioji klaida – atskirties trūkumas tarp pasitikėjimo modeliu ir pasitikėjimo serveriu. Modelis gali pasiūlyti veiksmą, tačiau serveris nusprendžia, ar įvestys yra teisingos, ar žetonas tinka ir ar gautas patvirtinimas. Ketvirtoji klaida – atsekamumo trūkumas. Jei vėliau neaišku, kuris įrankis su kokiu scope'u kokius duomenis perskaitė ar pakeitė, neįmanoma užtikrinti nei tinkamo palaikymo, nei saugumo.

Gilesnės įžvalgos

Šiame straipsnyje nagrinėjamas MCP integracijos sluoksnis: būsenos neturintis branduolis, tools/list ir HTTP OAuth. Šie straipsniai išsamiau paaiškina bendrąjį įrankių saugumą ir eksploatavimą: Teisių modeliui tinka KI-Chatbots: Tools sicher mit Rechten und Bestätigungen nutzen. Norint saugiai projektuoti konkrečius įrankių iškvietimus, verta paskaityti KI-Chatbot-Tool-Aufrufe sicher gestalten. Jei įrankių rezultatai turi išlikti nuskaitomi mašininiu būdu, tinka Strukturierte KI-Chatbot-Ausgaben validieren. Eksploatavimui ir klaidų paieškai techninis tęsinys yra KI-Chatbot-Observability für Traces, Retrieval und Tools.

Oficialūs šaltiniai

Techninis pagrindas yra galutinė MCP specifikacija 2026-07-28: puslapis apie MCP Tools, MCP Authorization, oficialus straipsnis The 2026-07-28 Specification ir Base Protocol Overview.

Išvada

MCP Dirbtinio Intelekto pokalbių botams tampa vertingu tada, kai svetainių komandos jį supranta ne kaip atvirą įrankių dėžę, o kaip kontroliuojamą integracijos sluoksnį. 2026-07-28 specifikacija puikiai tinka šiuolaikinei svetainių infrastruktūrai: būsenos neturinčios užklausos, podėliuojami sąrašai, nukreipiamos HTTP antraštės ir aiškus autorizavimas kiekvienam resursui. Kartu ji dar labiau išryškina atsakomybę. Įrankių pasiūlymai turi atitikti dabartinį žetoną, jautrioms operacijoms reikalinga žmogaus kontrolė, o kiekvienas iškvietimas turi būti patikrintas serverio pusėje.

Pragmatiška pradžia yra maža: vienas skaitymo įrankis, siauras scope'as, aiškus sutikimo tekstas, deterministinis įrankių atradimas ir geri žurnalai (logs). Vėliau galima prijungti daugiau įrankių, pokalbių botui netampant „juodąja dėže“. Taip iš svetainės pokalbių boto sukuriamas ne nekontroliuojamas agentas, o atsekamas asistentas, kuriam leidžiama naudoti tik tas sistemas, kurios yra patvirtintos dabartiniam vartotojui ir dabartinei užduočiai.