MCP pro webové chatboty: Připojení nástrojů pomocí OAuth a schválení

MCP dává webovým chatbotům větší schopnost jednání – ale pouze s jasnými hranicemi

MCP pro AI chatboty není žádný kouzelný konektor, který by webovému chatbotu zničehonic svěřil libovolné systémy. Model Context Protocol popisuje spíše společné rozhraní, přes které může model objevovat a volat nástroje: například vyhledávání ve znalostní bázi, dotaz na tiket, logiku rezervace termínů nebo interní kontrolu oproti produktovým datům. Zejména pro webové chatboty je to atraktivní, protože mnoho dialogů nekončí u jediné odpovědi. Návštěvníci se ptají na stav doručení, ceny, kontaktní cesty, formuláře, dostupnost nebo další kroky. Bez nástrojů musí bot vysvětlovat. S nástroji může, kontrolovaně a srozumitelně, získávat relevantní data nebo spouštět připravené akce.

Rozhodující otázka proto nezní: Může chatbot používat nástroje? Otázka zní: Které nástroje smí vidět v jakém kontextu, s jakým tokenem je volat, s jakým lidským schválením je provádět a s jakým protokolováním je později vysvětlit? Finální specifikace MCP ze 28. července 2026 zpřísňuje právě tyto provozní otázky. Dělá jádro bezstavovým, vyžaduje relevantní metadata na požadavek a upřesňuje, jak spolu souvisí vzdálená autorizace HTTP, OAuth, scopes a vazba tokenu na audience.

Co specifikace 2026-07-28 mění pro webové týmy

Nejdůležitější architektonickou změnou je stateless core. Server MCP nesmí předpokládat, že předchozí požadavky na stejném připojení již vytvořily kontext, schopnosti klienta nebo relaci. Vše, co je potřeba ke zpracování, musí být v aktuálním požadavku. Pro distribuované webové infrastruktury je to praktické: požadavky mohou za load balancery, edge gatewayemi nebo platformami workerů spadnout na různé instance. Pro implementaci to však také znamená: žádné skryté předpoklady o přenosových relacích, žádná tichá práva z předchozího připojení a žádná chatovací konverzace jako bezpečnostní hranice.

Každý požadavek potřebuje požadovaná metadata _meta. Mezi ně patří zejména verze protokolu a client-capabilities; informace o klientovi jsou užitečné pro zobrazení, logování a debugování, ale nejsou vhodné jako bezpečnostní důkaz. Pokud web obsluhuje více instancí botů, jazyků nebo zákaznických sekcí, měla by být tato metadatová vrstva vědomě validována a logována. Nenahrazuje věcnou autorizaci, ale zajišťuje, že server dokáže požadavky správně zařadit.

Seznamy nástrojů jsou dynamické, ale ne libovolné

tools/list je v aktuální specifikaci stránkovaný a cachovatelný. Odpovědi mohou obsahovat nápovědy pro cache, jako jsou ttlMs a cacheScope. Zároveň by mělo pořadí zůstat deterministické, dokud se nemění podkladová množina nástrojů. Je to více než jen výkonnostní kosmetika: pokud jsou katalogy nástrojů stabilně seřazeny, mohou je klienti spolehlivěji cachovat a kontexty modelů zůstávají klidnější.

Důležitý je detail u autorizace. Množina nástrojů se může lišit požadavek od požadavku na základě předložené autorizace, například proto, že token povoluje pouze práva ke čtení podpůrných dat, ale ne práva k zápisu do CRM. Nesmí však náhodně kolísat jako vedlejší efekt předchozích požadavků na stejném připojení. Pro webové chatboty z toho vyplývá jasný vzor: viditelný katalog nástrojů vzniká z role, scope, tenanta, jazyka, kontextu a rizika aktuálního požadavku.

Popisy nástrojů nejsou základem důvěry

Nástroje MCP popisují svůj název, své vstupy, volitelně výstupy a anotace. Tato metadata pomáhají modelu a uživatelskému rozhraní pochopit funkci. Nejsou však bezpečnostní kotvou. Specifikace jasně říká, že klienti musí s anotacemi nástrojů zacházet jako s nedůvěryhodnými, pokud nepocházejí z důvěryhodných serverů. Nástroj, který se popisuje jako pouze pro čtení, musí být na straně serveru přesto postaven tak, aby neprováděl žádné zapisující vedlejší účinky.

To platí i pro strukturované výsledky. outputSchema pomáhá validovat odpovědi a nepředávat modelu pouze volný text. Přesto musí servery kontrolovat vstupy, řídit přístup, nastavovat rate limity a čistit výstupy. Webový chatbot by neměl výsledky nástrojů přebírat do viditelných odpovědí nefiltrované, zejména pokud jsou do toho zapojena externí API, zákaznická data nebo obsah blízký HTML.

OAuth: Server MCP je chráněný prostředek

