MCP pre webových chatbotov: Pripojenie nástrojov cez OAuth a povolenia

MCP zvyšuje akčnosť webových chatbotov – ale len s jasnými hranicami

MCP pre AI chatbotov nie je čarovný konektor, ktorý webovému chatbotu zničoho nič zverí ľubovoľné systémy. Model Context Protocol popisuje skôr spoločné rozhranie, cez ktoré môže model objavovať a vyvolávať nástroje: napríklad vyhľadávanie v znalostnej báze, kontrolu tiketu, logiku rezervácie termínov alebo interné overenie voči produktovým dátam. Pre webových chatbotov je to obzvlášť atraktívne, pretože mnohé konverzácie sa nekončia jednou odpoveďou. Návštevníci sa pýtajú na stav doručenia, ceny, kontakty, formuláre, dostupnosť alebo ďalšie kroky. Bez nástrojov musí bot veci len vysvetľovať. S nástrojmi dokáže – kontrolovane a sledovateľne – získať relevantné dáta alebo spustiť pripravené akcie.

Kľúčová otázka preto neznie: Dokáže chatbot používať nástroje? Otázka znie: Ktoré nástroje smie vidieť v akom kontexte, s akým tokenom ich vyvolávať, s akým ľudským schválením ich spúšťať a s akým protokolovaním ich neskôr vysvetliť? Finálna špecifikácia MCP zo 28. júla 2026 sprísňuje práve tieto prevádzkové otázky. Robí jadro bezstavovým (stateless), vyžaduje relevantné metadáta na požiadavku a presne definuje, ako spolu súvisia vzdialená HTTP autorizácia, OAuth, rozsahy (scopes) a väzba tokenu na cieľové publikum (audience binding).

Čo špecifikácia 2026-07-28 mení pre webové tímy

Najdôležitejšou architektonickou zmenou je bezstavové jadro (stateless core). MCP server nesmie predpokladať, že predchádzajúce požiadavky v rámci rovnakého spojenia už vytvorili kontext, schopnosti klienta (capabilities) alebo reláciu (session). Všetko potrebné na spracovanie musí byť v aktuálnej požiadavke. Pre distribuované webové infraštruktúry je to praktické: požiadavky môžu za load balancermi, edge bránami alebo worker platformami dopadať na rôzne inštancie. Pre implementácie to však znamená aj: žiadne skryté predpoklady o transportných reláciách, žiadne tiché práva z predošlého spojenia a žiadne chápanie četovej konverzácie ako bezpečnostnej hranice.

Každá požiadavka vyžaduje potrebné metadáta _meta. Sem patrí najmä verzia protokolu a schopnosti klienta (capabilities); informácie o klientovi sú užitočné pre zobrazenie, logovanie a ladenie (debugging), ale neslúžia ako bezpečnostný dôkaz. Ak web obsluhuje viacero inštancií botov, jazykov alebo zákazníckych zón, táto metadátová vrstva by mala byť vedome validovaná a zaznamenávaná. Nenahrádza odbornú autorizáciu, ale zabezpečuje, aby server dokázal požiadavky správne zaradiť.

Zoznamy nástrojov sú dynamické, ale nie ľubovoľné

tools/list je v aktuálnej špecifikácii stránkovaný a cachovateľný. Odpovede môžu obsahovať návedia pre cache ako ttlMs a cacheScope. Zároveň by malo poradie zostať deterministické, pokiaľ sa nezmení základná množina nástrojov. To je viac než len kozmetika výkonu: Ak sú katalógy nástrojov stabilne zoradené, klienti ich môžu spoľahlivejšie ukladať do vyrovnávacej pamäte a kontexty modelov zostávajú stabilnejšie.

Dôležitá je nijansa pri autorizácii. Množina nástrojov sa môže v rámci požiadavky meniť na základe predloženej autorizácie, napríklad preto, že token povoľuje iba práva na čítanie podporných dát, ale nie práva na zápis do CRM. Nesmie však náhodne kolísať ako vedľajší efekt predchádzajúcich požiadavkách v rovnakom spojení. Pre webových chatbotov z toho vyplýva jasný vzor: Viditeľný katalóg nástrojov vzniká z roly, rozsahu (scope), nájomcu (tenant), jazyka, kontextu a rizika aktuálnej požiadavky.

