MCP 2026 schimbă asistenții AI: protocol stateless și cereri Multi Round-Trip

Un asistent AI primește ordinul să actualizeze un tichet, dar politica firmei cere confirmarea angajatului înainte de schimbarea stării. Serverul trebuie să întrerupă operațiunea, să solicite aprobarea și apoi să continue, chiar dacă următoarea cerere ajunge la altă instanță din infrastructură. Revizia Model Context Protocol din 28 iulie 2026 încearcă să transforme exact acest scenariu într-un flux standard, compatibil cu aplicații distribuite.

Noua specificație MCP introduce un nucleu stateless și mecanismul Multi Round-Trip Requests, abreviat MRTR. Schimbările nu fac automat un asistent mai inteligent și nici nu înlocuiesc memoria conversației. Ele modifică felul în care clienții și serverele MCP comunică atunci când o operațiune are nevoie de informații suplimentare, de aprobarea utilizatorului sau de o acțiune intermediară.

MCP nu mai presupune că serverul își amintește conexiunea anterioară

În arhitectura MCP din 2026, fiecare cerere modernă trebuie să conțină informațiile necesare procesării sale. Specificația precizează că serverul procesează cererile independent și nu trebuie să deducă stare din solicitări anterioare, nici măcar atunci când acestea sosesc pe aceeași conexiune sau pe același flux.

Vechea inițializare bazată pe initialize și notifications/initialized crea un context păstrat între client și server. În varianta stateless, versiunea protocolului și capabilitățile clientului sunt transmise pentru fiecare cerere prin câmpul _meta, folosind cheile definite de specificație.

Această schimbare elimină obligația ca toate solicitările unui client să fie direcționate către același proces. Un load balancer poate trimite două cereri consecutive către instanțe diferite, atât timp cât fiecare instanță poate verifica datele primite și accesa resursele autorizate.

Stateless nu înseamnă însă „fără date persistente”. Istoricul conversației, permisiunile utilizatorului, documentele, rezultatele unor operațiuni și evidențele de audit pot rămâne într-o bază de date sau într-un serviciu dedicat. Diferența este că protocolul nu mai cere unui proces MCP să păstreze în memorie contextul unei sesiuni pentru a înțelege următoarea cerere.

Pentru aplicațiile care au nevoie de memorie pe termen lung, aceasta trebuie proiectată separat și controlat. Un exemplu este arhitectura cu memorie externă și politici diferite pentru fiecare utilizator, unde starea aplicației nu este confundată cu starea conexiunii MCP.

MRTR mută întrebările intermediare într-un schimb controlat

În versiunile anterioare, un server putea iniția cereri către client pe o conexiune bidirecțională. Modelul era dificil de împăcat cu execuția stateless și cu infrastructura în care fiecare solicitare poate ajunge la alt proces.

Multi Round-Trip Requests înlocuiește acest comportament pentru operațiuni precum roots/list, sampling/createMessage sau elicitation/create. Schimbarea este incompatibilă cu vechiul model de cereri inițiate direct de server, motiv pentru care clientul și serverul trebuie să implementeze aceeași generație a protocolului.

Fluxul poate fi urmărit astfel:

Clientul îi cere serverului să execute o unealtă.
Serverul constată că nu poate finaliza operațiunea fără o informație sau o aprobare.
În loc să păstreze deschisă o execuție dependentă de același proces, serverul întoarce un rezultat intermediar cu tipul input_required.
Rezultatul include cererile care trebuie rezolvate și un requestState, adică starea necesară continuării operațiunii.
Clientul obține răspunsurile cerute și retrimite solicitarea împreună cu acestea și cu starea primită.
Serverul continuă operațiunea, poate cere încă o rundă sau poate livra rezultatul final.

MRTR nu reprezintă o conversație liberă între două componente. Este o succesiune explicită de cereri și răspunsuri asociate aceleiași operațiuni logice. Astfel pot fi implementate aprobări umane, completarea unor câmpuri lipsă sau solicitarea controlată a unei acțiuni pe care numai clientul o poate efectua.

O aprobare umană poate supraviețui mutării între servere

Să presupunem că un asistent folosit de o echipă de suport pregătește închiderea unui caz. Serverul verifică regulile companiei și descoperă că tichetul nu poate fi închis fără confirmarea responsabilului.

Cu MRTR, serverul returnează cererea de confirmare și starea necesară reluării. Clientul afișează utilizatorului acțiunea propusă, iar răspunsul este trimis într-o rundă nouă. Cererea poate ajunge la altă instanță MCP, care reconstruiește continuarea din datele validate, fără să depindă de memoria procesului inițial.

Acest model este potrivit pentru infrastructuri cu mai multe instanțe, actualizări progresive și redistribuirea încărcării. El permite și tratarea mai clară a întreruperilor: aplicația știe dacă are un rezultat final sau dacă așteaptă o informație intermediară.

Totuși, MRTR nu garantează că operațiunile de business sunt sigure la repetare. Echipa care construiește aplicația trebuie să decidă cum împiedică o reîncercare să producă de două ori aceeași plată, actualizare sau trimitere. Identificatorii operațiunilor, verificarea stării resursei și regulile de idempotency rămân responsabilitatea aplicației.

Același principiu este relevant și când răspunsurile modelului sunt validate înainte de a ajunge la un sistem extern. Structured Outputs cu JSON Schema și retry controlat rezolvă forma datelor generate; MRTR rezolvă continuarea unei operațiuni care necesită mai multe schimburi. Cele două mecanisme se completează, dar nu se înlocuiesc.

