Sunt două moduri de a lăsa un agent să acționeze în sistemele tale. Rulezi singur câte un server MCP pentru fiecare integrare, sau îndrepți agentul spre un gateway care a făcut deja asta.
Noi construim unul dintre ele, deci citește în consecință. Ce urmează este totuși varianta pe care i-am da-o unui prieten, inclusiv cazurile în care răspunsul nu suntem noi.
Capcana e că prima e ușoară
Găzduirea unei singure integrări este chiar plăcută. npx un pachet, un token
într-o variabilă de mediu, îndrepți editorul spre el. Douăzeci de minute. Dacă îți
trebuie un server MCP pentru un API, exact asta fă și sari peste restul.
Problema este că nimeni nu se oprește la unul, și nimic din muncă nu se refolosește.
Câte o aplicație OAuth pentru fiecare furnizor. Nu un token — o aplicație. O înregistrezi, configurezi URI-urile de redirecționare, o treci printr-o verificare dacă permisiunile sunt sensibile, și faci asta separat pentru Google, Slack, Notion, HubSpot și tot restul. Asta este munca subestimată constant, pentru că prima durează o oră și pare în regulă.
Reînnoirea token-urilor, la nesfârșit. Token-urile de acces expiră. Cele de reîmprospătare se rotesc, iar unii furnizori îl invalidează pe cel vechi în momentul în care îl folosești pe cel nou, deci o cădere între cele două pierde conexiunea. Este o bucată mică de cod pe care o vei scrie de mai multe ori și o vei greși ușor cel puțin o dată.
Un loc pentru secrete. Nu variabile de mediu pe un laptop, din momentul în care sunt implicați mai mulți oameni. Un depozit de secrete real, cu control de acces real.
Rutare pentru conturi multiple. Două spații Slack înseamnă două credențiale și o schemă de denumire prin care un agent să poată adresa unul, nu celălalt. Asta este enervant de adăugat ulterior și ușor de proiectat prost.
O pistă de audit. Ce agent a apelat ce, cu ce argumente, în numele cui, și ce a primit înapoi. Nimeni nu construiește asta în prima zi și toată lumea o vrea prima dată când se întâmplă ceva surprinzător.
Aplicarea permisiunilor. Un prompt care spune „nu șterge niciodată nimic” nu este aplicare, iar aplicarea reală înseamnă un loc prin care trec toate apelurile — adică un gateway, doar că unul pe care acum îl întreții tu.
Fiecare este o bucată mică de muncă. Problema este că este aceeași bucată mică pentru fiecare integrare, nu se termină niciodată și nu este munca pe care voiai să o faci.
Ce face un gateway în schimb
Tot ce e mai sus, o dată, pentru fiecare aplicație din catalog.
Conectezi o aplicație prin propriul ei ecran de consimțământ și autorizarea încetează să fie problema ta: ajunge într-un seif criptat, este reînnoită înainte să expire și este adresată după nume, nu după token. Conectezi aceeași aplicație de două ori și fiecare conexiune își păstrează credențialul, adresată separat printr-un sufix.
Permisiunile devin trei rânduri per aplicație — citire, scriere, distructiv, fiecare permisă sau blocată — verificate în gateway la fiecare apel, înainte ca ceva să ajungă la furnizor. Instrumentele blocate nici nu îi sunt oferite agentului. Este exact aplicarea pe care altfel ai fi construit-o singur, și este piesa la care majoritatea configurărilor proprii nu ajung niciodată.
Iar fiecare apel aterizează într-un jurnal de activitate cu instrumentul, argumentele, rezultatul, durata, conexiunea folosită și persoana în numele căreia a acționat. Nu pentru că și-a amintit cineva să adauge logare, ci pentru că toate apelurile trec printr-un singur loc.
Concesiile oneste
Patru, și sunt reale.
Un furnizor este pe traseu. Dacă gateway-ul e picat, agenții tăi sunt picați. Procesul tău are o rază de acțiune mai mică — cade o integrare, nu toate.
Nu controlezi procesul. Nu îl poți actualiza, profila sau fixa pe o versiune. Când comportamentul se schimbă, afli observându-l.
Datele trec printr-un terț. Argumentele și rezultatele trec prin serverele altcuiva. Pentru unele organizații asta este o discuție de conformitate înainte să fie una tehnică, și este un motiv legitim să găzduiești singur.
Suprafața de integrare este a noastră, nu a ta. Dacă nu purtăm aplicația de care ai nevoie, aștepți sau construiești în paralel.
Dacă vreuna este eliminatorie, găzduiește singur. Este decizia corectă și niciun tabel comparativ nu o schimbă.
Una lângă alta
| Servere MCP proprii | Gateway administrat | |
|---|---|---|
| Prima integrare | O după-amiază | Câteva minute |
| A zecea integrare | De zece ori întreținerea | La fel ca prima |
| Aplicații OAuth | Câte una per furnizor, de tine | Deja înregistrate, sau a ta |
| Reînnoire token | A ta de scris și operat | Rezolvată |
| Stocarea secretelor | A ta de ales și securizat | Seif criptat |
| Conturi multiple | O proiectezi tu | Adresate prin sufix |
| Pistă de audit | O construiești | Fiecare apel înregistrat |
| Permisiuni | Le construiești, sau te bazezi pe prompt | Aplicate înainte de apel |
| Raza de acțiune a unei căderi | O integrare | Tot, deodată |
| Traseul datelor | Doar infrastructura ta | Printr-un terț |
| Control de versiune | Total | Deloc |
Regula de decizie
Găzduiește singur când integrarea este produsul, când îți trebuie una sau două, sau când regulile de rezidență a datelor exclud alternativa. Sunt cazuri reale și nu sunt rare.
Folosește un gateway pentru tot restul — ceea ce, pentru majoritatea echipelor, înseamnă tot. Integrările nu sunt aproape niciodată produsul. Sunt taxa pe care o plătești ca să ajungi la produs, și este o taxă care se repetă per furnizor, per trimestru, la nesfârșit. Din momentul în care ai mai mult de câteva, sau mai mult de o persoană care are nevoie de ele sub permisiuni diferite, aritmetica încetează să fie strânsă.
Întrebarea care merită pusă nu este „putem construi asta?” — poți, nimic nu e greu. Este „întreținerea a șase aplicații OAuth este lucrul pe care ar trebui să îl facem trimestrul ăsta?” Pentru majoritatea echipelor, răspunsul onest este nu, și rămâne nu.
Calea de mijloc pe care nu o menționează nimeni
Nu se exclud. Un client MCP poate vorbi cu mai multe servere deodată.
Aranjamentul care tinde să funcționeze: un gateway pentru coada lungă — cele douăzeci de aplicații pe care echipa ta le atinge și unde integrarea nu este interesantă, vrei doar să existe — și un server scris de mână pentru sistemul care este cu adevărat al tău, unde vrei control asupra procesului și asupra formei instrumentelor.
Obții pârghie acolo unde integrarea e marfă și control acolo unde nu este. Nu este un compromis; pentru majoritatea echipelor este arhitectura corectă.
Încearcă pe ceva real
Cel mai rapid mod de a rezolva discuția nu este să mai citești o comparație. Conectează o aplicație pentru care altfel ai fi scris un server, stabilește-i regulile și dă-i unui agent o sarcină care chiar te interesează. Durează vreo cinci minute, iar la final vei ști de care parte a discuției ești.