Popisy nástrojov nie sú základom dôvery

MCP nástroje popisujú svoj názov, vstupy, voliteľne výstupy a anotácie. Tieto metadáta pomáhajú modelu a používateľskému rozhraniu pochopiť funkciu. Nie sú však bezpečnostným ukotvením. Špecifikácia jasne uvádza, že klienti musia s anotáciami nástrojov zaobchádzať ako s nedôveryhodnými, pokiaľ nepochádzajú z dôveryhodných serverov. Nástroj, ktorý sám seba popisuje ako „iba na čítanie“, musí byť na strane servera aj tak postavený tak, aby nevykonával žiadne zapisovacie vedľajšie účinky.

Platí to aj pre štruktúrované výsledky. Schéma outputSchema pomáha validovať odpovede a neposkytovať modelu len voľný text. Server napriek tomu musí kontrolovať vstupy, riadiť prístup, nastavovať obmedzenia počtu požiadaviek (rate limits) a čistiť výstupy. Webový chatbot by nemal preberať výsledky nástrojov do viditeľných odpovedí nefiltrovane, najmä ak sú zapojené外部 API, zákaznícke dáta alebo obsah blízky HTML.

OAuth: MCP server je chránený zdroj

Pri vzdialenom HTTP MCP je rozdelenie úloh kľúčové. Chránený MCP server vystupuje ako OAuth Resource Server. MCP klient koná v mene vlastníka zdroja (Resource Owner), teda typicky používateľa alebo organizácie. Authorization Server interaguje s používateľom, ak je to potrebné, a vydáva prístupové tokeny (Access Tokens). MCP server musí poskytnúť svoje metadáta chráneného zdroja (Protected Resource Metadata), aby klienti mohli objaviť príslušný Authorization Server. Authorization Server poskytuje aspoň jeden zo spôsobov objavovania (discovery): OAuth Authorization Server Metadata alebo OpenID Connect Discovery; MCP klient musí podporovať oba.

Pre produktové tímy to znamená: Chatbot by nemal sám spravovať heslá, API kľúče ani cudzie tokeny, ak je plánovaný tok OAuth. Mal by používateľa doviesť k jasnému povoleniu, následne použiť účelovo viazaný Access Token a viditeľne obmedziť ním povolené nástroje. Pre registráciu klientov sa dávajú do popredia dokumenty Client ID Metadata Documents; dynamická registrácia klientov (Dynamic Client Registration) zostáva len kvôli spätnej kompatibilite a je zastaraná (deprecated). Najmä pri integráciách ako kalendár, CRM, helpdesk, úložisko dokumentov alebo e-shopové systémy je toto oddelenie dôležité, pretože tá istá konverzácia často prechádza medzi verejnými otázkami a akciami závislými od účtu.

Tokeny musia byť viazané na cieľový zdroj

Aktuálna autorizačná špecifikácia vyžaduje indikátory zdrojov (Resource Indicators) podľa RFC 8707. Klient musí v autorizačných požiadavkách a požiadavkách na token nastaviť parameter resource a zadať tak kanonickú URI MCP servera, pre ktorý je token určený. MCP server musí skontrolovať, či bol Access Token vydaný presne pre jeho zdroj. Tokeny sa nesmú prenášať cez query string, ale patria do hlavičky Authorization.

Túto väzbu na publikum (audience binding) zabraňuje nebezpečnej skratke: Token určený pre službu A sa nesmie akceptovať ani odovzdávať službe B. Weboví chatboti preto potrebujú čistú hranicu tokenov pre každý MCP server a pre každé prostredie. Preview, Staging a Production by nemali používať rovnaké publikum (audience), ak predstavujú rôzne zdroje. Rovnako by agregátor, ktorý spája viacero MCP serverov pred jedným modelom, nemal tokeny miešať.

Rozsahy (scopes) sú zmluvou medzi UX a bezpečnosťou