`requestState` trebuie tratat ca date furnizate de un atacator

Specificarea MRTR avertizează explicit că un requestState primit de server trebuie considerat input controlat de un potențial atacator. Clientul poate returna valoarea modificată, iar simplul fapt că aceasta provine aparent dintr-o rundă anterioară nu îi dovedește integritatea.

Dacă requestState influențează autorizarea, accesul la resurse sau logica aplicației, serverul trebuie să îi protejeze integritatea, de exemplu prin HMAC sau criptare autentificată, și să respingă valorile care nu trec verificarea.

Pentru o implementare serioasă, controlul nu ar trebui să se oprească aici. Starea poate fi legată de utilizatorul și operațiunea pentru care a fost emisă, poate avea o perioadă limitată de utilizare și nu ar trebui să includă secrete în clar. Serverul trebuie să verifice din nou autorizarea înaintea efectului final, nu să presupună că aprobarea unei etape intermediare acordă acces nelimitat.

Jurnalele trebuie să distingă cererea inițială, rundele intermediare și rezultatul final, fără să copieze inutil date sensibile. În plus, aplicația trebuie să păstreze separarea dintre identitatea utilizatorului, identitatea clientului MCP și drepturile serviciului care execută acțiunea.

Revizia din 2026 include și clarificări privind autorizarea, iar documentația MCP cere implementatorilor să urmeze practicile de securitate OAuth 2.1. Stateless nu elimină autentificarea și nu transformă tokenul într-o autorizație universală pentru toate uneltele.

Scalarea devine mai simplă, dar observabilitatea devine obligatorie

Avantajul operațional al nucleului stateless este eliminarea dependenței de session affinity pentru cererile moderne. Instanțele pot fi adăugate sau înlocuite mai ușor, iar un proces care dispare nu trebuie să ia cu el contextul protocolului.

În schimb, traseul unei operațiuni nu mai poate fi reconstruit doar din memoria sau logurile unei singure instanțe. Aplicațiile au nevoie de identificatori de corelare, evenimente de audit și metrici care urmăresc câte operațiuni s-au încheiat, câte așteaptă input și câte au fost respinse deoarece starea nu a putut fi verificată.

Echipa trebuie să testeze separat cel puțin patru situații:

următoarea rundă ajunge la altă instanță;
utilizatorul abandonează cererea intermediară;
clientul retrimite aceeași rundă după un timeout;
requestState este modificat, expirat sau asociat altui utilizator.

Testarea conversațiilor rămâne necesară, dar nu este suficientă. Metoda pentru verificarea unui asistent în conversații lungi și cu instrucțiuni conflictuale evaluează comportamentul modelului; testele MRTR verifică protocolul, autorizarea și efectele operațiunilor distribuite.

Migrarea trebuie făcută ca schimbare de protocol, nu ca simplu update

Specificarea 2026-07-28 păstrează reguli de compatibilitate: o cerere modernă cu metadatele per request este servită stateless, în timp ce o cerere initialize selectează semantica legacy corespunzătoare versiunii negociate. Această tranziție nu înseamnă că orice combinație de client, SDK și server va funcționa automat.

Înainte de migrare, o echipă ar trebui să inventarieze versiunile acceptate de fiecare componentă, capabilitățile transmise și funcțiile care depind de cereri inițiate de server. Apoi poate muta câte un flux către MRTR și îl poate testa prin mai multe instanțe, cu timeout-uri și reîncercări reale.

Trebuie verificat și SDK-ul concret folosit. Publicarea specificației și actualizarea SDK-urilor principale nu garantează că toate bibliotecile, integrările sau produsele comerciale au implementat simultan fiecare funcție.

Pentru asistenții construiți cu ChatGPT sau cu alte modele, suportul MCP depinde de host, client și infrastructura aplicației, nu doar de model. MCP definește comunicarea dintre componente; nu decide singur ce unealtă este permisă, ce model trebuie ales sau cine aprobă acțiunea. Selecția modelului rămâne o problemă separată, tratată prin model routing după cost, risc și complexitate.

Decizia practică pentru 2026 este clară: aplicațiile noi pot proiecta direct cereri autonome și continuări MRTR, iar sistemele existente trebuie să păstreze compatibilitatea legacy numai cât timp clienții lor o cer. Momentul de trecere nu se stabilește după data specificației, ci după testarea comună a clientului, serverului, SDK-ului și controalelor de autorizare.

Întrebări frecvente

Stateless înseamnă că asistentul AI nu mai poate avea memorie?

Nu. Stateless descrie procesarea cererilor MCP, nu memoria conversației sau datele aplicației. Acestea pot fi păstrate într-un serviciu extern și transmise controlat când sunt necesare.

Ce problemă rezolvă Multi Round-Trip Requests?

MRTR permite ca o operațiune să solicite informații, aprobări sau acțiuni intermediare și apoi să continue prin cereri succesive, fără să depindă de același proces de server.

Poate serverul avea încredere în `requestState`?

Nu în mod implicit. Specificația cere ca valoarea să fie tratată ca input controlat de atacator, iar integritatea ei trebuie protejată dacă influențează autorizarea, resursele sau logica aplicației.

Este suficientă actualizarea SDK-ului pentru migrare?

Nu. Trebuie verificate versiunile negociate, capabilitățile, fluxurile MRTR, autorizarea, reîncercările și comportamentul aplicației atunci când rundele ajung la instanțe diferite.