Model Context Protocol este de obicei prezentat ca „USB-C pentru AI”, ceea ce este un slogan bun și o explicație proastă. Iată varianta care te ajută să construiești ceva.
Problema pe care o rezolvă
Un model lingvistic poate acționa asupra lumii doar prin instrumentele pe care i le dai. Înainte de MCP, fiecare combinație de gazdă și instrument era propria integrare: instrumentul tău de GitHub pentru Claude Desktop era alt cod decât instrumentul tău de GitHub pentru Cursor, care era încă altul față de cel pentru un agent scris de tine.
M gazde ori N instrumente înseamnă multe integrări, iar aproape toate sunt aceeași muncă făcută din nou.
MCP transformă asta în M plus N. Un instrument este expus o dată, de un server. Orice client care vorbește protocolul îl poate folosi. Scrii serverul de GitHub o dată, iar fiecare client MCP primește GitHub.
Cele trei substantive
Un server expune capabilități. În practică asta înseamnă aproape întotdeauna instrumente — funcții cu nume, descriere și o schemă JSON pentru argumente. Protocolul definește și resurse, prompturi și alte câteva lucruri, dar poți construi un server util care oferă doar instrumente.
Un client este lucrul care se conectează la servere. Claude, ChatGPT, Cursor, VS Code, Codex și agentul scris de tine sunt toți clienți.
O gazdă este aplicația în care trăiește clientul. Distincția contează ocazional și poate fi ignorată în majoritatea timpului.
Ce trece de fapt prin cablu
JSON-RPC. Ăsta e tot răspunsul, și merită văzut pentru că demistifică restul.
Un client începe cu initialize, anunțând ce versiune de protocol vorbește și ce
suportă. Serverul răspunde cu propriul nume, versiune și capabilități.
Apoi două metode duc practic totul:
tools/list— „ce pot apela?” Serverul returnează nume, descrieri și scheme de argumente.tools/call— „apelează-l pe acesta, cu argumentele astea.” Serverul face treaba și returnează un rezultat.
Asta e tot. Ingineria interesantă este de o parte și de alta a acestor două apeluri, nu în protocolul dintre ele.
Două transporturi
stdio — clientul pornește serverul ca proces copil și vorbește cu el prin
intrarea și ieșirea standard. Simplu, local, fără rețea. Asta produc majoritatea
instrucțiunilor de tipul „rulează comanda npx”.
HTTP în flux — serverul este un endpoint la distanță. Nu se pornește nimic. Asta folosește un server găzduit sau un gateway, și de aceea configurarea unui server MCP la distanță este un URL, nu o comandă.
Ce nu face MCP, în mod deliberat
Partea asta este de obicei sărită și tocmai ea decide cum construiești.
Nu face permisiuni. Protocolul nu are noțiunea de „agentul acesta poate citi,
dar nu poate șterge”. Un server care expune un instrument DELETE îl oferă
oricărui client care se conectează. Dacă vrei reguli, ele trăiesc în server — sau
în ceva prin care trec apelurile.
Nu face identitate prin el însuși. Revizii mai noi specifică OAuth pentru transporturile HTTP, dar ce înseamnă un token este exclusiv treaba serverului.
Nu oprește injecția de prompt. Rezultatul unui instrument este text care intră în contextul unui model. Dacă textul acela conține instrucțiuni și modelul le urmează, MCP nu are nicio părere despre asta. Serverele care returnează conținut din lumea exterioară ar trebui să îl eticheteze ca date neîncrezute, iar clienții ar trebui să îl trateze ca atare.
Nu face instrumentele bune. Un instrument prost denumit, cu o descriere vagă, este exact la fel de derutant peste MCP cum era și înainte. Numele și descrierile sunt interfața, iar modelele le citesc așa cum un dezvoltator citește o semnătură de funcție.
Lucrul de care se lovește toată lumea al doilea
Nu conectarea unui server. Partea aceea merge de obicei.
A doua problemă este că fiecare definiție de instrument costă context la fiecare cerere. Zece aplicații conectate înseamnă câteva sute de instrumente, și acum o parte semnificativă din atenția modelului se duce pe citirea unui catalog înainte ca cineva să fi spus ceva.
Răspunsurile care circulă sunt toate variații pe nu le trimite pe toate: filtrează la ce are nevoie o sarcină, sau trimite un set mic de instrumente de căutare și lasă agentul să caute restul. Amândouă funcționează. Amândouă merită știute înainte să conectezi a zecea aplicație, nu după.
Rezultatele mari sunt aceeași formă de problemă, din cealaltă direcție. Un instrument care returnează un export de 4 MB tocmai ți-a cheltuit fereastra de context pe un CSV. Serverele rezonabile trunchiază, paginează sau returnează un identificator pe care îl poți citi în bucăți.
Cel mai scurt drum spre ceva funcțional
Poți petrece o săptămână construind servere, sau poți împrumuta unul care există deja și afli în zece minute dacă îți folosește ceva din toate astea.
Spinrun este un gateway MCP: un singur endpoint HTTP care poartă deja aplicațiile OAuth, reînnoirea token-urilor, stocarea secretelor și pista de audit pentru un catalog de aplicații. Conectezi o aplicație prin propriul ei ecran de consimțământ, îndrepți un client spre un singur URL și instrumentele sunt acolo. Răspunde și la cele două probleme de mai sus — permisiunile sunt reguli citire/scriere/distructiv aplicate la fiecare apel, nu o propoziție într-un prompt, iar rezultatele mari sunt paginate, nu turnate în fereastra ta de context.
Alege un client, conectează o aplicație și dă-i o sarcină reală, nu un test. Golul dintre „instrumentele apar în listă” și „chiar este util” este locul în care se învață tot, și este mult mai scurt decât dacă începi prin a construi serverul.