MCP pentru chatboturi de website: Conectarea instrumentelor prin OAuth și aprobări

MCP oferă mai multă capacitate de acțiune chatboturilor de website – dar numai cu limite clare

MCP pentru chatboturi AI nu este o mufă magică ce încredințează brusc orice sistem unui chatbot de pe un website. Protocolul Model Context Protocol descrie mai degrabă o interfață comună prin care un model poate descoperi și apela instrumente: de exemplu, o căutare într-o bază de cunoștințe, o interogare de tichete, o logică de programări sau o verificare internă a datelor despre produse. Acest lucru este deosebit de atractiv pentru chatboturile de pe website-uri, deoarece multe dialoguri nu se termină la o simplă răspuns. Vizitatorii întreabă despre statusul livrării, prețuri, modalități de contact, formulare, disponibilitate sau următorii pași. Fără instrumente, botul trebuie doar să explice. Cu instrumente, el poate obține date relevante sau poate iniția acțiuni pregătite, într-un mod controlat și trasabil.

Întrebarea decisivă nu este: Poate un chatbot să folosească instrumente? Întrebarea este: Ce instrumente are voie să vadă în ce context, cu ce token le poate apela, cu ce aprobare umană le poate executa și cu ce jurnalizare le poate explica mai târziu? Specificația finală MCP din 28 iulie 2026 înăsprește tocmai aceste aspecte operaționale. Ea face ca nucleul să fie fără stare (stateless), solicită metadata relevante per cerere și clarifică modul în care se corelează autorizarea HTTP la distanță, OAuth, domeniile de acces (scopes) și legarea de audiență a tokenurilor.

Ce modifică specificația 2026-07-28 pentru echipele de dezvoltare web

Cea mai importantă schimbare de arhitectură este nucleul fără stare (stateless core). Un server MCP nu trebuie să presupună că cererile anterioare de pe aceeași conexiune au stabilit deja un context, capabilități ale clientului sau o sesiune. Tot ce este necesar pentru procesare trebuie să fie inclus în cererea curentă. Pentru infrastructurile web distribuite, acest lucru este foarte practic: cererile pot ajunge pe instanțe diferite în spatele load balancer-elor, ale gateway-urilor de margine (edge) sau ale platformelor de worker. Pentru implementări însă, înseamnă și: fără ipoteze ascunse despre sesiunile de transport, fără permisiuni implicite dintr-o conexiune anterioară și fără utilizarea conversației de chat ca o barieră de securitate.

Fiecare cerere are nevoie de metadatele _meta necesare. Acestea includ, în special, versiunea protocolului și capabilitățile clientului; informațiile despre client sunt utile pentru afișare, jurnalizare și depanare, dar nu constituie o dovadă de securitate. Dacă un website deservesc mai multe instanțe de boți, limbi sau zone de clienți, acest strat de metadate ar trebui validat și jurnalizat în mod deliberat. El nu înlocuiește autorizarea operațională, dar se asigură că serverul poate clasifica corect cererile.

Listele de instrumente sunt dinamice, dar nu arbitrare

tools/list este paginat și poate fi salvat în cache conform specificației curente. Răspunsurile pot conține indicații de cache cum ar fi ttlMs și cacheScope. În același timp, ordinea trebuie să rămână deterministică atâta timp cât setul subiacent de instrumente nu se modifică. Aceasta reprezintă mai mult decât o simplă optimizare de performanță: dacă directoarele de instrumente sunt sortate stabil, clienții le pot salva în cache cu mai multă fiabilitate, iar contextele modelelor rămân mai stabile.

Nuanța privind autorizarea este esențială. Setul de instrumente poate varia per cerere în funcție de autorizarea prezentată, de exemplu pentru că un token oferă doar drepturi de citire pe datele de suport, dar nu și drepturi de scriere într-un CRM. Cu toate acestea, nu trebuie să fluctueze aleatoriu ca un efect secundar al cererilor anterioare de pe aceeași conexiune. Pentru chatboturile de pe website-uri rezultă un tipar clar: catalogul de instrumente vizibil este generat din rolul, domeniul (scope), organizația, limba, contextul și riscul cererii curente.