U vzdáleného HTTP MCP je rozhodující rozdělení rolí. Chráněný server MCP funguje jako OAuth Resource Server. Klient MCP jedná jménem Resource Ownera, tedy typicky uživatele nebo organizace. Authorization Server v případě potřeby interaguje s uživatelem a vydává access tokeny. Server MCP musí poskytovat své Protected Resource Metadata, aby klienti mohli objevit odpovídající Authorization Server. Authorization Server poskytuje alespoň jeden z postupů discovery, OAuth Authorization Server Metadata nebo OpenID Connect Discovery; klient MCP musí podporovat oba.

Pro produktové týmy to znamená: chatbot by neměl sám spravovat hesla, API klíče nebo cizí tokeny, pokud je plánován tok OAuth. Měl by uživatele dovést k jasnému schválení, poté použít účelově vázaný access token a viditelně omezit jím povolené nástroje. Pro registraci klientů se preferují Client ID Metadata Documents; Dynamic Client Registration zůstává zachována pouze pro zpětnou kompatibilitu a je zastaralá (deprecated). Zejména u integrací jako kalendář, CRM, helpdesk, úložiště dokumentů nebo e-shopové systémy je toto oddělení důležité, protože stejná konverzace často přechází mezi veřejnými dotazy a akcemi závislými na účtu.

Tokeny musí být vázány na cílový prostředek

Aktuální autorizační specifikace vyžaduje Resource Indicators podle RFC 8707. Klient musí v autorizačních požadavcích a požadavcích na token nastavit parametr resource a tím uvést kanonické URI serveru MCP, pro který je token určen. Server MCP musí zkontrolovat, že access token byl vydán přesně pro jeho prostředek. Tokeny se nesmí přenášet pomocí query stringu, ale patří do hlavičky Authorization Header.

Tato vazba na audience zabraňuje nebezpečné zkratce: token určený pro službu A nesmí být přijat nebo předán u služby B. Webové chatboty proto potřebují čistou hranici tokenů pro každý server MCP a pro každé prostředí. Preview, Staging a Production by neměly používat stejnou audience, pokud představují různé prostředky. Stejně tak by agregátor, který spojuje více serverů MCP před jedním modelem, neměl tokeny směšovat.

Scopes jsou smlouvou o UX a bezpečnosti

Scopes by měly začínat zlehka. Specifikace doporučuje používat nápovědy scope z výzev WWW-Authenticate a při chybějících právech povolit step-up flow. V praxi to znamená: návstěvník může nejprve pracovat s nástroji pro čtení. Teprve když akce vyžaduje více práv, například vytvoření tiketu, zápis do souboru nebo přípravu objednávky, systém se cíleně dotáže na dodatečné schválení.

Dobrý design souhlasu (consent design) uvádí nejen název integrace, ale i její dopad: Která data se čtou? Která akce se připravuje? Ukládá se něco externě, odesílá nebo trvale mění? Pro citlivé operace by měl uživatel vidět skutečné potvrzení a mít možnost je odmítnout. To není individuální právní poradenství, ale technické pravidlo návrhu: schválení musí být pro lidi srozumitelná, pro servery vynutitelná a pro audity dohledatelná.

Odolná architektura pro webové chatboty s MCP

Robustní architektura odděluje model, fasádu nástrojů a cílové systémy. Webový chatbot nekomunikuje přímo s každým poskytovatelem třetí strany, ale s klientem MCP nebo gatewayí, která kontroluje verzi protokolu, client-capabilities, stav autorizace, rate limity a observabilitu. Za nimi leží servery MCP pro jednotlivé integrace nebo věcné oblasti. Každý server deklaruje pouze nástroje, které jsou povoleny pro aktuální požadavek, a každé volání znovu validuje.

Fasáda nástrojů by měla používat stabilní názvy, úzká vstupní schémata a jasná výstupní schémata. Názvy nástrojů musí být dostatečně jednoznačné, zejména pokud více serverů nabízí podobné funkce jako search, create nebo lookup. Při agregaci pomáhá jmenný prostor nebo prefix. Parametry by měly být navrženy tak, aby model nemusel vymýšlet tajná surová data. Pokud proces probíhá přes více požadavků, měl by server vracet explicitní, krátkodobý handle a ten při každém následném volání znovu autorizovat.

Druhým stavebním kamenem je uživatelské rozhraní. Návštěvníci by měli vidět, když je volán nástroj, jaké vstupy se odesílají a kdy je potřeba schválení. Pro přístupy pouze pro čtení často stačí transparentní stav. Pro zapisující, placené, externí nebo osobní akce je potřeba vědomější potvrzení. Specifikace nechává vzory uživatelského rozhraní otevřené, ale jasně požaduje, aby aplikace umožňovaly lidskou kontrolu nad voláním nástrojů.

Checklist pro zavedení MCP pro AI chatboty

