Dacă ai încercat să folosești un model AI pentru întrebări despre afacerea ta, probabil ai ajuns la același blocaj: modelul e bun, dar nu știe nimic despre tine. Poți să-i lipești în conversație un Excel, dar Excelul e de ieri, e trunchiat și are în el nume de clienți pe care nu vrei să le dai nimănui. Un server MCP rezolvă exact acest blocaj: dă modelului o cale controlată de a citi datele tale, în momentul întrebării, fără să le copiezi tu în prompt.
Ce înseamnă MCP
MCP vine de la Model Context Protocol, un standard deschis publicat de Anthropic la sfârșitul lui 2024 și adoptat de atunci de principalii furnizori de modele și de aplicații. Ideea e simplă: în loc ca fiecare aplicație să inventeze propriul mod de a lega un model AI de o sursă de date, există un protocol comun. O sursă de date expune un server MCP; un model (sau aplicația în care rulează, cum e Claude) e un client MCP. Clientul întreabă serverul ce poate face, serverul răspunde cu o listă de „unelte”, iar modelul le folosește când are nevoie.
Analogia cea mai apropiată e un port USB. Înainte de USB, fiecare periferic avea propriul conector și propriul driver. După, orice dispozitiv se conectează la orice calculator. MCP face același lucru pentru date și modele: construiești o dată conectorul pentru ERP-ul tău și îl folosește orice client care vorbește protocolul, de pe web, desktop sau telefon.
Ce face, concret, un server MCP peste datele unei firme
Un server MCP pentru date de business expune de obicei două unelte. Prima descrie datele: ce tabele există, ce coloane au, ce înseamnă fiecare, ce reguli de calcul se aplică. A doua rulează o interogare și întoarce rezultatul. Atât. Modelul face restul: citește descrierea, înțelege întrebarea ta („care produse au avut marjă negativă luna trecută?”), scrie interogarea potrivită, o trimite serverului, primește un tabel și îl explică.
Lucrul care nu se vede, dar face diferența, e descrierea. Un model care primește doar numele coloanelor (ord_st, pr_net, disc_c) va ghici. Un model care primește și explicația („starea comenzii: 3 = finalizată, 5 = anulată după expediere; discountul de coș se atribuie proporțional pe linii; costul pe bucată e cost mediu ponderat la data facturii”) va calcula corect. Această descriere, pe care noi o numim strat semantic, e munca reală dintr-un proiect MCP. Serverul în sine e un program generic.
Cum arată în practică
Echipa adaugă conectorul în Claude din setări, cu adresa serverului. La prima folosire, fiecare om se autentifică (în cazul nostru, prin OAuth, ca la orice aplicație modernă). De atunci, întrebările se pun în română, în conversație: „Cât am vândut pe eMAG în septembrie, pe categorie, și cu ce marjă?” Modelul citește descrierea datelor, scrie și rulează interogarea, întoarce un tabel și, dacă îl rogi, un grafic sau un export. Dacă nu e sigur de o regulă, întreabă. Dacă greșește, îi spui, iar greșeala devine o regulă nouă în descriere, ca să nu se repete pentru nimeni din echipă.
La un client al nostru, un retailer online cu 1,7 milioane de comenzi, descrierea cuprinde 45 de tabele, 34 de reguli de business și 6 funcții de raport. De la primul export de date la primele răspunsuri corecte au trecut trei zile. Detaliile sunt în studiul de caz.
De ce contează pentru un business, nu doar pentru IT
Viteza întrebării. Într-o firmă obișnuită, o întrebare nouă despre date înseamnă un raport nou. Cineva o scrie în Excel sau cere dezvoltatorilor o interogare, iar răspunsul vine peste câteva zile, moment în care întrebarea s-a schimbat. Cu un conector, răspunsul vine în timpul ședinței. Asta schimbă nu doar viteza, ci și ce întrebări îți permiți să pui.
Accesul pentru toată echipa. Rapoartele clasice sunt scrise pentru întrebările de ieri. Un conector e deschis la întrebările de mâine, și e la fel de folositor pentru directorul financiar, pentru omul de la achiziții și pentru cel de la marketing, fără ca vreunul să știe SQL.
Un cost care nu crește cu echipa. Un sistem de BI costă pe utilizator și pe raport. Un conector MCP costă construcția și operarea; fiecare om în plus are nevoie doar de un abonament la Claude.
Independența. Fiind un standard deschis, conectorul nu te leagă de un furnizor. Descrierea datelor tale rămâne în baza ta de date; dacă peste doi ani vrei alt client AI, o refolosești.
Riscurile reale și cum se gestionează
Un model cu acces la datele firmei e o idee care trebuie luată în serios. Trei reguli le rezolvă pe cele mai importante:
- Doar citire. Serverul rulează cu un utilizator de bază de date care nu poate modifica nimic, pe o copie a datelor, nu pe producție. Orice interogare are limită de timp și de rânduri.
- Fără date personale. Numele, adresele, emailurile și telefoanele clienților nu intră în copia pe care o citește modelul. Un client devine un identificator; analizele (câți au recumpărat, ce cumpără) funcționează la fel.
- Autentificare per utilizator. Fiecare om din echipă se conectează cu propriul cont, iar accesul se poate revoca individual.
Mai e un risc, mai puțin discutat: răspunsul plauzibil, dar greșit. Un model care nu are reguli clare va face presupuneri rezonabile și va livra un tabel curat, cu o cifră greșită. Singura apărare e stratul semantic bine scris și o perioadă de calibrare în care răspunsurile sunt comparate cu realitatea. De aceea proiectul nu se termină la lansare, ci două săptămâni mai târziu.
Când are sens și când nu
Are sens dacă ai date structurate (un ERP, un magazin online, un program de contabilitate, conturi de marketing), întrebări care se schimbă des și cel puțin un om care știe cum se calculează lucrurile la tine. Nu are sens dacă datele sunt în zece fișiere Excel întreținute manual, dacă singura ta întrebare e un raport fix pe care îl primești deja, sau dacă nimeni din firmă nu poate spune ce înseamnă o marjă corectă. În ultimul caz, primul pas nu e AI-ul, ci regula.
Dacă vrei să vezi cum ar arăta pentru datele tale, o discuție de 30 de minute e suficientă ca să știm ce export e nevoie și cât ar dura.
Citește și: