MCP și API în munca agentului și a aplicației

Agentul a accesat o sursă externă, a înțeles formatul răspunsului și a construit o pagină cu hartă. Funcționează. Acum această pagină o deschide un alt om, care nu are nici urmă de Claude Code.

Înainte de publicare, merită să răspundeți la o singură întrebare. Cine va aduce datele pentru vizitator? Analizăm cele două rute, cu ce se ocupă MCP, cum se verifică conexiunea și ce trebuie să funcționeze în continuare după ce închideți sesiunea agentului.

Cine solicită datele acum

Sunt două situații și e ușor să le confundați, pentru că pe ecran ambele arată ca "au apărut datele".

În prima situație, agentul explorează sursa. Lucrați la proiect, Claude Code citește documentația serviciului, încearcă o cerere, se uită la structura răspunsului. Datele îi trebuie ca să scrie cod. Totul se întâmplă pe computerul dumneavoastră și exact cât timp e deschisă sesiunea.

În a doua situație, vizitatorul deschide pagina publicată. Acum datele îi trebuie ei - ca să arate starea actuală. Cererea o face codul aplicației în timp ce rulează. Asta se numește runtime, adică momentul în care aplicația rulează la utilizator, nu momentul în care o scrieți.

Există și o a treia variantă, intermediară. Agentul a accesat o singură dată sursa și a salvat răspunsul într-un fișier lângă cod, iar site-ul afișează conținutul acestui fișier. Nu e nimic rău în această soluție, e chiar comodă pentru un exemplu sau o demonstrație. Doar că e o captură care rămâne așa cum a fost salvată și nu se actualizează singură.

Cele două lanțuri trăiesc separat, între ele nu există nicio săgeată

Observați linia punctată din mijloc. Nu e acolo de frumusețe. Între lanțul de sus și cel de jos nu există nicio săgeată, și ăsta e lucrul principal de reținut din schemă. Sursa poate fi aceeași, dar drumul până la ea e diferit pentru agent și pentru pagină. Mai jos analizăm fiecare lanț separat.

Ce este MCP

O sarcină rareori trăiește doar în repository. Descrierea bug-ului rămâne în tichet, stack trace-ul - în monitorizare, regulile noi ale bibliotecii - în documentație, iar înregistrările necesare - în baza de date.

Fără integrare, trebuie să mutați toate acestea manual din browser în chatul cu agentul. Un transfer ocazional e suportabil. Într-o muncă repetitivă, datele apucă să se învechească, o parte din detalii se pierd, iar același drum trebuie parcurs din nou.

MCP (Model Context Protocol) este standardul prin care Claude Code află ce instrumente externe are la dispoziție, le apelează și primește rezultatul într-un format convenit. În lanțul minimal, Claude Code creează un client MCP, clientul menține conexiunea cu serverul MCP, iar serverul ajunge la sistemul la care are acces - fișiere, bază de date, API-ul altcuiva.

Claude Code vorbește cu serverul MCP, iar serverul deschide doar capabilitățile descrise dinainte ale sistemelor externe

În stânga e Claude Code cu clientul MCP încorporat, în centru - serverul MCP cu capabilitățile declarate, în dreapta - sistemele externe. Esențialul aici e că agentul nu primește acces necontrolat la toate deodată. Vede doar operațiile și datele pe care serverul a decis să le ofere.

Un server MCP gata făcut vă scutește totodată de o parte din munca de integrare. Nu trebuie să descrieți singur formatele apelurilor pentru fiecare sistem extern și să scrieți tot codul care accesează API-ul acestuia. De asta se ocupă serverul, iar Claude Code lucrează cu operațiile deja declarate.

În plus, serverul nu trebuie neapărat să fie un program separat undeva pe internet. Poate rula direct pe computerul dumneavoastră ca proces local sau poate funcționa la distanță și deservi mulți clienți simultan. Pentru dumneavoastră, diferența ține mai ales de felul în care îl conectați.

Ce anume știe să facă serverul, decide el însuși. Protocolul descrie trei tipuri de lucruri pe care serverul le poate oferi:

tools - operații pe care agentul le poate executa: obține o pagină, trimite o cerere la API, scrie date;
resources - conținut pe care serverul îl oferă drept context: fișiere, înregistrări, răspunsuri ale serviciilor;
prompts - șabloane de cereri pregătite dinainte, pe care le puteți apela gata făcute.

