MCP vs API: ce adaugă de fapt un server MCP

Undeva în ultimul an, „ne trebuie un server MCP?” s-a alăturat lui „ne trebuie o aplicație?” pe lista întrebărilor care apar într-un brief înainte ca cineva să fi spus la ce folosește lucrul respectiv. De obicei e pusă ca și cum MCP ar fi un tip de API mai nou și mai bun, spre care trebuie să migrezi. Nu e. Un server MCP e un strat de traducere între o aplicație AI și un sistem care aproape întotdeauna are deja un API, iar în majoritatea proiectelor reale apelează acel API la fiecare cerere. Iată la ce servește fiecare, unde e granița dintre ele, ce presupune cu adevărat construirea unui server și partea pe care demo-urile o lasă deoparte.

MCP vs API, alăturate

Coloana MCP urmează specificația în vigoare în septembrie 2026, revizia 2026-07-28. Resursele și prompturile sunt opționale, iar destule servere expun doar unelte.

Ce este de fapt MCP

Model Context Protocol este un standard deschis, publicat de Anthropic în noiembrie 2024, prin care aplicațiile AI se conectează la sisteme externe. Propria documentație folosește comparația cu „un port USB-C pentru aplicații AI”: o singură formă de conector, astfel încât orice aplicație AI care îl suportă să se poată conecta la orice sistem care îl oferă, fără un cablu separat pentru fiecare pereche.

Există trei roluri. Gazda (host) e aplicația pe care o folosește efectiv un om: Claude, ChatGPT, un editor ca VS Code sau Cursor. În interiorul ei, un client ține o conexiune cu un singur server. Serverul e piesa pe care ai construi-o tu: un program care îi spune clientului ce poate face și apoi face. Cele două vorbesc JSON-RPC 2.0, prin intrarea și ieșirea standard când serverul rulează pe aceeași mașină, sau prin Streamable HTTP când rulează în altă parte.

Un server poate oferi trei feluri de lucruri. Uneltele (tools) sunt acțiuni pe care modelul le poate declanșa: caută comenzi, emite o factură, rezervă un interval. Resursele sunt date pe care aplicația le poate aduce în conversație, cum ar fi un fișier sau o înregistrare. Prompturile sunt șabloane reutilizabile pe care un om le alege dintr-un meniu. În sens invers, un server se poate opri la jumătatea unei sarcini și poate cere informații suplimentare, cel mai util prin elicitation, o întrebare pusă utilizatorului.

Protocolul se schimbă încă repede, iar o bună parte din ce s-a scris despre el în 2025 descrie acum o versiune mai veche. Revizia curentă, din 28 iulie 2026, a eliminat complet handshake-ul de deschidere și sesiunile la nivel de protocol, așa că fiecare cerere își poartă acum singură versiunea și capabilitățile, cam ca un apel API obișnuit. A mutat sarcinile de lungă durată într-o extensie opțională și a declarat depreciate sampling și roots, funcțiile prin care un server putea împrumuta modelul gazdei sau putea întreba în ce foldere are voie să lucreze.

Diferența într-o singură frază

Un API îi spune unui programator ce poate face un sistem; un server MCP îi spune unui model, în timpul rulării, în cuvinte despre care poate raționa. Tot ce e în tabelul de mai sus decurge de aici. Un API presupune că cineva a citit documentația, a ales endpointurile, a tratat erorile și a livrat cod care le apelează la fel de fiecare dată. Un server MCP presupune că nu a făcut nimeni asta: modelul descoperă uneltele când se conectează, le citește descrierile și decide singur care se potrivește cu ce tocmai a cerut utilizatorul.

De aceea descrierile uneltelor contează mult mai mult decât a contat vreodată documentația unui endpoint. Un endpoint cu un nume vag îl costă pe un programator zece minute. O unealtă descrisă vag te costă fiecare conversație în care modelul o alege pe cea greșită, sau pe cea bună cu argumentele greșite, și nimeni nu observă, pentru că răspunsul sună la fel de sigur pe el.

Serverele MCP învelesc API-uri. Nu le înlocuiesc

Uită-te în aproape orice server MCP și găsești la bază un apel API. Serverul oficial GitHub apelează API-ul GitHub. Când îi ceri unui asistent să deschidă un issue, lanțul arată așa: modelul alege unealta, clientul trimite o cerere JSON-RPC, serverul o transformă într-o cerere HTTPS obișnuită către API-ul care există de ani de zile, iar răspunsul se întoarce pe același drum.

Lucrăm și noi așa. Folosim servere MCP zilnic în munca noastră, printre ele Blender și Hugging Face, și fiecare e un strat subțire peste o interfață care exista deja: API-ul Python al Blender, API-ul Hugging Face Hub. Stratul ăsta e cel care îi permite unui model să le folosească fără ca cineva să scrie cod nou de legătură pentru fiecare sarcină.

Așadar, întrebarea reală nu e niciodată „API sau MCP”. Dacă sistemul tău nu are un API, încă nu ai nevoie de un server MCP. Ai nevoie de un API, iar serverul vine după el. Dacă are deja unul bun, serverul e un strat relativ mic deasupra. Alegerea API-ului de dedesubt e o decizie separată, iar REST vs GraphQL o tratează.

De ce un standard, și nu simplu function calling

Modelele puteau apela funcții și înainte de MCP. Fiecare furnizor mare are o funcție de tool calling prin care trimiți, odată cu cererea, o listă de funcții, iar modelul răspunde cu cea pe care vrea să o ruleze. Diferența e cine deține legăturile. Cu function calling simplu, fiecare aplicație își definește uneltele în propriul cod, pentru un singur furnizor de modele. Cu MCP, definițiile uneltelor stau în server, iar orice gazdă compatibilă se poate conecta la ele.

Asta transformă ceea ce era o înmulțire, fiecare aplicație AI construind o integrare separată pentru fiecare sistem, într-o adunare: fiecare aplicație implementează un client o dată, fiecare sistem implementează un server o dată. E motivul pentru care protocolul s-a răspândit atât de repede. OpenAI l-a adoptat în martie 2025, Google a anunțat în aprilie că Gemini îl va suporta, iar Microsoft și GitHub au intrat în comitetul lui de coordonare în mai. În decembrie 2025, protocolul a trecut în Agentic AI Foundation, o structură nouă sub umbrela Linux Foundation, cofondată de Anthropic, OpenAI și Block, cu Google, Microsoft, AWS și Cloudflare printre membri. Pasul ăsta contează mai mult decât pare: e diferența dintre funcția unui singur furnizor și infrastructura unei întregi industrii.

Când merită construit un server MCP

Trei situații, și au un lucru în comun: ce îți apelează sistemul e un model AI ales de altcineva. Prima: vinzi un produs cu API, iar clienții tăi lucrează deja în asistenți AI. Un server îi lasă să-ți folosească produsul de acolo, și tot mai mulți se așteaptă la asta. A doua: echipa ta vrea să pună întrebări sistemelor interne în limbaj natural (comenzi, stocuri, tichete) din asistentul pe care îl folosește deja, fără să construiești tu o interfață de chat proprie. A treia: vrei ca o singură integrare să servească orice aplicație AI, nu câte una pentru fiecare furnizor.

Și trei în care e unealta greșită. Un proces fix, cu pași cunoscuți, de pildă „când vine o comandă, emite factura și trimite-o pe e-mail”, cere automatizare deterministă care apelează direct API-ul; un model care decide fiecare pas adaugă costuri și un nou mod de a greși, fără să câștigi nimic. Am comparat platformele pentru jumătatea asta în Zapier vs. Make vs. n8n. O integrare unică între două sisteme ale tale cere un simplu apel API. Iar orice mută bani sau șterge date cere un om în buclă, lucru pe care MCP îl face posibil, dar nu îl impune.

Ce presupune de fapt construirea unuia

Partea de protocol e cea ușoară. Există SDK-uri oficiale pentru majoritatea limbajelor uzuale, printre ele TypeScript, Python, C#, Go, Java și Kotlin, iar un server care învelește trei endpointuri ale unui API existent are câteva sute de linii. Dacă ai nevoie doar de un demo, e treabă de o zi.

Munca de producție e în altă parte, și tot acolo e și estimarea. Mai întâi, uneltele trebuie gândite pentru un model, nu pentru un programator: mai puține, de nivel mai înalt, cu descrieri scrise pentru cel care chiar le va folosi. Ghidul Anthropic numește o greșeală frecventă uneltele care „doar învelesc funcționalități software sau endpointuri API existente”, iar exemplul lor e o singură unealtă search_contacts în locul unui list_contacts care obligă modelul să treacă prin toată lista. Apoi autorizarea, care pentru un server la distanță înseamnă OAuth 2.1, metadate de resursă protejată, verificarea că fiecare token a fost emis pentru serverul tău și niciodată transmiterea tokenului clientului către API-ul din spate, lucru pe care specificația îl interzice explicit. Jurnalizarea fiecărui apel de unealtă, cu cine a cerut și ce s-a întâmplat. Permisiuni și limite de apeluri, pentru că un model va apela liniștit o unealtă de 400 de ori dacă sarcina pare să o ceară. Asta e partea dintr-un proiect de API & integrări care ia timp.

Mai există un cost, care cade pe partea modelului, nu pe a ta. Fiecare definiție de unealtă se încarcă în contextul modelului. Inginerii Anthropic au lucrat pe un exemplu în care definițiile uneltelor și rezultatele intermediare care treceau prin model ajungeau la 150.000 de tokeni, și l-au redus la circa 2.000 lăsând modelul să scrie cod care apelează serverele. Fiecare unealtă pe care o expui e un cost în fiecare conversație, așa că câteva unelte bune bat o copie fidelă a întregului tău API.

Securitatea: partea pe care demo-urile o sar

Un server MCP îi dă unui model mâini, iar un model primește instrucțiuni de la orice citește. Combinația a produs deja un an întreg de incidente reale. În aprilie 2025, Invariant Labs a arătat tool poisoning: instrucțiuni ascunse în descrierea unei unelte, invizibile pentru utilizator și executate de model. În mai 2025, aceeași echipă a arătat cum un issue construit special într-un depozit public GitHub face un agent care folosea serverul oficial GitHub să scurgă date din depozite private, și a spus clar că problema nu era în codul serverului, ci în arhitectură. În iunie 2025, Asana și-a oprit serverul MCP aproape două săptămâni, după ce o eroare de logică a expus unele date altor organizații; compania a estimat numărul clienților afectați la aproximativ 1.000. În iulie 2025, o vulnerabilitate în mcp-remote, un conector folosit pe scară largă, permitea executarea de cod la distanță pe calculatorul oricui îl conecta la un server nesigur. În septembrie 2025, un pachet npm malițios, deghizat în server de e-mail, trimitea pe ascuns autorului o copie a fiecărui mesaj expediat.

Simon Willison a numit tiparul din spatele majorității acestor cazuri „lethal trifecta”, o combinație letală de trei elemente: un agent cu acces la date private, expus la conținut nesigur și cu o cale de a trimite date în afară. Oricare două se pot gestiona. Toate trei împreună înseamnă că oricine poate pune text în fața modelului, într-un e-mail, un tichet de suport, o recenzie de produs sau o pagină web, poate încerca să-l facă să-ți trimită datele undeva. BSI, autoritatea germană pentru securitate informatică, a folosit cazul GitHub ca exemplu în ghidul din ianuarie 2026 despre atacurile asupra modelelor de limbaj și a concluzionat că un risc rezidual poate rămâne chiar și cu toate contramăsurile relevante aplicate. Dă-i unui server MCP cele mai înguste permisiuni care își fac treaba, pentru că cel mai ostil text pe care îl va citi vreodată primește aceleași permisiuni ca tine.

În practică asta înseamnă unelte doar de citire în mod implicit și unelte de scriere în spatele unei confirmări explicite, câte un server pentru fiecare graniță de încredere în loc de unul care poate face orice, dependențe fixate și verificate în loc de ce servește registrul de pachete azi, și niciodată o unealtă care rulează SQL sau comenzi shell arbitrare pe producție. Cum au schimbat agenții AI hackingul acoperă partea atacatorului, iar securitatea codului generat de AI acoperă codul cu care sunt scrise tot mai des aceste servere.

Cum decizi

Începe cu API-ul. Dacă nu ai unul curat, documentat și autentificat, acela e proiectul, și se plătește indiferent dacă un model AI ajunge vreodată să-l atingă. Dacă ai, întreabă-te cine îți va apela sistemul printr-un model și ce are nevoie să facă cu el: să citească sau să schimbe lucruri. Doar citire înseamnă un prim server mic și sigur. Accesul la scriere e un proiect adevărat, cu o analiză de securitate atașată.

Apoi construiește cel mai mic server care răspunde la cea mai frecventă întrebare, pune-l în fața unor utilizatori reali și citește jurnalele. Apelurile de unelte îți spun ce are de fapt nevoie modelul mai repede decât orice document de design. Jumătatea care ține de model e acoperită de serviciul nostru de AI & automatizare; jumătatea deterministă începe de obicei cu Automatizare flux de lucru.