Descrierile instrumentelor nu constituie o bază de încredere

Instrumentele MCP își descriu numele, intrările, opțional ieșirile și adnotările. Aceste metadate ajută modelul și interfața cu utilizatorul să înțeleagă funcția. Însă ele nu reprezintă o ancoră de securitate. Specificația afirmă clar că clienții trebuie să trateze adnotările instrumentelor ca fiind de neîncredere, cu excepția cazului în care provin de la servere de încredere. Un instrument care se descrie ca fiind de tip „read-only” trebuie totuși construit pe partea de server astfel încât să nu execute efecte secundare de scriere.

Acest lucru este valabil și pentru rezultatele structurate. Un outputSchema ajută la validarea răspunsurilor și nu doar la transmiterea de text liber către model. Cu toate acestea, serverele trebuie să verifice intrările, să controleze accesul, să aplice limite de rată (rate limits) și să igienizeze ieșirile. Un chatbot de website nu ar trebui să preia rezultatele instrumentelor nefiltrate în răspunsurile vizibile, în special atunci când sunt implicate API-uri externe, date ale clienților sau conținut apropiat de HTML.

OAuth: Serverul MCP este o resursă protejată

În cazul Remote-HTTP-MCP, împărțirea rolurilor este crucială. Un server MCP protejat acționează ca un OAuth Resource Server. Clientul MCP acționează în numele unui Resource Owner, adică, de obicei, un utilizator sau o organizație. Serverul de autorizare interacționează cu utilizatorul, dacă este necesar, și emite tokenuri de acces (Access Tokens). Serverul MCP trebuie să își pună la dispoziție metadatele de resursă protejată (Protected Resource Metadata), astfel încât clienții să poată descoperi serverul de autorizare potrivit. Serverul de autorizare furnizează cel puțin una dintre metodele de descoperire, OAuth Authorization Server Metadata sau OpenID Connect Discovery; clientul MCP trebuie să le suporte pe ambele.

Pentru echipele de produs, acest lucru înseamnă: chatbotul nu ar trebui să gestioneze el însuși parole, chei API (API keys) sau tokenuri terțe dacă este prevăzut un flux OAuth. El ar trebui să ghideze utilizatorul către o aprobare clară, să folosească ulterior un token de acces destinat unui scop precis și să limiteze vizibil instrumentele permise prin acesta. Pentru înregistrarea clienților sunt preferate documentele Client ID Metadata; Dynamic Client Registration rămâne menținută doar pentru compatibilitate retroactivă și este depreciată. Această separare este importantă în special pentru integrări precum calendare, CRM, helpdesk, stocare de documente sau sisteme de magazin online, deoarece aceeași conversație trece adesea de la întrebări publice la acțiuni dependente de cont.

Tokenurile trebuie să fie legate de resursa țintă

Specificația curentă de autorizare solicită indicatori de resursă (Resource Indicators) conform RFC 8707. Clientul trebuie să seteze parametrul resource în cererile de autorizare și de token, indicând astfel URI-ul canonical al serverului MCP căruia îi este destinat tokenul. Serverul MCP trebuie să verifice dacă tokenul de acces a fost emis exact pentru resursa sa. Tokenurile nu trebuie transmise prin query string, ci fac parte din Authorization Header.

Această legare de audiență (audience binding) previne o scurtătură periculoasă: un token destinat Serviciului A nu trebuie să fie acceptat sau redirecționat către Serviciul B. De aceea, chatboturile de pe website-uri au nevoie de o delimitare curată a tokenurilor per server MCP și per mediu. Mediile de Preview, Staging și Production nu ar trebui să folosească aceeași audiență dacă reprezintă resurse diferite. De asemenea, un agregator care combină mai multe servere MCP în fața unui model nu ar trebui să amestece tokenurile.

Domeniile de acces (Scopes) reprezintă un contract de UX și securitate

