AI Agent intervju pitanje četvrti talas: MCP, Chrome DevTools, CDP sesija ponovne upotrebe

content

01, Šta je MCP, koji problem rešava

MCP puni naziv Model Context Protocol, je protokol koji je A firma krajem 2024. izbacila, u jednoj rečenici objašnjenje: dao je standardni komunikacijski interfejs između AI aplikacija i spoljnih alata.

Zašto treba ovaj protokol?

Pre MCP, svaka AI aplikacija da se poveže na jedan novi alat mora sama napisati jedan set prilagođenog koda, ti pišeš svoje, ja pišem svoje, dupli rad.

Claude Code da se poveže na GitHub, napiše jedan set; Qoder da se poveže na GitHub, još jedan set — isti posao, ali se kod uopšte ne može ponovno koristiti.

Sa MCP je drugačije, GitHub zvanično samo treba napisati jedan MCP Server, sve AI aplikacije koje podržavaju MCP direktno se povezuju, isto kao i USB ujedinjuje interfejs.

Šta konkretno rešava nekoliko problema

Ukratko tri stvari.

Otkrivanje alata — Host startuje MCP Server, poziva jednom tools/list zna što ovaj Server može raditi, ne treba unaprijed hardkodirati.

Poziv alata — ujedinjeno ide kroz tools/call interfejs, bez obzira da li je ispod Git operacija, pregledač manipulacija ili baza podataka upit, način poziva je potpuno isti, za Agent uopšte bez razlike.

Pristup podacima — resources/list plus resources/read dopušta Server da izloži čitljive izvore podataka, LLM kad treba kontekst direktno uzima.

02, Šta je razlika između MCP stdio transporta i Streamable HTTP transporta

stdio je standardni ulaz izlaz. Host startuje MCP Server kao podproces, kroz stdin šalje JSON-RPC poruke, stdout prima odgovor. Životni vek Server je potpuno kontrolisan od strane Host-a — Host izadje, stdin je EOF, Server sledi i završava.

Pogodno za lokalne alate, na primer chrome-devtools-mcp, mcp-server-git ove.

Streamable HTTP ide kroz mrežu. Host kroz HTTP POST šalje JSON-RPC zahtev, Server kroz SSE strim vraća odgovor. Server je nezavisno deploy-ovan udaljeni servis, sa Host nema smrtnu vezu, ti zatvoriš klijent, Server je još uvek živ.

Pogodno za cloud alate, tim deljeni MCP Server.

U konfiguracionom fajlu kako razlikovati? Takođe jednostavno, ima command polje ide stdio, ima url polje ide HTTP, PaiCLI sam procenjuje.

03, Kako radi MCP JSON-RPC komunikacioni protokol

Koristi JSON-RPC 2.0, poruke su tri vrste.

Request, nosi id, treba protivna strana odgovor. Na primer tools/list zahtev, id je 1, Host šalje posle čeka Server da vrati id takođe 1 Response.

Response, id se uparuje sa Request. Server primi id 1 zahtev, nakon obrade vraća isto id 1 odgovor, Host uzme id upari, zna to je rezultat kog zahteva.

Notification, nema id, ne treba odgovor, jednostrano obaveštenje. Na primer Server lista alata se promenila, gurne jednu tools/list_changed, Server primi sam ide ponovo izvući listu.

Kako implementirati uparivanje zahteva i odgovora

Jezgro je jedan ConcurrentHashMap, ključ je samorastući zahtev id, vrednost je CompletableFuture.

Šalješ zahtev korišćenjem samorastućeg id registruješ jedan Future, primaš odgovor kroz id pronalaziš odgovarajući Future i popunjavaš rezultat završavaš uparivanje. Ima još timeout zaštita, preko određenog vremena ne primi odgovor automatski izveštaj o timeout izuzetku, sprečava Future zauvek da visi.

Kompletan komunikacioni životni ciklus ovako izgleda:

Host prvo šalje initialize pregovara verziju i kapacitet → Server odgovara → Host šalje initialized označava "ja sam spreman" → poziva tools/list vuče listu alata → zatim ulazi u normalno radno stanje, korišćenjem tools/call izvršava alat → Server ima promena bilo kad gurne notification.

Zašto ovako odgovaraš: JSON-RPC sam po sebi nije težak, intervjuer ispituje da li si sam pisao. Pominjanjem ConcurrentHashMap + CompletableFuture realizuješ uparivanje zahtev-odgovor, objašnjavaš da ne samo znas koristiti SDK, nego stvarno dirao dna komunikacije.

04, Kako dizajnirati prostor imena nakon što se MCP alat registruje Agent-u

PaiCLI svaki put kad registruje MCP alat, koristi mcp__serverIme__alatIme ovaj format. Na primer chrome-devtools Server-ov navigate_page alat, nakon registracije se zove mcp__chrome-devtools__navigate_page.

Zašto koristiti dvostruki podvlaka

Jer ime alata samo nosi jednostruki podvlaku, kao navigate_page, take_screenshot.

Ako koristiš jednostruki podvluka kao separator, ne možeš razlikovati gde se završava ime servera, gde počinje ime alata. Dvostruki podvlaka u MCP imenu alata se ne pojavljuje, je prirodno bezbedan separator.

Ovaj dizajn prostora imena donosi i vrlo praktične prednosti:

• Izbegava konflikat, dva Server-a imaju istoimeni alat search, dodat prefiks neće zbuniti.
• Bezbedna izolacija, politika odobrenja može raditi po prefiksu, na primer korisnik kaže "propusti čitav chrome-devtools", poklapanje prefiksa je dovoljno.
• LLM razume, LLM vidi mcp__chrome-devtools__navigate_page, odmah može sudariti da je ovo pregledač srodna operacija.

05, Šta su MCP resources, koja je razlika sa alatima

Jednostavno, Tools su mogu raditi, imaju ulazne parametre, će promeniti stanje; Resources su mogu čitati, kroz URI pristup, vraća sadržaj, samo čitanje bez pisanja. Možeš razumeti Tools kao POST endpoint, Resources kao GET endpoint.

Ali stvarno korišćenje postoji jedan problem: LLM ne može direktno pozvati resources/read, jer Function Calling protokol ima samo koncept alata, nema resources.

Zato PaiCLI radi dve stvari da popuni ovu rupu.

Prvo je resources spakovati kao alat. Za svaki Server koji podržava resources automatski registruje dva virtualna alata — list_resources i read_resource. LLM može kao poziv običnog alata pozvati ih, prvo proveri koje resurse postoje, zatim po URI čita sadržaj.

Drugo je podržati korisnika direktno @ specificirati. Korisnik u unosu piše @server:protocol://path, PaiCLI pre podnošenja Agent-u automatski proširuje sadržaj resursa i ubacuje, ne prolazi kroz LLM odluku.

Dva načina imaju svoje primenjive scenarije: LLM treba aktivno istraživati podatke ide kroz alat, korisnik već zna čitati koji resurs direktno @ specificira.

06, Kako tretirati neuspeh startovanja ili timeout MCP Server-a

Ovaj problem u stvarnom razvoju stvarno često susreće, PaiCLI radio je nekoliko slojeva zaštite.

Prvo, initialize postavio 60 sekundi timeout, ne može jedan Server zablokirati ceo proces startovanja Agent-a.

Zatim, više Server-a su paralelno startuju, pozadinske niti svaki radi svoje, ne čekaju jedni druge.

Tokom startovanja svakih 5 sekundi ispisuje jedan status čekanja, kaže korisniku "određeni Server još nije spreman", ne čeka ljudi da ne znaju šta se dešava.

Konačno postoji još jedan /mcp restart komanda, neki Server pada može samostalno restartovati, ne treba sve ponovo početi.

