Arhitectura MCP: analiză tehnică completă, cu diagrame

Arhitectura MCP este setul fundamental de componente și reguli de comunicare care fac posibil MCP (Model Context Protocol). MCP este un standard open-source, iar arhitectura MCP este infrastructura de bază pe care acesta rulează.

Orice arhitectură MCP conține trei componente de bază, în jurul cărora este construită: o gazdă (host), un client și un server. Cadrul de comunicare al MCP este adesea descris ca fiind alcătuit dintr-un strat de date și un strat de transport. Stratul de date reprezintă setul de reguli privind formatarea mesajelor (cererile MCP sunt trimise în JSON-RPC 2.0). Stratul de transport vehiculează aceste mesaje, folosind Streaming HTTP pentru conexiunile externe.

Arhitectura MCP este un cadru de server care implementează Model Context Protocol, un standard deschis pentru conectarea modelelor AI la instrumente, la resurse precum bazele de date și la prompturi care extind contextul de intrare. Acestea sunt numite în mod colectiv „primitive”. În final, arhitectura MCP le permite LLM-urilor să descopere ce instrumente sunt disponibile și să execute fluxuri de lucru, totul fără a necesita actualizări regulate pe partea clientului.

Diagrama arhitecturii MCP: o aplicație AI face schimb de cereri cu un server MCP, care oferă instrumente, resurse și prompturi.

De când a fost introdusă de Anthropic, arhitectura MCP a ajuns să fie utilizată pe scară largă în fluxurile de lucru AI. Acest lucru se datorează în mare parte faptului că înlocuiește sisteme care necesită mai multă întreținere, cum ar fi cele construite în jurul mai multor conexiuni API, fără a sacrifica performanța. Deoarece toate funcționalitățile disponibile se află în spatele serverului MCP, este necesară o singură conexiune, iar actualizările și adăugirile sunt disponibile imediat pentru aplicația client.

MCP le oferă LLM-urilor un mijloc de a descoperi și de a apela instrumentele, prompturile și resursele disponibile, fie pe sistemul local al aplicației gazdă, fie de la un furnizor extern.

În cazul instrumentelor, care oferă acces la funcționalități externe, descoperirea presupune ca gazda să efectueze un apel tools/list către serverul MCP pentru a afla ce instrumente sunt disponibile. LLM-ul (sau, în unele cazuri, gazda) poate apoi să citească descrierile instrumentelor disponibile și să le solicite după caz. Prompturile și resursele folosesc un proces similar.

Diagrama componentelor arhitecturii MCP: o gazdă care conține un LLM, un orchestrator și un client se conectează la un server MCP în doi pași, mai întâi descoperirea și apoi cererile, iar serverul MCP expune instrumente, resurse și prompturi.

Aceasta contrastează cu arhitectura personalizată bazată pe API-uri, care a fost norma în dezvoltarea software și în care funcționalitățile din afara aplicației trebuiau apelate prin conexiuni dedicate, cu cereri formatate cu precizie.

Aplicația gazdă este platforma centrală de orchestrare și se conectează la un LLM. Instrumente cunoscute precum Perplexity și Claude Desktop pot acționa ca gazde în cadrul unui sistem MCP.

Într-un flux de lucru simplu, utilizatorul pune o întrebare prin interfața de chat. Componenta de orchestrare a gazdei adaugă apoi context la întrebare, indicându-i LLM-ului ce primitive MCP sunt disponibile, împreună cu o descriere a capacităților acestora.

Clientul este o componentă software din aplicația AI. MCP oferă o interfață standard prin care clientul comunică cu servere MCP interne și externe, pe baza instrucțiunilor gazdei sau ale LLM-ului. Rolul său este să stabilească o conexiune, să formateze mesajele JSON-RPC, să trimită cereri și să primească răspunsuri.

Termenii „gazdă MCP” și „client MCP” sunt uneori folosiți interschimbabil. Totuși, distincția este utilă, deoarece o gazdă, cum ar fi Perplexity, poate orchestra mai mulți clienți MCP în același timp. Un flux de lucru AI complex ar putea necesita acces la zeci sau chiar sute de servere MCP separate, iar fiecare dintre acestea va folosi o conexiune separată.