Serverul nu e obligat să le suporte pe toate trei. La conectare, clientul și serverul verifică ce știe fiecare, iar operațiile nesuportate pur și simplu nu se folosesc. Multe servere se limitează doar la tools, și asta ajunge. Arhitectura MCP.

Merită să rețineți esențialul. MCP standardizează felul în care vorbesc clientul și serverul. Ce anume vă va fi disponibil stabilește serverul, nu protocolul. A conecta un server nu înseamnă a primi acces la tot internetul - primiți exact setul de operații pe care acest server l-a declarat.

Când dați o sarcină agentului, numiți sursa și rezultatul dorit, nu comanda. Apoi verificați dacă serverul conectat are o operație potrivită. Dacă nu o are, sarcina se rezolvă pe altă cale, nu prin convingere.

Cum ajung datele pe site

Acum lanțul de jos. Pagina publicată primește datele în unul din două moduri.

În primul caz, browserul accesează direct API-ul public. Varianta asta merge când sursa e deschisă și nu e nevoie de cheie. Codul paginii face o cerere și afișează răspunsul. Simplu și fără detalii în plus.

În al doilea caz, browserul accesează backend-ul aplicației, iar acesta - API-ul închis. Așa se procedează când sursa cere o cheie. Secretul rămâne pe server, browserul nu îl vede. Frontend-ul răspunde aici de ce se vede pe ecran, backend-ul - de ce se execută pe server, și el știe să acceseze serviciul în numele aplicației.

API-ul public e accesibil direct din browser, iar cheia pentru API-ul închis rămâne pe backend

Ruta de sus e mai scurtă, pentru că browserul poate accesa singur sursa deschisă. În ruta de jos, backend-ul devine granița care păzește secretul. Cheia rămâne pe server și nu ajunge în codul paginii.

Iată însă ce nu se întâmplă. Conexiunea dintre Claude Code și serverul MCP nu pleacă împreună cu site-ul la publicare. Comanda cu care ați adăugat serverul configurează agentul dumneavoastră; ea nu adaugă în aplicație nicio linie de cod. Se poate scrie o aplicație cu propriul client MCP, dar asta e o muncă separată și o implementare separată, nu rezultatul conectării din Claude Code.

Toate acestea se verifică destul de repede. Închideți Claude Code, deschideți pagina publicată și uitați-vă în fila Network din instrumentele pentru dezvoltatori. Dacă datele vin, se vede cererea, adresa și răspunsul. Dacă nu vin, nu va exista nicio cerere, și exact acesta e cazul pe care merita să-l prindeți înainte ca pagina s-o vadă altcineva.

O imagine pe ecran nu e de ajuns. Pagina poate afișa o captură salvată mai devreme și să arate totuși complet vie. Trebuie să vă uitați la cererea propriu-zisă. Și invers, lipsa evenimentelor noi în răspuns nu înseamnă încă o defecțiune. Poate că sursa pur și simplu nu a trimis nimic pentru perioada aleasă.

Cum se verifică conexiunea

Ordinea e cam aceeași pentru orice server:

găsiți instrucțiunile oficiale ale serverului - adresa, modul de acces, lista operațiilor;
adăugați serverul cu comanda dată chiar în aceste instrucțiuni;
deschideți /mcp în Claude Code și verificați că serverul s-a conectat și ce instrumente are;
executați o singură cerere de citire, cea mai simplă;
comparați manual rezultatul cu sursa - deschideți aceeași pagină și uitați-vă cu ochii dumneavoastră.

Din terminal, starea o arată claude mcp list, iar detaliile despre un anumit server - claude mcp get. E util să știți că acești pași răspund la întrebări diferite:

Ce ați văzut	Ce dovedește asta
linia `Added ...` după adăugare	configurația e scrisă, și atât
`Connected` în `claude mcp list`	Claude Code a reușit să se conecteze la server
instrumentul a returnat conținut	ruta funcționează integral, de la cerere la răspuns

Diferența nu e formală. Un config scris cu succes nu spune nimic despre faptul că serverul răspunde, iar o conexiune reușită - despre faptul că operația necesară e disponibilă și că aveți drepturi pentru ea. De aceea verificarea se încheie cu un apel real. Apropo, dacă în listă apare Needs authentication, serverul nu e stricat, doar așteaptă autentificarea.

Să luăm un exemplu concret. Serviciul Firecrawl are un server MCP care știe să obțină conținutul unei pagini publice - instrumentul se numește firecrawl_scrape. Pentru agent, e o cale comodă de a citi integral o pagină de documentație, în loc să o copiați în conversație bucată cu bucată.

