MCP tīmekļa vietņu tērzēšanas botiem: rīku pieslēgšana ar OAuth un apstiprinājumiem

MCP padara tīmekļa vietņu tērzēšanas botus rīcībspējīgākus — taču tikai ar skaidrām robežām

MCP mākslīgā intelekta tērzēšanas botiem nav nekāds brīnumspraudnis, kas tīmekļa vietnes botam pēkšņi uztic jebkuras sistēmas. Model Context Protocol drīzāk apraksta kopīgu saskarni, caur kuru modelis var atklāt un izsaukt rīkus: piemēram, meklēšanu zināšanu bāzē, biļešu pieprasījumu, tikšanās loģiku vai iekšēju pārbaudi pret produktu datiem. Tīmekļa vietņu tērzēšanas botiem tas ir īpaši pievilcīgi, jo daudzi dialogi nebeidzas ar vienu atbildi. Apmeklētāji jautā par piegādes statusu, cenām, saziņas veidiem, veidlapām, pieejamību vai nākamajiem soļiem. Bez rīkiem botam ir jāpaskaidro. Ar rīkiem tas var kontrolēti un izsekojami iegūt pamatotus datus vai ierosināt sagatavotas darbības.

Tāpēc izšķirošais jautājums nav: vai tērzēšanas bots var izmantot rīkus? Jautājums ir: kādus rīkus tas drīkst redzēt kādā kontekstā, ar kādu pilnvaru (token) izsaukt, ar kādu cilvēka apstiprinājumu izpildīt un ar kādu žurnalēšanu vēlāk paskaidrot? Galīgā MCP specifikācija no 2026. gada 28. jūlija saasina tieši šos ekspluatācijas jautājumus. Tā padara kodolu bezstāvokļa (stateless), pieprasa atbilstošus metadatus par katru pieprasījumu un precizē, kā ir saistīta attālinātā HTTP autorizācija, OAuth, apjomi (scopes) un pilnvaru auditorijas sasaiste (token audience binding).

Ko 2026-07-28 specifikācija maina tīmekļa vietņu izstrādātājiem

Svarīgākā arhitektūras izmaiņa ir bezstāvokļa kodols (stateless core). MCP serveris nedrīkst pieņemt, ka iepriekšējie pieprasījumi tajā pašā savienojumā jau ir izveidojuši kontekstu, klienta iespējas vai sesiju. Visam, kas nepieciešams apstrādei, jābūt pašreizējā pieprasījumā. Sadalītām tīmekļa infrastruktūrām tas ir praktiski: pieprasījumi aiz slodzes līdzsvarotājiem, robežvārtiem (edge gateways) vai darbinieku platformām var nonākt dažādās instancēs. Taču realizācijai tas nozīmē arī: nekādu slēptu pieņēmumu par transporta sesijām, nekādu klusu tiesību no iepriekšējā savienojuma un nekādu tērzēšanas sarunu kā drošības robežu.

Katram pieprasījumam ir nepieciešami obligātie _meta metadati. Pie tiem pieder jo īpaši protokola versija un klienta iespējas (capabilities); klienta informācija ir noderīga attēlošanai, žurnalēšanai un atkļūdošanai, bet nav piemērota kā drošības pierādījums. Ja tīmekļa vietne apkalpo vairākas bota instances, valodas vai klientu zonas, šis metadatu slānis apzināti jāpārbauda un jāreģistrē žurnālā. Tas neaizstāj funkcionālo autorizāciju, bet nodrošina, ka serveris var pareizi klasificēt pieprasījumus.

Rīku saraksti ir dinamiski, bet nav patvaļīgi

tools/list pašreizējā specifikācijā ir sadalīts lappusēs (paginated) un kešojams. Atbildēs var būt kešatmiņas norādes, piemēram, ttlMs un cacheScope. Tajā pašā laikā secībai jāpaliek deterministiskai, kamēr nemainās pamatā esošais rīku kopums. Tas ir kas vairāk par veiktspējas uzlabošanu: ja rīku katalogi ir stabili sakārtoti, klienti var tos uzticamāk kešot un modeļa konteksti paliek mierīgāki.

Svarīga ir autorizācijas nuance. Rīku kopums katram pieprasījumam drīkst atšķirties atkarībā no uzrādītās autorizācijas, piemēram, tāpēc, ka pilnvara dod tikai lasīšanas tiesības atbalsta datos, bet nedod rakstīšanas tiesības CRM. Tomēr tas nedrīkst nejauši svārstīties kā blakusparādība no iepriekšējiem pieprasījumiem tajā pašā savienojumā. Tīmekļa vietņu tērzēšanas botiem no tā izriet skaidrs paraugs: redzamais rīku katalogs veidojas no pašreizējā pieprasījuma lomas, apjoma (scope), klienta/nomnieka, valodas, konteksta un riska.

Rīku apraksti nav uzticības pamats

MCP rīki apraksta savu nosaukumu, ievadi, pēc izvēles arī izvadi un anotācijas. Šie metadati palīdz modelim un lietotāja saskarnei saprast funkciju. Tomēr tie nav drošības enkurs. Specifikācijā skaidri teikts, ka klientiem rīku anotācijas jāuztver kā neuzticamas, ja vien tās nenāk no uzticamiem serveriem. Rīkam, kas sevi apraksta kā tikai lasāmu, servera pusē joprojām jābūt izveidotam tā, lai tas neveiktu nekādas rakstīšanas blakusparādības.

Tas attiecas arī uz strukturētiem rezultātiem. outputSchema palīdz validēt atbildes, nevis vienkārši nodot modelim brīvu tekstu. Neraugoties uz to, serveriem ir jāpārbauda ievade, jākontrolē piekļuve, jānosaka ātruma ierobežojumi (rate limits) un jāattīra izvade. Tīmekļa vietnes tērzēšanas botam nevajadzētu pārņemt rīku rezultātus redzamajās atbildēs nefiltrētā veidā, jo īpaši, ja ir iesaistītas ārējās API, klientu dati vai HTML līdzīgs saturs.

OAuth: MCP serveris ir aizsargāts resurss

Izmantojot Remote-HTTP-MCP, lomu sadalījums ir izšķirošs. Aizsargāts MCP serveris darbojas kā OAuth resursu serveris (Resource Server). MCP klients rīkojas resursa īpašnieka (Resource Owner) vārdā, t.i., parasti lietotāja vai organizācijas vārdā. Autorizācijas serveris mijiedarbojas ar lietotāju, ja nepieciešams, un izsniedz piekļuves pilnvaras (Access Tokens). MCP serverim ir jānodrošina savi Protected Resource Metadata, lai klienti varētu atklāt atbilstošo autorizācijas serveri. Autorizācijas serveris nodrošina vismaz vienu no atklāšanas procedūrām: OAuth Authorization Server Metadata vai OpenID Connect Discovery; MCP klientam ir jāatbalsta abas.

Produktu komandām tas nozīmē: tērzēšanas botam pašam nevajadzētu pārvaldīt paroles, API atslēgas vai svešas pilnvaras, ja ir paredzēta OAuth plūsma. Tam vajadzētu novest lietotāju pie skaidra apstiprinājuma, pēc tam izmantot mērķtiecīgu piekļuves pilnvaru un redzami ierobežot ar to atļautos rīkus. Klientu reģistrācijai priekšroka dodama Client ID Metadata Documents; dinamiskā klientu reģistrācija (Dynamic Client Registration) tiek saglabāta tikai atpakaļejošas savietojamības dēļ un ir novecojusi (deprecated). Šāda nošķiršana ir svarīga īpaši tādās integrācijās kā kalendārs, CRM, palīdzības dienests, dokumentu glabātuve vai e-komercijas sistēmas, jo viena un tā pati saruna bieži mainās starp publiskiem jautājumiem un no konta atkarīgām darbībām.

Pilnvarām jābūt piesaistītām mērķa resursam

Pašreizējā autorizācijas specifikācija pieprasa resursu indikatorus saskaņā ar RFC 8707. Klientam autorizācijas un pilnvaru pieprasījumos ir jāiestata parametrs resource, norādot MCP servera kanonisko URI, kuram pilnvara ir paredzēta. MCP serverim ir jāpārbauda, vai piekļuves pilnvara ir izsniegta tieši tā resursam. Pilnvaras nedrīkst nodot caur URL vaicājuma virkni (query string), tām jāatrodas Authorization galvenē.

Šī auditorijas piesaiste (audience binding) novērš bīstamu īsceļu izmantošanu: pilnvaru, kas paredzēta pakalpojumam A, nedrīkst pieņemt vai nodot tālāk pakalpojumam B. Tāpēc tīmekļa vietņu tērzēšanas botiem ir nepieciešama tīra pilnvaru robeža katram MCP serverim un katrai videi. Priekšskatījuma (preview), izstrādes (staging) un ražošanas (production) vidēm nevajadzētu izmantot vienu un to pašu auditoriju, ja tās attēlo dažādus resursus. Tāpat agregators, kas apvieno vairākus MCP serverus modeļa priekšā, nedrīkst sajaukt pilnvaras.

Apjomi (scopes) ir UX un drošības līgums