Diagrama unei gazde MCP, cum ar fi Perplexity, care orchestrează trei clienți MCP, fiecare conectat la propriul server MCP, cum ar fi o bază de date, fișiere sau un API extern.

Serverul expune toate instrumentele pe care le poate folosi instrumentul bazat pe AI. Din perspectivă arhitecturală, serverul MCP interpretează cererea primită și, atunci când este necesar, se conectează la primitivele solicitate.

Serverele MCP pot oferi acces la trei categorii de primitive:

Instrumente: Acestea sunt, în esență, funcționalități software externe. Dacă luați în considerare o abordare tradițională bazată pe API-uri, o aplicație de analiză web ar putea prelua date folosind o cerere formatată către un server extern. În arhitectura MCP, toate funcționalitățile terțe ale unui furnizor sunt disponibile printr-o singură conexiune, iar cererile sunt create conform unor reguli de formatare standard.
Resurse: Resursele sunt surse de date care oferă context doar pentru citire. Schemele bazelor de date sunt un bun exemplu. Serverul MCP expune diversele surse de informații disponibile pentru gazdă. Dacă gazda interoghează baza de date, de exemplu printr-o căutare SQL generată de LLM, aceasta este considerată o cerere către un instrument.
Prompturi: Acestea sunt șabloane de prompturi reutilizabile care ajută LLM-urile să efectueze sarcini specifice. Un utilizator sau o gazdă va apela un prompt în locul unui instrument atunci când are nevoie de instrucțiuni gata pregătite pentru a finaliza o sarcină. Adesea, sarcinile predefinite dintr-o aplicație gazdă, cum ar fi opțiunea „examinează codul” sau „analizează datele”, sunt stocate ca prompturi pe care utilizatorul le poate selecta.

De asemenea, merită menționat că MCP și API nu sunt tehnologii care se exclud reciproc. Serverul MCP poate expune apeluri API disponibile ca răspuns la o cerere de descoperire. Esențial este că furnizorul MCP, nu clientul, are responsabilitatea de a le întreține.

Stratul de date din arhitectura MCP este setul de reguli care definesc modul în care sunt formatate cererile, răspunsurile și notificările. Limbajul standard pentru mesaje este JSON-RPC.

Orice arhitectură MCP urmează un proces de bază format din (1) inițializare și descoperire de către gazdă, (2) răspuns din partea serverului MCP și (3) un apel din partea gazdei (uneori decis de LLM), fiecare etapă reprezentând un mesaj JSON separat.

Diagrama stratului de date MCP: un utilizator trimite un prompt către aplicația gazdă, unde LLM-ul lucrează împreună cu clientul MCP; clientul trimite o cerere către serverul MCP (instrumente, resurse, prompturi) și primește un rezultat, iar gazda îi returnează utilizatorului un răspuns.

Să vedem cum funcționează descoperirea instrumentelor prin două exemple (acestea s-ar putea aplica și resurselor sau prompturilor):

Descoperiți instrumentele înainte de generarea de către LLM: Gazda inițiază clientul MCP, care trimite o cerere tools/list (lista de instrumente disponibile a serverului MCP). LLM-ul o analizează în timpul procesului de generare și stabilește dacă este necesar un anumit instrument, o anumită resursă sau un anumit prompt.
Oferiți LLM-ului opțiunea de a efectua o căutare: Într-un sistem agentic, gazda adaugă o opțiune de descoperire, cum ar fi search-tools, în contextul de intrare, iar LLM-ul poate solicita o căutare dacă este necesar.

Instrumentele, care sunt în mare parte funcționalități ale unor aplicații externe, sunt de obicei selectate de LLM sau de gazdă. Resursele și prompturile sunt de regulă solicitate la cererea utilizatorului sau de către gazdă.

Iată cum arată o cerere tools/list către un server MCP, trimisă de o aplicație imaginară de notițe:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

În acest exemplu, “id”:101 identifică cererea printr-un ID, astfel încât clientul să poată asocia răspunsurile, iar câmpul “params” conține informații suplimentare despre client, cum ar fi numele clientului (notes-app-client) și capacitățile acestuia.

