Ce este un server MCP? Cum funcționează MCP și MCP UI în 2026

Pe 1 aprilie 2025, Invariant Labs a publicat un instrument numit add. Primea două numere și returna suma lor. Descrierea lui conținea însă și un bloc marcat IMPORTANT, invizibil în interfața clientului, care îi cerea modelului să citească ~/.cursor/mcp.json și ~/.ssh/id_rsa și să trimită ambele fișiere în afară printr-un parametru de rezervă. Modelul s-a conformat. Utilizatorul a văzut o adunare.

Demonstrația aceasta este cea mai utilă introducere în serverele MCP pe care o cunosc, pentru că arată ambele jumătăți deodată. Protocolul a funcționat exact cum a fost proiectat: un client AI a descoperit un instrument, i-a citit descrierea și l-a apelat. Modelul de încredere era partea pe care nimeni nu o construise încă.

Ce este un server MCP

Un server MCP este un program care expune instrumente, date și prompturi către aplicații AI prin Model Context Protocol (MCP). Documentația oficială definește MCP drept „un standard open-source pentru conectarea aplicațiilor AI la sisteme externe”. Un client AI precum Claude, ChatGPT, Visual Studio Code sau Cursor se conectează la server, întreabă ce oferă și apelează acele capabilități în numele utilizatorului.

Anthropic a anunțat MCP pe 25 noiembrie 2024 împreună cu șase servere gata făcute: Google Drive, Slack, GitHub, Git, Postgres și Puppeteer. OpenAI l-a adoptat în martie 2025. Google DeepMind a urmat în aprilie. În decembrie 2025, Anthropic a donat protocolul către Agentic AI Foundation, un fond dedicat din cadrul Linux Foundation, cofondat de Anthropic, Block și OpenAI.

Problema este multiplicarea conexiunilor. Înainte de MCP, fiecare aplicație AI care dorea GitHub își scria propriul conector, iar fiecare furnizor construia câte o legătură pentru fiecare aplicație AI. Zece modele și zece instrumente puteau însemna o sută de integrări. MCP reduce numărul la douăzeci: clientul implementează protocolul o dată, iar sistemul expune un server.

Gândește-te la el ca la containerul de transport al integrărilor AI. Înainte de containere, fiecare port încărca fiecare marfă de mână, cu macaralele și echipa lui. Containerul a standardizat cutia, așa că orice navă, macara și camion putea muta orice marfă. Nu a standardizat ce intra în cutie și nu a inspectat niciodată conținutul. MCP face același târg. Ține minte a doua jumătate, revine în secțiunea despre securitate.

Cum funcționează un server MCP

Specificația actuală, versiunea 2026-07-28, folosește mesaje JSON-RPC 2.0 între trei roluri. Propria ei descriere are trei rânduri: gazdele sunt „aplicații LLM care inițiază conexiuni”, clienții sunt „conectori din interiorul aplicației gazdă”, iar serverele sunt „servicii care oferă context și capabilități”.

Gazdă, client, server

Gazda este aplicația în care scrii: Claude Desktop, un IDE, propriul tău agent. În interiorul ei rulează câte un client pentru fiecare conexiune la un server. Serverul stă la capătul celălalt și vorbește cu sistemul real, fie că e o bază de date Postgres, API-ul GitHub sau un folder de pe discul tău. Gazda decide ce vede modelul și ce trebuie să aprobe utilizatorul. Serverul decide ce va face sistemul din spatele lui.

1. Gazdă Claude Desktop · un IDE · propriul tău agent

   arată modelului instrumentele, cere consimțământul utilizatorului

2. Client câte unul pentru fiecare conexiune la server

   vorbește JSON-RPC prin stdio sau Streamable HTTP

3. Server MCP instrumente · resurse · prompturi

   descrie ce oferă și execută apelurile

4. Sistemul din spate bază de date · API SaaS · fișiere locale

   face munca

Instrumente, resurse și prompturi

Un server poate oferi trei tipuri de lucruri:

• Instrumentele (tools) sunt funcții pe care modelul le poate executa: create_issue, query_orders, send_email. Fiecare are un nume, o descriere și un JSON Schema pentru intrări.
• Resursele (resources) sunt context și date pe care le citește utilizatorul sau modelul: un fișier, schema unei baze de date, o înregistrare.
• Prompturile (prompts) sunt mesaje și fluxuri de lucru șablon pe care utilizatorul le poate alege, de exemplu „rezumă acest pull request”.

Instrumentele primesc cea mai mare atenție pentru că acționează. Din același motiv poartă și cea mai mare parte a riscului.

Un apel de instrument, pas cu pas

Revizia 2026-07-28 a făcut MCP fără stare. Nu mai există handshake-ul initialize; fiecare cerere poartă versiunea protocolului și capabilitățile clientului într-un câmp _meta, iar serverele trebuie să implementeze o metodă server/discover, ca un client să poată întreba din start ce suportă. Un singur apel de instrument arată acum așa:

1. Utilizatorul cere: creează un tichet pentru acest bug

2. Pasul 1

   Descoperire

   • Clientul poate apela server/discover pentru versiuni și capabilități
3. Pasul 2

   Lista de instrumente

   • tools/list returnează nume, descrieri și scheme de intrare
4. Pasul 3

   Modelul alege un instrument

   • Gazda îi transmite modelului definițiile instrumentelor
5. Pasul 4

   Consimțământul utilizatorului

   • Specificația spune că gazdele trebuie să obțină consimțământ explicit înainte de a apela orice instrument
6. Pasul 5

   Apel

   • tools/call cu argumente, versiunea protocolului în _meta

7. Lipsește o intrare? Serverul returnează input_required, clientul reîncearcă cu răspunsurile

   Pasul 6

   Rezultat

8. Rezultatul ajunge înapoi la model drept context

Pasul 6 este nou în această revizie. Un server care are nevoie de mai multe informații nu mai trimite o cerere proprie înapoi către client. Returnează un rezultat marcat input_required, clientul adună răspunsul și reîncearcă apelul inițial. Specificația numește asta modelul Multi Round-Trip Request.

Transporturi: stdio și Streamable HTTP

Specificația definește două transporturi standard:

• stdio: clientul pornește serverul ca subproces și schimbă cu el mesaje JSON-RPC delimitate de linie nouă prin intrarea și ieșirea standard. Așa rulează majoritatea serverelor locale, și asta înseamnă că serverul rulează pe mașina ta, cu privilegiile tale.
• Streamable HTTP: fiecare mesaj este un HTTP POST către un singur endpoint, iar răspunsurile vin înapoi ca obiect JSON sau ca flux de evenimente legat de cerere. Așa rulează serverele la distanță, găzduite.

Transportul mai vechi HTTP+SSE este oficial depreciat. Revizia 2026-07-28 a eliminat și sesiunile la nivel de protocol și headerul Mcp-Session-Id; un server care are nevoie de stare între apeluri își generează acum propriul identificator și îl primește înapoi ca argument obișnuit al instrumentului.

Autorizare

Autorizarea în MCP este opțională și se aplică doar pentru HTTP. Pentru stdio, specificația spune că serverele ar trebui să ia credențialele din mediu. Pentru HTTP, un server MCP protejat acționează ca server de resurse OAuth 2.1. Trebuie să publice OAuth Protected Resource Metadata (RFC 9728), ca să-i poată găsi clienții serverul de autorizare. Clienții trebuie să numească exact serverul pentru care este tokenul (indicatori de resursă RFC 8707). Serverele trebuie să respingă orice token care nu a fost emis pentru ele, iar ghidul de securitate numește „token passthrough”, adică trimiterea nemodificată a tokenului unui client către un API din aval, drept interzis explicit.

Ultima regulă contează mai mult decât pare. Un server care retransmite orice token primește devine un proxy pentru oricine deține unul.

Ce adaugă MCP UI: servere care returnează o interfață

Răspunsurile text încetează să funcționeze în clipa în care un utilizator trebuie să compare patruzeci de rânduri, să ajusteze un formular cu douăsprezece câmpuri sau să aprobe un lot de modificări una câte una. „MCP UI” este numele sub care oamenii caută soluția: un server returnează o interfață interactivă care se afișează în clientul AI, lângă conversație.

Statutul merită precizie. Ideea a pornit de la MCP-UI, un proiect comunitar. OpenAI a construit un mecanism asemănător în Apps SDK. Proiectul MCP a propus un standard comun cu ambele la 21 noiembrie 2025, apoi a publicat MCP Apps la 26 ianuarie 2026 drept prima extensie oficială MCP. Pachetele MCP-UI respectă acum standardul și rămân un loc pentru încercarea îmbunătățirilor.

Așadar MCP UI înseamnă azi MCP Apps. Este oficial și este o extensie, nu parte din nucleul protocolului. Extensiile sunt opționale: trebuie să le suporte și clientul, și serverul, iar documentația spune deschis că „suportul gazdelor diferă de la un client la altul”. Documentația MCP Apps listează drept gazde compatibile Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam și Archestra.AI. Un server ale cărui instrumente returnează UI trebuie să funcționeze în continuare și pentru un client care afișează doar text.

Mecanic, refolosește piesele proprii ale MCP:

1. Descrierea unui instrument include un _meta.ui.resourceUri care indică o resursă ui://.
2. Gazda preia acea resursă, o pagină HTML cu scripturile ei, și o poate preîncărca înainte ca instrumentul să fie apelat.
3. Gazda o afișează într-un iframe izolat (sandbox), care nu poate citi pagina părinte, cookie-urile sau spațiul ei de stocare.
4. Aplicația și gazda comunică prin postMessage într-un dialect JSON-RPC al MCP. Aplicația poate cere apeluri de instrumente, iar gazda decide pe care le permite.