Apjomiem (scopes) vajadzētu sākties maziem. Specifikācijā ieteikts izmantot apjoma norādes no WWW-Authenticate izaicinājumiem un tiesību trūkuma gadījumā atļaut pakāpenisku tiesību palielināšanas plūsmu (step-up flow). Praktiski tas nozīmē: apmeklētājs vispirms var strādāt ar lasīšanas rīkiem. Tikai tad, kad darbībai nepieciešamas papildu tiesības, piemēram, izveidot biļeti, ierakstīt failu vai sagatavot pasūtījumu, sistēma mērķtiecīgi lūdz papildu apstiprinājumu.

Labs piekrišanas dizains nosauc ne tikai integrācijas nosaukumu, bet arī ietekmi: kādi dati tiek lasīti? Kāda darbība tiek sagatavota? Vai kaut kas tiek glabāts, nosūtīts vai pastāvīgi mainīts ārēji? Sensitīvām operācijām lietotājam vajadzētu redzēt reālu apstiprinājumu un iespēju to noraidīt. Tās nav individuālas juridiskas konsultācijas, bet gan tehnisks izstrādes noteikums: apstiprinājumiem jābūt cilvēkiem saprotamiem, serveriem izpildāmiem un auditēšanai izsekojamiem.

Izturīga arhitektūra tīmekļa vietņu tērzēšanas botiem ar MCP

Uzticama arhitektūra nošķir modeli, rīku fasādi un mērķa sistēmas. Tīmekļa vietnes tērzēšanas bots nesazinās tieši ar katru trešās puses pakalpojumu sniedzēju, bet gan ar MCP klientu vai vārtiem (gateway), kas kontrolē protokola versiju, klienta iespējas, autorizācijas statusu, ātruma ierobežojumus un novērojamību (observability). Aiz tiem atrodas MCP serveri atsevišķām integrācijām vai funkcionālajām jomām. Katrs serveris deklarē tikai tos rīkus, kas ir atļauti pašreizējam pieprasījumam, un no jauna validē katru izsaukumu.

Rīku fasādei jāizmanto stabili nosaukumi, šauri ievades shēmas un skaidras izvades shēmas. Rīku nosaukumiem jābūt pietiekami unikāliem, jo īpaši, ja vairāki serveri piedāvā līdzīgas funkcijas, piemēram, search, create vai lookup. Apvienošanas gadījumā palīdz nosaukumvieta (namespace) vai prefikss. Parametriem jābūt veidotiem tā, lai modelim nebūtu jāizdomā neapstrādāti konfidenciāli dati. Ja process ilgst vairākus pieprasījumus, serverim jāatgriež eksplodēts, īslaicīgs rokturis (handle) un tas no jauna jāautorizē katrā nākamajā izsaukumā.

Otrs būvbloks ir lietotāja saskarne. Apmeklētājiem būtu jāredz, kad tiek izsaukts rīks, kāda ievade tiek nosūtīta un kad ir nepieciešams apstiprinājums. Tikai lasīšanas piekļuvei bieži pietiek ar caurspīdīgu statusu. Rakstīšanas, maksas, ārējām vai personas datu darbībām ir nepieciešams apzinātāks apstiprinājums. Specifikācija atstāj lietotāja saskarnes paraugus atvērtus, taču skaidri pieprasa, lai lietojumprogrammas nodrošinātu cilvēka kontroli pār rīku izsaukumiem.

MCP ieviešanas kontrolsaraksts mākslīgā intelekta tērzēšanas botiem

1. Izveidot rīku inventarizāciju: kuras sistēmas ir jāpieslēdz, kuri rīki ir tikai lasāmi, kuri maina datus un kuriem nepieciešams cilvēka apstiprinājums?
2. Definēt apjomus (scopes): sadalīt tiesības pēc darbībām, nevis pēc iekšējām komandām. Rīkam statusa vaicājumiem ir nepieciešami citādi apjomi nekā rīkam izveidei, mainīšanai vai nosūtīšanai.
3. Pārbaudīt OAuth atklāšanu: testēt Protected Resource Metadata, Authorization Server Metadata, klientu reģistrāciju un pāradresācijas URI katrai videi.
4. Nodrošināt auditorijas piesaisti: pieņemt pilnvaras tikai kanoniskajam MCP servera URI, nekad nenodot tās nepareiziem resursiem un nekad neievietot URL.
5. Padarīt tools/list deterministisku: kopā testēt stabilu kārtošanu, lappušu dalīšanu, kešatmiņas norādes un autorizācijas filtrus.
6. Uzturēt shēmas šauras: validēt ievadi, izmantot strukturētas izvades un pēc noklusējuma atspējot ārējo $ref mērķu automātisku ielādi no tīkla; pēc izvēles atļaut tikai ar balto sarakstu, noildzi, izmēra ierobežojumu un žurnalēšanu.
7. Izveidot apstiprinājumus lietotāja saskarnē: padarīt redzamu rīka nosaukumu, mērķi, ievadi, mērķa sistēmu, apjoma uzlabošanu un noraidīšanas iespēju.
8. Nostiprināt novērojamību (observability): reģistrēt pieprasījuma ID, rīka nosaukumu, apjomu, lēmumu, kļūdu, aizturi un rezultāta veidu, nevajadzīgi nesaglabājot sensitīvu saturu.
9. Praktizēt kļūdu ceļus: apstrādāt 401, 403, beidzies pilnvaras derīguma termiņš, trūkstošus apjomus, nezināmus rokturus, noildzes un noraidītus apstiprinājumus kā normālus produkta stāvokļus.
10. Sākt pamazām: vispirms palaist reāllaikā vienu vai divus zema riska lasīšanas rīkus, pēc tam pakāpeniski pievienot tiesību palielināšanu (step-up), rakstīšanas darbības un citas integrācijas.