Ca răspuns, serverul MCP va returna definițiile instrumentelor, care includ numele instrumentelor disponibile și detaliile asociate acestora. De exemplu, lista ar putea include un instrument add-task, care permite aplicației de notițe să creeze sarcini într-o aplicație conectată de gestionare a sarcinilor sau de calendar, atribuind fiecărei sarcini un titlu și o prioritate.

Iată cum ar putea arăta o cerere:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Câmpul “method” îi indică serverului MCP că este vorba despre un apel de instrument, “name” specifică ce instrument trebuie apelat, iar “arguments” furnizează datele de intrare necesare.

Dacă stratul de date reprezintă ce-ul conexiunii dintre un client și un server MCP, stratul de transport este cum-ul. Acesta definește modul în care circulă mesajele: canalul specific și regulile care guvernează modul în care sunt livrate cererile și răspunsurile.

MCP are două căi de transport:

Intrare/ieșire standard: Aceasta este folosită atunci când serverul MCP rulează în același mediu local ca aplicația gazdă. Clientul scrie cererea JSON în intrarea standard a serverului. Serverul o citește, efectuează operațiunea solicitată și scrie răspunsul în ieșirea standard.
Streamable HTTP: Când serverul MCP rulează extern față de aplicația gazdă, clientul MCP trimite cereri către server folosind HTTP POST. Serverul răspunde fie cu un singur mesaj JSON, fie cu un flux Server-Sent Events (SSE), un canal persistent de „ascultare”, care îi permite să returneze mai multe mesaje în timp.

Arhitectura MCP multi-tenant este un tip de implementare care poate deservi simultan mai mulți utilizatori (tenanți).

În acest context, un tenant poate fi o persoană, un grup de persoane sau o organizație. Implementarea poate presupune rularea unui server MCP separat pentru fiecare tenant, oferirea accesului la un singur server partajat sau plasarea unui set de servere în spatele unui gateway central. Când se folosește un gateway, acesta direcționează cererile către endpoint-urile corecte în funcție de identitatea utilizatorului sau de natura cererii.

Funcționează pe același principiu de bază ca arhitectura MCP standard, dar cererile fiecărui utilizator sunt procesate în propriul spațiu de lucru (chiar dacă acest lucru implică resurse partajate) și sunt autentificate separat. Este o abordare frecventă în mediul enterprise, iar resursele partajate sunt adesea preferate, deoarece rularea mai multor servere MCP ar fi inutil de costisitoare.

Cum arată în practică o cerere MCP completă, de la un capăt la altul? Există opt etape principale, fiecare implicând o componentă distinctă a arhitecturii.

Diagramă de flux a unei cereri MCP complete, în opt pași: descoperirea instrumentelor, solicitarea utilizatorului, procesarea de către model, selectarea instrumentului, cererea, execuția instrumentului, rezultatul și generarea răspunsului.

Iată cum arată în practică un apel de instrument MCP, folosind exemplul anterior al unei aplicații de notițe conectate la un serviciu de gestionare a sarcinilor:

Descoperirea instrumentelor: Aplicația de notițe (gazda) își folosește clientul MCP pentru a solicita instrumentele disponibile ale serverului printr-o cerere tools/list. Serverul returnează numele, descrierile și datele de intrare așteptate ale acestora, inclusiv pe cele pentru instrumentul add-task. Acest lucru se poate întâmpla înainte să trimiteți un prompt.
Solicitarea utilizatorului: Trimiteți o cerere aplicației de notițe bazate pe LLM prin chatbotul din aplicație, de exemplu: „Creează în calendarul meu o sarcină pentru a revizui noua mea ciornă, cu prioritate medie”.
Procesarea de către model: Gazda trimite cererea dumneavoastră și definițiile relevante ale instrumentelor către LLM.
Selectarea instrumentului: LLM-ul generează o cerere structurată de instrument, specificând instrumentul și datele sale de intrare: add-task cu title: Review the draft și priority: Medium. Gazda verifică dacă acțiunea este permisă și transmite cererea clientului MCP, care trimite un mesaj JSON-RPC.
Cererea: Clientul MCP trimite o cerere tools/call către serverul său MCP.
Execuția instrumentului: Serverul MCP apelează API-ul aplicației de gestionare a sarcinilor pentru a crea o nouă sarcină cu titlul și prioritatea specificate.
Returnarea rezultatului: Serverul trimite rezultatul înapoi către clientul MCP, care îl transmite gazdei. Gazda îl adaugă la informațiile furnizate LLM-ului.
Generarea răspunsului: LLM-ul folosește rezultatul pentru a genera un răspuns pentru utilizator, de exemplu: „Am creat o sarcină pentru a revizui ciorna, cu prioritate medie”.