07, Šta može Chrome DevTools MCP, kako radi podešavanje poslova sa web_fetch

Chrome DevTools MCP je Google zvanično izbačeni MCP Server, jednim dahom dao je 28 alata za operaciju pregledača. Čemu? Da LLM može kao pravi ljudi operisati pregledačem — otvori web stranicu, popuni formu, klikni dugme, napravi snapshot, uhvati mrežni zahtev, šti ti možeš, on sve može.

Već postoji web_fetch, zašto još Chrome DevTools MCP

web_fetch suština je jedan HTTP zahtev, može samo dobiti statički HTML. Susretne SPA, JS renderovane stranice, ima anti-crawl sajtove, potpuno nevidi. Pregledač MCP nije tako, on stvarno pokrenuo jednu Chrome instancu, JavaScript i dalje radi, prijavljeno stanje i dalje čuva, bilo koju stranicu može dobiti.

PaiCLI u system prompt-u ima jednu tabelu odluka, LLM će prema karakteristika zadatka sam proceniti kojim putem ide: statička stranica ide web_fetch, jeftino i brzo; SPA i JS renderovanje ide pregledač take_snapshot; anti-crawl sajt takođe ide pregledač; treba prijavljenu stranicu ide pregledač plus CDP sesiju ponovne upotrebe; treba popuniti formu i poslati ide fill_form + click.

08, Kako se realizuje CDP sesija ponovne upotrebe

Chrome DevTools MCP podrazumevano je isolated režim, svaki put startuje kreira jedan potpuno novi pregledač profil, nema prijavljeno stanje.

Zato PaiCLI realizuje CDP (Chrome DevTools Protocol) sesiju ponovne upotrebe.

Proces je ovakav: korisnik u svom Chrome-u normalno prijavljuje razne sajtove, zatim u PaiCLI izvršava /browser connect, MCP iz isolated režima prebaci na autoConnect režim. MCP Server povezuje na postojeću Chrome instancu korisnika, ponovno upotrebljava sve prijavljeno stanje. Tako Agent može direktno pristupiti već prijavljenim stranicama.

09, Koliko vrsta MCP mehanizma obaveštenja postoji?

Tri vrste: tools/list_changed lista alata se promenila, resources/list_changed lista resursa se promenila, resources/updated sadržaj određenog resursa je ažuriran.

PaiCLI primi tools/list_changed automatski ponovo vuče listu alata, primi resources srodna obaveštenja očisti odgovarajući cache, održava podatke sveže.

Zašto handler obaveštenja treba asinhrono izvršavati

Ako se logika rukovanja obaveštenjem direktno izvršava u niti čitanja poruka, unutra logika ako pošalje jedan JSON-RPC zahtev i čeka odgovor, će se desiti mrtva ključavnija.

Jer nit za čitanje je zauzeta, novi odgovor ušao je u bafer ali niko ne čita, čekani odgovor zauvek ne može pročitati. Tipičan scenarij je Server gurne tools/list_changed, logika rukovanja treba pozvati tools/list ponovo vući listu alata, rezultat sam čeka sam, mrtvo zaključano.

Zato PaiCLI koristi jednu nezavisnu jednu nit da radi asinhrono dispečer, rukovanje obaveštenjem i čitanje poruka su potpuno izolovani, potpuno izbjegava ovaj problem.

10, Kako tretirati MCP tools/call povratni rezultat

tools/call vraća jedan content niz, svaki element ima type polje, uglavnom tri vrste: text, image, resource.

text je najjednostavniji, direktno spaja u string kad tool message vrati LLM.

image tip je malo komplikovaniji. Prvo dekodira base64, ako uspe generiše prilog slike, u sledećem krugu razgovora šalje LLM. Ako obrada ne uspe, na primer slika je prevelika ili format nije podržan, degradira u tekstualni podssetnik, kaže LLM da koristi take_snapshot da dobije DOM tekstualni snapshot.