Surse

Verificate în septembrie 2026. Protocolul se revizuiește des, așa că linkurile către specificație duc la revizia curentă, 2026-07-28; incidentele sunt datate la momentul în care au fost făcute publice. Recomandările despre când merită construit un server ne aparțin.

• Model Context Protocol — What is MCP? ↗

  Definiția MCP ca standard deschis pentru conectarea aplicațiilor AI la sisteme externe și comparația cu „un port USB-C pentru aplicații AI”.

• Model Context Protocol — Specification 2026-07-28, key changes ↗

  Revizia fără stare: eliminarea handshake-ului initialize și a sesiunilor la nivel de protocol, mutarea sarcinilor într-o extensie și deprecierea Roots, Sampling, Logging și Dynamic Client Registration.

• Model Context Protocol — Tools ↗

  Uneltele ca elemente controlate de model, descoperite prin tools/list cu nume, descriere și schemă JSON pentru date de intrare, plus erorile returnate modelului ca să se poată corecta.

• Model Context Protocol — Authorization ↗

  OAuth 2.1 pentru transporturile HTTP, metadate de resursă protejată (RFC 9728), tokeni legați de serverul care îi primește (RFC 8707) și regula că serverele nu acceptă și nu transmit mai departe niciun alt token.

• Model Context Protocol — Security best practices ↗

  Problema „confused deputy” la serverele proxy, token passthrough descris ca anti-tipar și identificatorii de stare care nu trebuie tratați niciodată drept autentificare.

• Anthropic — Introducing the Model Context Protocol ↗

  Anunțul din 25 noiembrie 2024, care descrie MCP ca un nou standard pentru conectarea asistenților AI la sistemele în care stau datele.

• Linux Foundation — Formation of the Agentic AI Foundation ↗

  Decembrie 2025: MCP, goose și AGENTS.md ca proiecte fondatoare, Anthropic, Block și OpenAI ca cofondatori, iar AWS, Bloomberg, Cloudflare, Google și Microsoft printre membri.

• TechCrunch — OpenAI adopts rival Anthropic’s standard for connecting AI models to data ↗

  Martie 2025, începutul suportului din afara Anthropic, pornind cu Agents SDK de la OpenAI.

• Anthropic Engineering — Writing effective tools for agents ↗

  Uneltele care doar învelesc endpointuri API existente, numite o greșeală frecventă, și exemplul search_contacts în locul list_contacts.

• Anthropic Engineering — Code execution with MCP ↗

  Un exemplu lucrat, nu un benchmark: consumul de tokeni redus de la 150.000 la 2.000, o economie de 98,7%, lăsând modelul să apeleze serverele din cod.

• Invariant Labs — Tool poisoning attacks ↗

  Aprilie 2025: instrucțiuni ascunse în descrierile uneltelor, invizibile pentru utilizator și vizibile pentru model.

• Invariant Labs — GitHub MCP exploited ↗

  Mai 2025: un issue public malițios care face un agent să scurgă date din depozite private, descris de cercetători ca problemă de arhitectură, nu ca bug al serverului.

• BleepingComputer — Asana warns MCP AI feature exposed customer data to other orgs ↗

  Iunie 2025: o eroare de logică, nu un atac, cu aproximativ 1.000 de clienți afectați și serverul oprit pe durata remedierii.

• JFrog — Critical RCE vulnerability in mcp-remote (CVE-2025-6514) ↗

  Iulie 2025: CVSS 9,6, executare de cod la distanță pe mașina clientului la conectarea la un server nesigur, remediată în versiunea 0.1.16.

• The Hacker News — First malicious MCP server found ↗

  Septembrie 2025: pachetul npm postmark-mcp, care de la versiunea 1.0.16 trimitea în copie ascunsă fiecare e-mail expediat către o adresă externă.

• Simon Willison — The lethal trifecta for AI agents ↗

  Accesul la date private, expunerea la conținut nesigur și capacitatea de a comunica în exterior, plus motivul pentru care periculoasă e combinația tuturor celor trei.

• BSI — Evasion-Angriffe auf LLMs: Gegenmaßnahmen in der Praxis ↗

  Ianuarie 2026, în germană: oficiul federal german pentru securitate informatică folosește cazul GitHub MCP ca studiu de caz și arată că un risc rezidual poate rămâne chiar cu toate contramăsurile relevante aplicate.