Domeniile de acces (scopes) ar trebui să înceapă de la un nivel minim. Specificația recomandă utilizarea indicațiilor privind domeniile din provocările WWW-Authenticate și permiterea unui flux de ridicare a drepturilor (Step-up Flow) atunci când lipsesc permisiunile. În practică, acest lucru înseamnă: un vizitator poate lucra mai întâi cu instrumente de citire. Abia atunci când o acțiune necesită mai multe drepturi, cum ar fi crearea unui tichet, scrierea unui fișier sau pregătirea unei comenzi, sistemul solicită în mod țintit aprobarea suplimentară.

Un design bun al consimțământului nu doar menționează numele integrării, ci și efectul acesteia: Ce date sunt citite? Ce acțiune este pregătită? Se stochează, se trimite sau se modifică ceva definitiv la nivel extern? Pentru operațiuni sensibile, utilizatorul ar trebui să vadă o confirmare reală și să o poată refuza. Aceasta nu este o consultanță juridică individuală, ci o regulă tehnică de proiectare: aprobările trebuie să fie de înțeles pentru oameni, de aplicat pentru servere și de verificat pentru audituri.

O arhitectură rezilientă pentru chatboturi de website cu MCP

O arhitectură robustă separă modelul, fațada de instrumente și sistemele țintă. Chatbotul de pe website nu comunică direct cu fiecare furnizor terț, ci cu un client sau gateway MCP care controlează versiunea protocolului, capabilitățile clientului, statusul de autentificare, limitele de rată și observabilitatea. În spatele acestuia se află servere MCP pentru integrări individuale sau domenii funcționale. Fiecare server declară doar instrumentele permise pentru cererea curentă și validează din nou fiecare apel.

Fațada de instrumente ar trebui să utilizeze nume stabile, scheme de intrare restrânse și scheme de ieșire clare. Numele instrumentelor trebuie să fie suficient de unice, în special atunci când mai multe servere oferă funcții similare precum search, create sau lookup. În cazul agregării, un spațiu de nume (namespace) sau un prefix este de mare ajutor. Parametrii ar trebui proiectați astfel încât modelul să nu fie nevoit să inventeze date brute secrete. Dacă un proces se desfășoară pe parcursul mai multor cereri, serverul ar trebui să returneze un identificator (handle) explicit, cu durată scurtă de viață, și să îl reautorizeze la fiecare apel ulterior.

O a doua componentă este interfața cu utilizatorul. Vizitatorii ar trebui să vadă când este apelat un instrument, ce date de intrare sunt trimise și când este necesară o aprobare. Pentru accesări de tip simplă citire, un status transparent este adesea suficient. Pentru acțiuni de scriere, contra cost, externe sau cu caracter personal, este necesară o confirmare mai conștientă. Specificația lasă deschise tiparele de interfață, dar cere în mod clar ca aplicațiile să permită controlul uman asupra apelurilor de instrumente.

Listă de verificare pentru lansarea MCP la chatboturile AI

1. Crearea inventarului de instrumente: Ce sisteme urmează să fie conectate, ce instrumente sunt doar de citire, care modifică date și care necesită confirmare umană?
2. Definirea domeniilor (scopes): Împărțiți drepturile în funcție de acțiuni, nu de echipe interne. Un instrument pentru interogarea statusului necesită alte domenii de acces față de un instrument pentru creare, modificare sau trimitere.
3. Verificarea descoperirii OAuth: Testați metadatele de resursă protejată, metadatele serverului de autorizare, înregistrarea clienților și URI-urile de redirecționare per mediu.
4. Impunerea legării de audiență: Acceptați tokenurile numai pentru URI-ul canonical al serverului MCP, nu le redirecționați niciodată către resurse greșite și nu le includeți niciodată în URL-uri.
5. Muncă pe tools/list deterministic: Testați împreună sortarea stabilă, paginarea, indicațiile de cache și filtrele de autorizare.
6. Păstrarea schemelor restrânse: Validați intrările, folosiți ieșiri structurate și dezactivați implicit încărcarea automată din rețea a țintelor externe $ref; opțional, doar cu o listă de permisiuni (allowlist), timeout, limită de dimensiune și jurnalizare.
7. Construirea aprobărilor în UI: Faceți vizibile numele instrumentului, scopul, intrările, sistemul țintă, ridicarea domeniului (scope upgrade) și opțiunea de refuz.
8. Ancorarea observabilității: Jurnalizați ID-ul cererii, numele instrumentului, domeniul de acces, decizia, erorile, latența și tipul de rezultat, fără a stoca inutil conținut sensibil.
9. Exersarea căilor de eroare: Tratați codurile 401, 403, tokenurile expirate, domeniile lipsă, identificatorii (handles) necunoscuți, timeout-urile și aprobările refuzate ca stări normale ale produsului.
10. Începutul la scară mică: Lansați mai întâi unul sau două instrumente de citire cu risc scăzut, apoi adăugați treptat fluxuri de step-up, acțiuni de scriere și alte integrări.