Rozsahy práva (scopes) by mali začínať v malom. Špecifikácia odporúča použiť informácie o rozsahu z výziev WWW-Authenticate a pri chýbajúcich právach umožniť tok navýšenia (Step-up flow). V praxi to znamená: Návštevník môže najprv pracovať s nástrojmi len na čítanie. Až keď akcia vyžaduje viac práv, napríklad vytvorenie tiketu, zápis do súboru alebo prípravu objednávky, systém sa cielene opýta na dodatočné povolenie.

Dobrý návrh súhlasu (consent design) neuvádza len názov integrácie, ale aj jej účinok: Aké dáta sa čítajú? Aká akcia sa pripravuje? Ukladá sa niečo externe, odosiela sa to alebo trvalo mení? Pri citlivých operáciách by mal používateľ vidieť skutočné potvrdenie a mať možnosť ho odmietnuť. Toto nie je právne poradenstvo, ale technické pravidlo návrhu: Povolenia musia byť pre ľudí zrozumiteľné, pre servery presaditeľné a pre audity sledovateľné.

Odolná architektúra pre webových chatbotov s MCP

Robustná architektúra oddeľuje model, fasádu nástrojov a cieľové systémy. Webový chatbot nekomunikuje priamo s každým poskytovateľom tretej strany, ale s MCP klientom alebo bránou (gateway), ktorá riadi verziu protokolu, schopnosti klienta, stav autentifikácie, obmedzenia požiadaviek (rate limits) a pozorovateľnosť (observability). Za tým ležia MCP servery pre jednotlivé integrácie alebo odborné oblasti. Každý server deklaruje len tie nástroje, ktoré sú povolené pre aktuálnu požiadavku, a každé volanie opätovne validuje.

Fasáda nástrojov by mala používať stabilné názvy, úzke vstupné schémy a jasné výstupné schémy. Názvy nástrojov musia byť dostatočne jednoznačné, najmä ak viacero serverov ponúka podobné funkcie ako search, create alebo lookup. Pri agregácii pomáha menný priestor (namespace) alebo prefix. Parametre by mali byť navrhnuté tak, aby model nemusel vymýšľať tajné surové dáta. Ak proces prebieha cez viacero požiadaviek, server by mal vrátiť explicitný, krátkodobý identifikátor (handle) a pri každom následnom volaní ho opätovne autorizovať.

Druhým stavebným prvkom je používateľské rozhranie. Návštevníci by mali vidieť, keď sa vyvolá nástroj, aké vstupy sa odosielajú a kedy je potrebné povolenie. Pre prístupy čisto na čítanie často postačuje transparentný stav. Pre zápisové, spoplatnené, externe alebo osobné akcie je potrebné uvážlivejšie potvrdenie. Špecifikácia necháva vzory rozhrania otvorené, ale jednoznačne vyžaduje, aby aplikácie umožňovali ľudskú kontrolu nad volaniami nástrojov.

Kontrolný zoznam pre nasadenie MCP pre AI chatbotov

1. Vytvoriť inventár nástrojov: Ktoré systémy sa majú pripojiť, ktoré nástroje sú len na čítanie, ktoré menia dáta a ktoré vyžadujú ľudské potvrdenie?
2. Definovať rozsahy (scopes): Práva rozdeliť podľa akcií, nie podľa interných tímov. Nástroj na zistenie stavu potrebuje iné rozsahy ako nástroj na vytváranie, zmenu alebo odosielanie.
3. Skontrolovať OAuth Discovery: Otestovať Protected Resource Metadata, Authorization Server Metadata, registráciu klientov a URI presmerovania pre každé prostredie.
4. Vynútiť väzbu na publikum (Audience Binding): Akceptovať tokeny len pre kanonickú URI MCP servera, nikdy ich neodovzdávať nesprávnym zdrojom a nikdy ich nevkladať do URL.
5. Spraviť tools/list deterministickým: Spoločne otestovať stabilné triedenie, stránkovanie, návedia cache a autorizačné filtre.
6. Udržať schémy úzke: Validovať vstupy, používať štruktúrované výstupy a predvolene zakázať automatické sieťové načítavanie externých cieľov $ref; voliteľne len s povoleným zoznamom (allowlist), časovým limitom, limitom veľkosti a logovaním.
7. Spracovať povolenia v UI: Zviditeľniť názov nástroja, účel, vstupy, cieľový systém, navýšenie rozsahu (scope upgrade) a možnosť odmietnutia.
8. Ukotviť pozorovateľnosť (observability): Logovať Request-ID, názov nástroja, rozsah, rozhodnutie, chyby, latenciu a typ výsledku bez zbytočného ukladania citlivého obsahu.
9. Nacvičiť chybové cesty: Zaobchádzať s 401, 403, expirovanými tokenmi, chýbajúcimi rozsahmi, neznámymi identifikátormi, časovými limitmi a odmietnutými povoleniami ako s bežnými stavmi produktu.
10. Začať v malom: Najprv spustiť jeden až dva nízkorizikové nástroje na čítanie, potom postupne dopĺňať navýšenie práv (step-up), zapisovacie akcie a ďalšie integrácie.