MCP și arhitectura API tradițională sunt adesea confundate, dar sunt tehnologii complementare. MCP a fost conceput special pentru aplicațiile bazate pe AI. Acesta elimină efortul ridicat de întreținere pe care îl presupun implementarea și gestionarea mai multor conexiuni API codificate rigid.

Oferind aplicației gazdă o singură conexiune pentru fiecare furnizor de funcționalități sau resursă internă, MCP ajută la remedierea problemei contextului de intrare supraîncărcat (listarea tuturor API-urilor) sau a scripturilor limitate ale aplicațiilor bazate pe API-uri.

În schimb, serverele MCP pot expune API-uri (sau, mai degrabă, funcționalitatea care apelează API-uri) ca parte a listei lor de instrumente. Ori de câte ori un furnizor își actualizează aplicația și apare un nou API sau dacă documentația se modifică, acesta trebuie doar să actualizeze serverul MCP. Nu sunt necesare modificări de cod în aplicația gazdă.

Securitatea MCP a fost subiectul multor dezbateri încă de la introducerea sa. Deși este considerată în general o tehnologie sigură, există mai multe riscuri de securitate, multe dintre ele mai pronunțate în implementările arhitecturale complexe.

Arhitectura MCP prezintă următoarele puncte slabe potențiale:

Injectarea de prompturi: Un utilizator inserează un prompt rău intenționat în date externe, pe care modelul AI îl interpretează greșit ca pe o instrucțiune.
Acces cu privilegii excesive: Serverele MCP pot expune un număr mare de instrumente unui model AI, ceea ce poate crește potențialul de probleme de securitate (așa-numita „rază de impact”).
Scurgeri accidentale de date: Implementările configurate necorespunzător pot face ca informații sensibile, precum cheile API sau credențialele bazelor de date, să fie transmise unui LLM.
Manipularea sistemului local: Serverele MCP locale sunt la fel de vulnerabile la problemele sistemului local, precum scripturile rău intenționate, ca orice altă aplicație, cu problema suplimentară că pot avea efecte dăunătoare în aval asupra sistemelor de AI agentic.

Niciuna dintre aceste probleme nu este insurmontabilă. Adesea, măsurile consacrate sunt tot ce este necesar pentru a asigura siguranța sistemului. Măsuri precum implicarea unui om în buclă (human in the loop), aplicarea unor controale stricte asupra datelor sensibile și protejarea împotriva atacurilor asupra serverelor sunt practici obișnuite.

MCP s-a dovedit a fi un standard deschis util și popular în rândul dezvoltatorilor. Acesta rezolvă multe dintre problemele API-urilor codificate rigid din aplicațiile bazate pe LLM și reduce substanțial volumul de cod pe care trebuie să-l scrie dezvoltatorii.

Pe viitor, arhitectura de bază a MCP, formată din gazdă și server, va rămâne aproape sigur aceeași. Inovațiile viitoare se vor concentra pe capabilități agentice avansate în fluxurile de lucru cu mai mulți pași.

În plus, vor fi necesare măsuri de securitate mai solide pe măsură ce aceste funcționalități agentice sunt implementate, precum și o arhitectură scalabilă, în special la nivelul stratului de transport, pe măsură ce sistemele AI devin mai extinse și mai complexe.

Ce este arhitectura MCP?

Componentele arhitecturii MCP: gazde, clienți și servere

Gazda

Clientul

Serverul

Ce este stratul de date în arhitectura MCP?

Ce este stratul de transport în arhitectura MCP?

Ce este arhitectura MCP multi-tenant?

Diagrama arhitecturii MCP: prezentare pas cu pas

Prin ce diferă arhitectura MCP de arhitectura API tradițională?

Este sigură arhitectura MCP?

Care este viitorul arhitecturii MCP?