Greșeli frecvente în implementare

Cea mai frecventă greșeală este emiterea unui prim token mult prea larg. Dacă un chatbot de website primește drepturi extinse de scriere imediat după prima autentificare, fiecare decizie a modelului devine mai riscantă. Este de preferat un domeniu de start minim cu un pas de ridicare (step-up) configurat țintit. A doua greșeală este un catalog de instrumente compus din nume de sisteme interne în loc de intenții ale utilizatorilor. Un model lucrează mult mai fiabil cu acțiuni clare și descrise restrâns decât cu endpoint-uri generice multifuncționale.

A treia greșeală este lipsa separării între încrederea în model și încrederea în server. Modelul are voie să propună o acțiune, dar serverul decide dacă intrările sunt valide, dacă tokenul este potrivit și dacă există o aprobare. A patra greșeală este lipsa trasabilității. Dacă mai târziu nu este clar ce instrument a citit sau a modificat ce date cu ce domeniu de acces, nu se va putea asigura corespunzător nici suportul, nici securitatea.

Aprofundări suplimentare

Acest articol tratează stratul de integrare MCP: stateless core, tools/list și HTTP-OAuth. Următoarele articole aprofundează securitatea generică a instrumentelor și exploatarea lor: Pentru modelul de autorizare, este potrivit Chatboturi AI: Utilizarea sigură a instrumentelor cu drepturi și confirmări. Pentru apeluri concrete de instrumente, merită citit Proiectarea sigură a apelurilor de instrumente pentru chatboturi AI. Dacă rezultatele instrumentelor trebuie să rămână lizibile pentru mașini, consultați Validarea ieșirilor structurate la chatboturile AI. Pentru exploatare și depanare, articolul Observabilitatea chatboturilor AI pentru Traces, Retrieval și instrumente reprezintă continuarea tehnică.

Surse oficiale

Baza tehnică o constituie specificația finală MCP 2026-07-28: pagina despre MCP Tools, secțiunea MCP Authorization, articolul oficial The 2026-07-28 Specification și ghidul Base Protocol Overview.

Concluzie

MCP pentru chatboturi AI devine valoros atunci când echipele web nu îl privesc ca pe o trusă deschisă de unelte, ci ca pe un strat de integrare controlat. Specificația din 2026-07-28 se potrivește excelent cu infrastructura web modernă: cereri fără stare, liste ce pot fi salvate în cache, antete HTTP rutabile și autorizare explicită per resursă. În același timp, ea clarifică responsabilitățile. Oferta de instrumente trebuie să corespundă tokenului curent, operațiunile sensibile au nevoie de control uman, iar fiecare apel trebuie validat pe partea de server.

Un început pragmatic se face la scară mică: un instrument de citire, un domeniu (scope) restrâns, un text clar de consimțământ, descoperire deterministică a instrumentelor și jurnale de calitate. Ulterior pot fi conectate și alte instrumente, fără ca chatbotul să devină o cutie neagră. În acest fel, dintr-un chatbot de website nu rezultă un agent necontrolat, ci un asistent transparent, care are voie să utilizeze exact acele sisteme care au fost aprobate pentru utilizatorul curent și sarcina actuală.