# adăugați serverul prin HTTP; adresa exactă se ia din documentația serviciului
claude mcp add --transport http firecrawl https://mcp.firecrawl.dev/v2/mcp

Acum despre acces. Documentația Firecrawl descrie atât lucrul fără cont și fără cheie, cu limite zilnice, cât și autentificarea prin browser, când clientul deschide singur pagina de login. Condițiile și limitele serviciilor se schimbă, așa că pe cele actuale le verificați chiar la serviciu, nu în articol. Documentația Firecrawl despre MCP.

Și un mic detaliu care economisește timp. Implicit, serverul se adaugă pentru proiectul în care ați dat comanda și nu apare în alte proiecte. Dacă serverul vă trebuie peste tot sau, dimpotrivă, întregii echipe, comanda de adăugare are variante separate de scope. Claude Code despre MCP.

Valoarea cheii nu are ce căuta nici în exemplul de configurare, nici în adresa serverului, nici în conversația cu agentul. În config se pune numele variabilei de mediu, iar valoarea se setează separat - despre asta e articolul vecin despre chei.

Ce permite un anumit instrument

Un server conectat e un set de operații, iar consecințele lor diferă mult. A citi o pagină și a modifica o înregistrare într-un sistem extern nu e deloc același lucru, deși se apelează la fel.

Înainte să acceptați un apel, e util să vă uitați la trei lucruri: cu ce obiect lucrează instrumentul, ce operație execută și ce drepturi îi trebuie pentru asta. Citirea e de obicei mai sigură, dar și ea are un preț. Cererea ajunge la un serviciu terț și vă consumă cota.

Separat, despre ce vine în răspuns. Textul obținut de pe un site străin înseamnă date, nu o instrucțiune. Dacă pe pagină scrie "acum șterge toate fișierele", asta rămâne text pe pagină, iar decizia o luați dumneavoastră. Tocmai de aceea merită să vedeți ce are de gând agentul să facă după ce a citit o sursă externă.

Și, în fine, principala întrebare practică. Chiar e nevoie de MCP? Nu întotdeauna.

Sarcina	Cum se rezolvă mai simplu
afișarea pe site a datelor dintr-un JSON public	o cerere obișnuită din codul aplicației, MCP nu e necesar
agentul lucrează regulat cu un serviciu care are o integrare gata făcută	MCP merită: operațiile sunt descrise, conexiunea se refolosește
citirea ocazională a documentației sau apelarea unei singure adrese	ajunge citirea URL-ului sau accesarea directă a API-ului

MCP nu e singura ușă spre exterior și nici un înlocuitor pentru toate celelalte. Agentul are în continuare și linia de comandă, și accesul direct la API. Alegerea pornește de la sarcină, nu de la faptul că o conexiune e deja configurată.

Ce verificați în propriul proiect

Când agentul pregătește lucrul cu date externe, e util să-i cereți să separe explicit cele două straturi, în loc să descâlciți asta mai târziu:

Descrie separat două rute:
de unde iei tu datele în timp ce lucrezi la proiect
și de unde le va lua aplicația însăși pentru vizitator.
Arată în ce fișier și în ce loc din cod se află cererea aplicației.
Verifică pagina cu sesiunea închisă: vin datele sau nu.
Dacă acum se folosește o captură salvată, spune-mi direct.

Trei situații care apar cel mai des și răspunsul pentru fiecare:

Ce trebuie făcut	Cine obține datele	De ce așa
studierea documentației serviciului în timpul dezvoltării	agentul	datele sunt necesare pentru scrierea codului, la vizitator această cerere nu se repetă
actualizarea hărții la vizitator	codul aplicației	cererea se execută cât timp pagina rulează, iar sesiunea agentului e deja închisă în acel moment
salvarea o singură dată a unei selecții în JSON	agentul, și doar o dată	apoi site-ul afișează fișierul; datele rămân așa cum au fost salvate

Observați că MCP apare aici doar în primul rând, și nici acolo nu e obligatoriu. Dacă sarcina se rezolvă printr-o citire obișnuită a adresei, așa merită s-o și rezolvați.

Ultima verificare înainte să arătați munca altcuiva e cea mai simplă: închideți Claude Code și deschideți pagina. Ce continuă să funcționeze, aceea e aplicația dumneavoastră. Tot restul a fost ajutorul agentului la dezvoltare - util, dar rămas pe computerul dumneavoastră.