Biežākās kļūdas realizācijā

Visbiežākā kļūda ir pārāk plaša pirmatnējā pilnvara. Ja tīmekļa vietnes tērzēšanas bots pēc pirmās pieteikšanās uzreiz saņem visaptverošas rakstīšanas tiesības, katrs modeļa lēmums kļūst riskantāks. Labāk ir izmantot minimālu sākuma apjomu ar mērķtiecīgu tiesību palielināšanu. Otrā kļūda ir rīku katalogs, kas sastāv no iekšējiem sistēmu nosaukumiem, nevis lietotāja nodomiem. Modelis darbojas uzticamāk ar skaidrām, šauri aprakstītām darbībām nekā ar vispārīgiem universāliem galapunktiem (endpoints).

Trešā kļūda ir nošķiršanas trūkums starp uzticēšanos modelim un uzticēšanos serverim. Modelis drīkst ierosināt darbību, bet serveris izlemj, vai ievades dati ir derīgi, vai pilnvara ir atbilstoša un vai ir saņemts apstiprinājums. Ceturtā kļūda ir izsekojamības trūkums. Ja vēlāk nav skaidrs, kurš rīks ar kādu apjomu kādus datus ir nolasījis vai mainījis, ne atbalstu, ne drošību nevar nodrošināt pienācīgi.

Papildu materiāli padziļināšanai

Šajā rakstā aplūkots MCP integrācijas slānis: bezstāvokļa kodols, tools/list un HTTP-OAuth. Šie raksti padziļina vispārējo rīku drošību un darbību: Pilnvaru modelim ir piemērots raksts Mākslīgā intelekta tērzēšanas boti: droša rīku izmantošana ar tiesībām un apstiprinājumiem. Konkrētiem rīku izsaukumiem ir vērts izlasīt Droša mākslīgā intelekta tērzēšanas bota rīku izsaukumu izstrāde. Ja rīku rezultātiem jāpaliek mašīnlasāmiem, noderēs Strukturētu mākslīgā intelekta tērzēšanas bota izvadu validēšana. Darbībai un kļūmju novēršanai tehniskais turpinājums ir Mākslīgā intelekta tērzēšanas botu novērojamība izsekošanai, izgūšanai un rīkiem.

Oficiālie avoti

Tehniskais pamats ir galīgā MCP specifikācija 2026-07-28: lapa par MCP Tools, MCP Authorization, oficiālais raksts The 2026-07-28 Specification un Base Protocol Overview.

Secinājums

MCP mākslīgā intelekta tērzēšanas botiem kļūst vērtīgs tad, ja tīmekļa vietņu izstrādātāju komandas to uztver nevis kā atvērtu rīku kasti, bet gan kā kontrolētu integrācijas slāni. Specifikācija 2026-07-28 labi atbilst mūsdienu tīmekļa infrastruktūrai: bezstāvokļa pieprasījumi, kešojami saraksti, maršrutējamas HTTP galvenes un eksplicitēta autorizācija katram resursam. Vienlaikus tā skaidrāk definē atbildību. Rīku piedāvājumam jāatbilst pašreizējai pilnvarai, sensitīvām operācijām ir nepieciešama cilvēka kontrole, un katram izsaukumam jābūt validētam servera pusē.

Pragmatisks sākums ir mazs: viens lasīšanas rīks, šaurs apjoms (scope), skaidrs piekrišanas teksts, deterministiska rīku atklāšana un labi žurnāli. Pēc tam var pieslēgt papildu rīkus, tērzēšanas botam nekļūstot par "melno kasti". Tādējādi tīmekļa vietnes tērzēšanas bots nepārtop par nekontrolētu aģentu, bet gan par izsekojamu asistentu, kas drīkst izmantot tieši tās sistēmas, kuras ir apstiprinātas pašreizējam lietotājam un pašreizējam uzdevumam.