Costul este real. Acum livrezi un front-end web în aplicația altcuiva, cu o politică de securitate a conținutului pe care trebuie s-o declari, cu reguli de afișare pe care nu le controlezi și cu o variantă text de rezervă pentru fiecare gazdă care o ignoră. Câștigul este că aprobarea nu mai e o transcriere de chat. Lista de cazuri potrivite din documentație se încheie cu „aprobarea rapoartelor de cheltuieli, revizuirea modificărilor de cod sau trierea problemelor”, iar acesta este miezul onest: MCP UI e cel mai bun la decizii, nu la decor.

Un exemplu Tajo doar în citire

Suprafața Alto MCP a Tajo include query_contacts, care caută contacte stocate în spațiul conectat. Caută un contact existent după email și examinează ID-ul, starea consimțământului pentru email și momentul ultimei observări. Instrumentul separat get_contact_topic_status citește abonările sale pe teme.

Acestea sunt citiri din spațiul de lucru. Nu aduc o imagine actualizată de la furnizor, nu pornesc sincronizarea și nu trimit mesaje. Nici nu dovedesc că toți conectorii sunt activi. Investighează la sursă datele lipsă sau vechi. Un rezultat gol nu dovedește că persoana lipsește din Brevo.

Folosește documentația MCP Tajo pentru a conecta un client acceptat și a vedea instrumentele expuse efectiv spațiului tău autorizat. Un panou interactiv poate ajuta când gazda acceptă MCP Apps; rezultatul text trebuie totuși să explice ce s-a întâmplat.

Un apel de instrument nu este o sincronizare durabilă

Sincronizarea recurentă cere și programare, identități stabile, progres salvat, decizii de reîncercare și evidența scrierilor încheiate. Aplicația care execută munca răspunde de ele. MCP standardizează accesul la instrumente; simpla afișare nu oferă aceste reguli.

După expirarea timpului, o citire poate fi repetată de obicei. O trimitere sau plată ar putea fi deja făcută. Păstrează înregistrarea execuției și verifică rezultatul înainte de altă încercare. Încrederea modelului nu dă permisiune și nu face repetarea sigură.

Ghidul API Brevo arată scrierea în destinație pe o cale concretă de contact. Ghidul reverse ETL arată când câmpurile calculate merită sincronizare proprie întreținută.

Nota de plată pentru securitate vine odată cu protocolul

Obiecția merită formulată complet: „MCP îi dă unui model probabilistic o listă de funcții care pot șterge date și trimite e-mailuri, apoi se bazează pe text scris de străini ca să le descrie. Asta nu e un standard de integrare. E un atac asupra lanțului de aprovizionare, cu specificație.” Cea mai mare parte e corectă. Specificația este de acord cu premisa. Secțiunea ei de securitate spune că instrumentele „reprezintă execuție de cod arbitrar și trebuie tratate cu prudența cuvenită”, că descrierile instrumentelor „ar trebui considerate nesigure, cu excepția cazului în care provin de la un server de încredere”, și că MCP „nu poate impune aceste principii de securitate la nivel de protocol”.

Iată istoricul de până acum:

• Otrăvirea instrumentelor (tool poisoning). Dezvăluirea Invariant Labs din aprilie 2025, instrumentul add de mai sus. Aceeași postare a descris rug pull, când un server schimbă descrierea unui instrument după ce l-ai aprobat, și shadowing, când un server rău intenționat rescrie comportamentul modelului față de un alt server, de încredere.
• Compromiterea serverelor locale. În iulie 2025, JFrog a dezvăluit CVE-2025-6514 în mcp-remote, versiunile 0.0.5 până la 0.1.15, care permitea unui server rău intenționat să ruleze comenzi pe mașina utilizatorului. În aceeași vară, CVE-2025-49596 a lovit chiar MCP Inspector de la Anthropic, livrat implicit fără autentificare.
• Umflarea scope-urilor. Bunele practici de securitate oficiale numesc tiparul: tokenuri cu files:* sau admin:* acordate din start, pentru că un server a listat toate scope-urile și clientul le-a cerut pe toate.
• Îngrijorare oficială. În mai 2026, Agenția Națională de Securitate a SUA (NSA) a declarat că „proliferarea rapidă a MCP a depășit dezvoltarea modelului său de securitate”.

Unde greșește obiecția este concluzia. Soluția nu a fost niciodată să nu mai conectăm modele la sisteme; echipele făceau deja asta cu chei API brute lipite în prompturi și scripturi, fără niciun jurnal de audit. Soluția este să tratezi un server MCP ca pe orice altă dependență privilegiată:

• Instalează servere doar din surse cărora le-ai încredința aceleași credențiale și în afara MCP.
• Preferă serverele la distanță cu OAuth și scope-uri înguste în locul binarelor locale care țin chei cu viață lungă.
• Cere aprobare umană pentru fiecare scriere și păstrează evidența cine ce a aprobat.
• Fixează versiunile serverelor și revizuiește-le din nou când se schimbă descrierea unui instrument.
• Expune instrumente croite pe sarcini, nu un API întreg; un model nu poate abuza de un endpoint de ștergere care n-a fost niciodată expus.

Protocolul a standardizat cutia. Inspectarea mărfii rămâne treaba ta.

Construiești un server MCP sau folosești unul existent

Cataloagele publice precum mcp.so adună servere construite de comunitate, iar mulți furnizori SaaS își publică propriile servere. Brevo, de exemplu, oferă un server MCP împărțit și în servere individuale, așa că unui agent i se pot da contactele fără campanii. Decizia ține mai puțin de efort și mai mult de cine ar trebui să dețină forma instrumentelor.

Ce server MCP ar trebui să folosească agentul tău?

1. Furnizorul publică un server care acoperă sarcina

   Folosește serverul furnizorului

   Ține pasul cu API-ul și îl întreține furnizorul.

2. Un singur sistem, dar ai nevoie de mai puține acțiuni sau de acțiuni mai sigure

   Folosește-l cu acces restrâns

   Acordă scope-uri minime și expune doar grupurile de instrumente de care are nevoie agentul.

3. Date interne sau un sistem fără server

   Construiește un server mic

   Câteva instrumente croite pe sarcini peste propriul tău API, cu propria ta autentificare.

4. Sarcina se întinde pe două sau mai multe sisteme

   Construiește sau adoptă un strat guvernat

   Un singur set de instrumente, reguli de consimțământ și istoric de audit pentru toate.

Construirea unui server de bază e partea ușoară. Cu un SDK oficial, un server stdio funcțional cu un singur instrument e treabă de o după-amiază. Costul vine mai târziu: OAuth pentru versiunea HTTP, deprecierile (revizia 2026-07-28 a depreciat Roots, Sampling și Logging, precum și Dynamic Client Registration) și munca permanentă de a scrie descrieri de instrumente pe care modelul le citește corect. Să învelești un API câte un endpoint pe instrument este cea mai frecventă greșeală. Fiecare descriere de instrument este text pe care modelul trebuie să-l citească și să-l cântărească, așa că o listă scurtă de instrumente croite pe sarcini bate întreaga suprafață a API-ului.

MCP, API-uri, integrări și iPaaS

MCP nu înlocuiește API-urile. Aproape orice server MCP este un înveliș peste un API. API-ul rămâne locul unde se face munca, cu propriile limite de rată, model de date și ciudățenii. MCP schimbă cine îl poate apela: un model, la rulare, care alege apelul pe baza unei descrieri, în locul unui dezvoltator care îl scrie fix în cod dinainte.

Distincția trasează o linie clară față de celelalte două lucruri cu care MCP e confundat:

• Integrările și iPaaS (principalele platforme sunt comparate aici) mută date după un program sau la un declanșator, determinist, indiferent dacă e cineva în chat sau nu. O sincronizare nocturnă a 40 000 de comenzi într-un CRM nu ar trebui să depindă de decizia unui model de a face 40 000 de apeluri de instrumente.
• Reverse ETL împinge date modelate dintr-un depozit de date înapoi în instrumentele operaționale. Ce este reverse ETL și când se potrivește este un subiect separat, iar el este un pipeline, nu o conversație.
• MCP este pentru momentele în care o persoană sau un agent trebuie să întrebe, să inspecteze sau să acționeze în aceste sisteme, la cerere.

Greșeala merge în ambele direcții. Unele echipe construiesc servere MCP pentru sincronizare în masă și obțin pipeline-uri lente, scumpe și nerepetabile. Alte echipe construiesc integrări atente și apoi îi dau asistentului AI o cheie API brută ca să le interogheze, și obțin o ușă din spate neguvernată.

Pentru o integrare acceptată, sarcina durabilă și instrumentele de inspectare ar trebui să împartă o limită explicită de permisiuni. Verifică conectorul, acțiunile permise și rezultatele înregistrate pentru fluxul exact. Documentația integrărilor separă îndrumarea de configurare de căile ce încă au nevoie de dovezi din producție. MCP poate expune instrumente aprobate separat; afișarea lor nu dovedește o sincronizare recurentă ori toate controalele active.

În 22 de luni, MCP a ajuns de la șase servere de referință la un proiect Linux Foundation pe care îl vorbesc Claude, ChatGPT, VS Code și Cursor. Conectarea unui model la un sistem e acum partea ieftină. Să decizi ce are voie să facă acolo, asta e munca.