1. Vytvoření inventáře nástrojů: Které systémy mají být připojeny, které nástroje jsou pouze pro čtení, které mění data a které vyžadují lidské potvrzení?
2. Definování scopes: Práva rozdělit podle akcí, ne podle interních týmů. Nástroj pro dotazy na stav potřebuje jiné scopes než nástroj pro vytváření, změnu nebo odesílání.
3. Kontrola OAuth discovery: Otestovat Protected Resource Metadata, Authorization Server Metadata, registraci klientů a redirect URI pro každé prostředí.
4. Vynucení vazby na audience: Akceptovat tokeny pouze pro kanonické URI serveru MCP, nikdy je nepřevádět na nesprávné prostředky a nikdy je nedávat do URL.
5. Zajištění determinističnosti tools/list: Společně otestovat stabilní řazení, stránkování, nápovědy pro cache a autorizační filtry.
6. Udržování úzkých schémat: Validovat vstupy, používat strukturované výstupy a automatické načítání externích cílů $ref přes síť výchozím způsobem deaktivovat; volitelně pouze s allowlistem, timeoutem, limitem velikosti a logováním.
7. Vytvoření schvalování v UI: Zviditelnit název nástroje, účel, vstupy, cílový systém, zvýšení scope (step-up) a možnost odmítnutí.
8. Ukotvení observability: Logovat ID požadavku, název nástroje, scope, rozhodnutí, chybu, latenci a typ výsledku bez zbytečného ukládání citlivého obsahu.
9. Procvičení chybových cest: Kód 401, 403, vypršené tokeny, chybějící scopes, neznámé handles, timeouty a odmítnutá schválení řešit jako běžné stavy produktu.
10. Začít v malém: Nejprve spustit jeden až dva nízkorizikové nástroje pro čtení, poté postupně přidávat step-up, zapisující akce a další integrace.

Typické chyby při realizaci

Nejčastější chybou je příliš široký první token. Pokud webový chatbot získá hned po prvním přihlášení rozsáhlá práva k zápisu, každé rozhodnutí modelu se stává rizikovějším. Lepší je minimální počáteční scope s cíleným step-upem. Druhou chybou je katalog nástrojů, který se skládá z názvů interních systémů namísto ze záměrů uživatele. Model pracuje spolehlivěji s jasnými, úzce popsanými akcemi než s generickými univerzálními koncovými body.

Třetí chybou je chybějící oddělení mezi důvěrou v model a důvěrou v server. Model smí navrhnout akci, ale server rozhoduje, zda jsou vstupy platné, zda token odpovídá a zda existuje schválení. Čtvrtou chybou je chybějící dohledatelnost. Pokud je později nejasné, který nástroj s jakým scope četl nebo měnil jaká data, nelze čistě provozovat podporu ani bezpečnost.

Další prohloubení

Tento příspěvek se zabývá integrační vrstvou MCP: stateless core, tools/list a HTTP-OAuth. Následující články prohlubují generickou bezpečnost nástrojů a provoz: Pro autorizační model se hodí KI-Chatbots: Tools sicher mit Rechten und Bestätigungen nutzen. Pro konkrétní volání nástrojů stojí za přečtení KI-Chatbot-Tool-Aufrufe sicher gestalten. Pokud mají výsledky nástrojů zůstat strojově čitelné, hodí se Strukturierte KI-Chatbot-Ausgaben validieren. Pro provoz a řešení problémů je technickým pokračováním KI-Chatbot-Observability für Traces, Retrieval und Tools.

Oficiální zdroje

Odborným základem je finální specifikace MCP 2026-07-28: stránka o MCP Tools, MCP Authorization, oficiální příspěvek The 2026-07-28 Specification a Base Protocol Overview.

Závěr

MCP pro AI chatboty získává na hodnotě tehdy, když jej webové týmy nechápou jako otevřenou krabici s nářadím, ale jako kontrolovanou integrační vrstvu. Specifikace 2026-07-28 se dobře hodí pro moderní webovou infrastrukturu: bezstavové požadavky, cachovatelné seznamy, směrovatelné HTTP hlavičky a explicitní autorizace pro každý prostředek. Zároveň jasněji vymezuje odpovědnost. Nabídky nástrojů musí odpovídat aktuálnímu tokenu, citlivé operace vyžadují lidskou kontrolu a každé volání musí být validováno na straně serveru.

Pragmatický začátek je malý: jeden nástroj pro čtení, úzký scope, jasný text souhlasu, deterministické objevování nástrojů (tool discovery) a dobré logy. Poté lze připojovat další nástroje, aniž by se chatbot stal neprůhlednou černou skříňkou. Z webového chatbota tak nevznikne nekontrolovaný agent, ale srozumitelný asistent, který smí používat přesně ty systémy, jež jsou schváleny pro aktuálního uživatele a aktuální úkol.