resource tip je izdvaja tekstualni sadržaj, spaja u text rezultate zajedno vraća.

Ako izvršenje alata ne uspe, isError je true, ceo rezultat se pakuje u "MCP alat vratio grešku" format, LLM vidi posle zna da poziv neuspeo, može odlučiti da li ponoviti ili promeniti ideju.

11, Koja je veza između MCP-a i Function Calling

Ovo dva često se mešaju, ali zapravo delovi posla su jasni.

Function Calling je LLM API sloj protokol, radi dve stvari: kaže LLM-u "koje alate imaš na raspolaganju", i daje LLM-u kaže "hoću da pozovem ovaj alat".

MCP je protokol strane alata, rešuje "alat odakle dolazi, kako izgleda, kako izvršiti".

Spajajući gledaš jasno: MCP Server kroz tools/list vraća definiciju alata → PaiCLI te definicije pretvara u Function Calling format → stavlja u LLM zahtev tools polje → LLM vraća tool_calls kaže "hoću da pozovem određeni MCP alat" → PaiCLI kroz MCP tools/call izvršava → rezultat opet hrani LLM.

U jednom rečenicom sažetak: MCP upravlja "alat odakle", Function Calling upravlja "LLM kako bira". Dva protokola svako upravlja jedan segment, zajedno su kompletna lančuga poziva alata.

12, Šta je MCP schema čišćenje, zašto treba

Definicija parametara alata koje MCP Server vraća je standard JSON Schema, ali LLM nije JSON Schema parser, neke kompleksne strukture ne dobro radi.

Tipično postoji tri problema:

• $ref referenca, JSON Schema dozvoljava korišćenje $ref pokazuje na drugo mesto definiciju, ali LLM neće "ići u rečnik", vidi $ref zbunjuje, generisani parametri verovatno neće poklopiti.
• anyOf/oneOf tip unije, parametar može biti string ili number, LLM verovatnost pogrešnog izbora tipa je vrlo visoka.
• Preduga description, neki MCP Server opis alata napisao nekoliko hiljada reči, ceo API dokument uvecao, LLM je info preplavljen zapravo ne razume ključni parametar.

Zato PaiCLI pri registraciji alata automatski radi jednu rundu čišćenja: $ref direktno razvija ili uklanja, anyOf/oneOf pretvara u prirodni jezik description stavlja, predugu description seče. Nakon čišćenja schema je LLM prijateljskiji, tačnost generisanja parametara je viša.

13, Ako te budes pustio da dizajniraš jedan MCP Server, kako biš

Prvo odredi način transporta. Alat radi na lokalnom korisničkom računaru bira stdio, radi na cloud deljen više ljudi bira Streamable HTTP.

Zatim u initialize handshake-u deklariše kapacitet — Server podržava tools, resources ili prompts, u handshake fazi jasno kaže Host.

Sledeće je dizajn alata, ovaj korak je najkritičniji. Svaki alat jedinstvene odgovornosti, parametar schema strogo definisan. Opis alata je napisan za LLM čitanje, treba jasno reći "ovaj alat šta radi, kad treba koristiti, kad ne treba koristiti", kvalitet opisa direktno utiče na LLM tačnost poziva.

Rukovanje greškama. Izvršenje alata ne uspe vrati isError: true, doda značajnu info greške, LLM može sudariti sledeći korak šta raditi.

Upravljanje životnim vekom. stdio režimu treba ispravno tretirati stdin EOF i očistiti resurse, HTTP režimu treba tretirati sesiju timeout i konkurentne zahteve.

Konačno je oznaka bezbednosti. Ako Server može pristupiti osetljivim podacima ili izvršiti opasne operacije, u tool description označi. Host strana mehanizam bezbednosti može prema description ključnim rečima prilagoditi politiku odobrenja.