Typické chyby pri implementácii

Najčastejšou chybou je príliš široký prvý token. Ak webový chatbot dostane po prvom prihlásení okamžite rozsiahle práva na zápis, každé rozhodnutie modelu sa stáva rizikovejším. Lepší je minimálny štartovací rozsah s cieleným navýšením (step-up). Druhou chybou je katalóg nástrojov pozostávajúci z interných názvov systémov namiesto zámerov používateľa. Model pracuje spoľahlivejšie s jasnými, úzko popísanými akciami než s generickými univerzálnymi koncovými bodmi.

Tretou chybou je chýbajúce oddelenie medzi dôverou v model a dôverou v server. Model môže akciu navrhnúť, ale server rozhoduje, či sú vstupy platné, či token sedí a či existuje povolenie. Štvrtou chybou je chýbajúca spätnej sledovateľnosť. Ak neskôr nie je jasné, ktorý nástroj s akým rozsahom čítal alebo menil aké dáta, nie je možné čisto prevádzkovať podporu ani bezpečnosť.

Ďalšie zdroje na štúdium

Tento príspevok sa zaoberá integračnou vrstvou MCP: bezstavové jadro, tools/list a HTTP-OAuth. Nasledujúce články prehlbujú generickú bezpečnosť nástrojov a prevádzku: Pre autorizačný model sa hodí AI chatboti: Bezpečné používanie nástrojov s právami a potvrdeniami. Pre konkrétne volania nástrojov sa oplatí prečítať Bezpečný návrh volaní nástrojov pre AI chatbotov. Ak majú výsledky nástrojov zostať strojovo čitateľné, pozrite si Validácia štruktúrovaných výstupov AI chatbotov. Pre prevádzku a riešenie problémov je technickým pokračovaním Pozorovateľnosť AI chatbotov pre stopy, načítanie a nástroje.

Oficiálne zdroje

Odborným základom je finálna špecifikácia MCP 2026-07-28: stránka o MCP Tools, MCP Authorization, oficiálny príspevok The 2026-07-28 Specification a Base Protocol Overview.

Záver

MCP pre AI chatbotov získava hodnotu vtedy, keď ho webové tímy nechápu ako otvorenú krabicu s náradím, ale ako kontrolovanú integračnú vrstvu. Špecifikácia 2026-07-28 sa dobre hodí pre modernú webovú infraštruktúru: bezstavové požiadavky, cachovateľné zoznamy, smerovateľné HTTP hlavičky a explicitná autorizácia pre každý zdroj. Zároveň robí zodpovednosť jasnejšou. Ponuka nástrojov musí zodpovedať aktuálnemu tokenu, citlivé operácie vyžadujú ľudskú kontrolu a každé volanie musí byť validované na strane servera.

Pragmatický začiatok je malý: jeden nástroj na čítanie, úzky rozsah, jasný text súhlasu, deterministické objavovanie nástrojov a dobré logy. Následne možno pripájať ďalšie nástroje bez toho, aby sa chatbot stal neprehľadnou čiernou skrinkou. Z webového chatbota tak nevznikne nekontrolovaný agent, ale sledovateľný asistent, ktorý smie používať presne tie systémy, ktoré sú schválené pre aktuálneho používateľa a aktuálnu úlohu.