MCP arhitektura: kompletna tehnička analiza sa dijagramima
Tehnička analiza MCP arhitekture koja obuhvata hostove, klijente i servere, JSON-RPC sloj podataka, opcije transporta, postavke sa više zakupaca, bezbednosne rizike i objašnjenje zahteva u osam koraka, uz dijagrame.

MCP arhitektura je osnovni skup komponenti i pravila komunikacije koji omogućavaju MCP (Model Context Protocol). MCP je standard otvorenog koda, a MCP arhitektura je infrastruktura na kojoj se zasniva njegov rad.
Svaka MCP arhitektura sadrži tri osnovne komponente oko kojih je izgrađena: host, klijent i server. Za komunikacioni okvir MCP-a često se kaže da se sastoji od sloja podataka i transportnog sloja. Sloj podataka je skup pravila o tome kako se poruke formatiraju (MCP zahtevi se šalju u formatu JSON-RPC 2.0). Transportni sloj prenosi te poruke, koristeći Streaming HTTP za spoljne veze.
Šta je MCP arhitektura?
MCP arhitektura je serverski okvir koji implementira Model Context Protocol, otvoreni standard za povezivanje AI modela sa alatima, resursima kao što su baze podataka i promptovima koji proširuju ulazni kontekst. Oni se zajedničkim imenom nazivaju „primitivi“. U suštini, MCP arhitektura omogućava LLM-ovima da otkriju koji su alati dostupni i da izvršavaju radne tokove, a sve to bez potrebe za redovnim ažuriranjima na strani klijenta.
Otkako ju je predstavila kompanija Anthropic, MCP arhitektura se široko koristi u AI radnim tokovima. To je u velikoj meri zato što zamenjuje sisteme koji zahtevaju više održavanja, kao što su oni izgrađeni oko više API veza, bez žrtvovanja performansi. Pošto se sva dostupna funkcionalnost nalazi iza MCP servera, potrebna je samo jedna veza, a ažuriranja i dodaci su odmah dostupni klijentskoj aplikaciji.
Komponente MCP arhitekture: hostovi, klijenti i serveri
MCP pruža LLM-ovima način da otkriju i pozivaju alate, promptove i resurse koji su im dostupni, bilo na lokalnom sistemu host aplikacije ili od spoljnog dobavljača.
Kod alata, koji omogućavaju pristup spoljnoj funkcionalnosti, otkrivanje podrazumeva da host uputi MCP serveru poziv tools/list kako bi saznao koji su alati dostupni. LLM (ili u nekim slučajevima host) zatim može da pročita opise dostupnih alata i da ih zatraži po potrebi. Promptovi i resursi koriste sličan proces.
Ovo je u suprotnosti sa namenski izrađenom arhitekturom zasnovanom na API-jima, koja je bila norma u razvoju softvera, gde je funkcionalnost izvan aplikacije morala da se poziva preko namenskih veza sa precizno formatiranim zahtevima.
Host
Host aplikacija je centralna platforma za orkestraciju i povezuje se sa LLM-om. Poznati alati kao što su Perplexity i Claude Desktop mogu da služe kao hostovi u okviru MCP sistema.
U jednostavnom radnom toku, korisnik postavlja pitanje preko interfejsa za čet. Komponenta orkestratora u hostu zatim dodaje kontekst pitanju i saopštava LLM-u koji su MCP primitivi dostupni, zajedno sa opisom njihovih mogućnosti.
Klijent
Klijent je softverska komponenta u AI aplikaciji. MCP pruža standardni interfejs preko kog klijent komunicira sa internim i spoljnim MCP serverima na osnovu uputstava hosta ili LLM-a. Njegov zadatak je da uspostavi vezu, formatira JSON-RPC poruke, šalje zahteve i prima odgovore.
Termini „MCP host“ i „MCP klijent“ ponekad se koriste kao sinonimi. Međutim, ta razlika je korisna jer host, kao što je Perplexity, može istovremeno da orkestrira više MCP klijenata. Složen AI radni tok može da zahteva pristup desetinama ili čak stotinama zasebnih MCP servera, a svaki od njih će koristiti zasebnu vezu.
Server
Server izlaže sve alate koje AI alat može da koristi. Sa stanovišta arhitekture, MCP server tumači dolazni zahtev i, kada je potrebno, povezuje se sa traženim primitivima.
MCP serveri mogu da omoguće pristup trima kategorijama primitiva:
- Alati: U suštini, to su spoljne softverske funkcionalnosti. Ako uzmete u obzir tradicionalni pristup zasnovan na API-jima, aplikacija za veb-analitiku može da preuzima podatke pomoću formatiranog zahteva upućenog spoljnom serveru. U MCP arhitekturi, sva funkcionalnost trećih strana od jednog dobavljača dostupna je preko jedne veze, a zahtevi se kreiraju prema standardnim pravilima formatiranja.
- Resursi: Resursi su izvori podataka koji pružaju kontekst samo za čitanje. Šeme baza podataka su dobar primer. MCP server izlaže različite izvore informacija koji su dostupni hostu. Ako host upućuje upit bazi podataka, na primer putem SQL pretrage koju generiše LLM, to se smatra zahtevom za alat.
- Promptovi: To su šabloni promptova za višekratnu upotrebu koji pomažu LLM-ovima da obave određene zadatke. Korisnik ili host će pozvati prompt umesto alata zato što su za obavljanje zadatka potrebna gotova uputstva. Unapred podešeni zadaci u host aplikaciji, kao što su opcije „pregledaj kod“ ili „analiziraj podatke“, često se čuvaju kao promptovi koje korisnik može da izabere.
Takođe vredi napomenuti da MCP i API nisu međusobno isključive tehnologije. MCP server može da izloži API pozive koji su dostupni kao odgovor na zahtev za otkrivanje. Ključno je da je njihovo održavanje odgovornost MCP dobavljača, a ne klijenta.
Šta je sloj podataka u MCP arhitekturi?
Sloj podataka u MCP arhitekturi je skup pravila koja definišu kako se formatiraju zahtevi, odgovori i obaveštenja. Standardni jezik za poruke je JSON-RPC.
Svaka MCP arhitektura prati osnovni proces koji čine (1) inicijalizacija i otkrivanje od strane hosta, (2) odgovor MCP servera i (3) poziv od strane hosta (o kom ponekad odlučuje LLM), pri čemu svaka faza predstavlja zasebnu JSON poruku.
Pogledajmo kako funkcioniše otkrivanje alata kroz dva primera (oni se mogu primeniti i na resurse ili promptove):
- Otkrivanje alata pre generisanja od strane LLM-a: Host inicijalizuje MCP klijent, koji šalje zahtev tools/list (listu dostupnih alata MCP servera). LLM to pregleda tokom procesa generisanja i utvrđuje da li je potreban određeni alat, resurs ili prompt.
- Davanje LLM-u mogućnosti da pokrene pretragu: U agentskom sistemu, host dodaje opciju otkrivanja, kao što je search-tools, ulaznom kontekstu, a LLM po potrebi može da zatraži pretragu.
Alate, koji su uglavnom funkcionalnosti spoljnih aplikacija, obično bira LLM ili host. Resursi i promptovi se obično traže na zahtev korisnika ili od strane hosta.
Evo kako izgleda zahtev tools/list MCP serveru iz jedne zamišljene aplikacije za beleške:
{
"jsonrpc": "2.0",
"id": 101,
"method": "tools/list",
"params": {
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": {
"name": "notes-app-client",
"version": "0.1.0"
},
"io.modelcontextprotocol/clientCapabilities": {}
}
}
}U ovom primeru, “id”:101 identifikuje zahtev pomoću ID-a kako bi klijent mogao da upari odgovore, a polje “params” sadrži dodatne informacije o klijentu, kao što su naziv klijenta (notes-app-client) i mogućnosti.
Kao odgovor, MCP server će vratiti definicije alata, koje uključuju nazive dostupnih alata i povezane detalje. Na primer, lista može da sadrži alat add-task koji aplikaciji za beleške omogućava da kreira zadatke u povezanoj aplikaciji za upravljanje zadacima ili kalendaru, dodeljujući svakom zadatku naslov i prioritet.
Evo kako bi zahtev mogao da izgleda:
{
"jsonrpc": "2.0",
"id": 202,
"method": "tools/call",
"params": {
"name": "add-task",
"arguments": {
"title": "Review the draft",
"priority": "medium"
},
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": {
"name": "notes-app-client",
"version": "0.1.0"
},
"io.modelcontextprotocol/clientCapabilities": {}
}
}
}Polje “method” saopštava MCP serveru da je u pitanju poziv alata, “name” određuje koji alat treba pozvati, a “arguments” pruža potrebne ulazne podatke.
Šta je transportni sloj u MCP arhitekturi?
Ako je sloj podataka šta veze između klijenta i MCP servera, transportni sloj je kako. On definiše način na koji poruke putuju: konkretan kanal i pravila koja određuju kako se zahtevi i odgovori isporučuju.
MCP ima dve transportne putanje:
- Standardni ulaz/izlaz: Koristi se kada MCP server radi u istom lokalnom okruženju kao i host aplikacija. Klijent upisuje JSON zahtev u standardni ulaz servera. Server ga čita, izvršava traženu operaciju i upisuje odgovor u standardni izlaz.
- Streamable HTTP: Kada MCP server radi izvan host aplikacije, MCP klijent šalje zahteve serveru koristeći HTTP POST. Server odgovara jednom JSON porukom ili tokom Server-Sent Events (SSE), trajnim kanalom za „osluškivanje“, što mu omogućava da vraća više poruka tokom vremena.
Šta je MCP arhitektura sa više zakupaca?
MCP arhitektura sa više zakupaca (multi-tenant) je vrsta implementacije koja može istovremeno da opslužuje više korisnika (zakupaca).
Ovde zakupac može biti pojedinac, grupa pojedinaca ili organizacija. Implementacija može da podrazumeva pokretanje zasebnog MCP servera za svakog zakupca, pružanje pristupa jednom zajedničkom serveru ili postavljanje skupa servera iza centralnog mrežnog prolaza (gateway). Kada se koristi mrežni prolaz, on usmerava zahteve ka odgovarajućim krajnjim tačkama na osnovu identiteta korisnika ili prirode zahteva.
Funkcioniše po istom osnovnom principu kao standardna MCP arhitektura, ali se zahtevi pojedinačnih korisnika obrađuju u njihovom sopstvenom radnom prostoru (čak i ako to podrazumeva deljene resurse) i zasebno se autentifikuju. Česta je u poslovnim scenarijima, a deljeni resursi se često preferiraju jer bi pokretanje više MCP servera bilo nepotrebno skupo.
Dijagram MCP arhitekture: objašnjenje korak po korak
Kako u praksi izgleda MCP zahtev od početka do kraja? Postoji osam ključnih faza, a svaka od njih uključuje zasebnu komponentu arhitekture.
Evo kako poziv MCP alata izgleda u praksi, na prethodnom primeru aplikacije za beleške povezane sa uslugom za upravljanje zadacima:
- Otkrivanje alata: Aplikacija za beleške (host) koristi svoj MCP klijent da bi putem zahteva tools/list zatražila dostupne alate servera. Server vraća njihove nazive, opise i očekivane ulazne podatke, uključujući i one za alat add-task. Ovo se može dogoditi pre nego što pošaljete prompt.
- Unos korisnika: Šaljete zahtev aplikaciji za beleške zasnovanoj na LLM-u preko ugrađenog četbota, na primer: „Napravi zadatak u mom kalendaru da pregledam svoj novi nacrt, sa srednjim prioritetom.“
- Obrada u modelu: Host šalje vaš zahtev i relevantne definicije alata LLM-u.
- Izbor alata: LLM generiše strukturirani zahtev za alat, navodeći alat i njegove ulazne podatke: add-task sa title: Review the draft i priority: Medium. Host proverava da li je radnja dozvoljena i prosleđuje zahtev MCP klijentu, koji šalje JSON-RPC poruku.
- Zahtev: MCP klijent šalje zahtev tools/call svom MCP serveru.
- Izvršavanje alata: MCP server poziva API aplikacije za upravljanje zadacima kako bi kreirao novi zadatak sa navedenim naslovom i prioritetom.
- Vraćanje rezultata: Server šalje rezultat nazad MCP klijentu, koji ga prosleđuje hostu. Host ga dodaje informacijama koje se dostavljaju LLM-u.
- Generisanje odgovora: LLM koristi rezultat da bi generisao odgovor za korisnika, na primer: „Kreiran je zadatak za pregled nacrta sa srednjim prioritetom.“
Po čemu se MCP arhitektura razlikuje od tradicionalne API arhitekture?
MCP i tradicionalna API arhitektura često se mešaju, ali to su komplementarne tehnologije. MCP je osmišljen posebno za aplikacije zasnovane na veštačkoj inteligenciji. On prevazilazi veliko opterećenje održavanja koje nose implementacija i upravljanje većim brojem fiksno kodiranih API veza.
Time što host aplikaciji obezbeđuje jednu vezu po dobavljaču funkcionalnosti ili internom resursu, MCP pomaže u rešavanju problema preopterećenog ulaznog konteksta (navođenje svih API-ja) ili ograničenih skripti aplikacija zasnovanih na API-jima.
Umesto toga, MCP-ovi mogu da izlože API-je (ili, tačnije, funkcionalnost koja poziva API-je) kao deo svoje liste alata. Kad god dobavljač ažurira svoju aplikaciju i pojavi se novi API, ili ako se dokumentacija promeni, dovoljno je da ažurira MCP server. Na strani host aplikacije nisu potrebne nikakve izmene koda.
Da li je MCP arhitektura bezbedna?
Bezbednost MCP-a je od njegovog predstavljanja predmet brojnih rasprava. Iako se generalno smatra bezbednom tehnologijom, postoji nekoliko bezbednosnih rizika, od kojih su mnogi izraženiji u složenim implementacijama arhitekture.
MCP arhitektura ima sledeće potencijalne slabosti:
- Ubacivanje promptova (prompt injection): Korisnik ubacuje zlonamerni prompt u spoljne podatke, a AI model ga pogrešno tumači kao uputstvo.
- Prekomerne privilegije pristupa: MCP serveri potencijalno mogu da izlože veliki broj alata AI modelu, što može da poveća mogućnost bezbednosnih problema (radijus štete).
- Slučajno curenje podataka: Loše konfigurisane implementacije mogu dovesti do toga da osetljive informacije, poput API ključeva ili akreditiva za bazu podataka, budu prosleđene LLM-u.
- Manipulacija lokalnim sistemom: Lokalni MCP serveri su podjednako ranjivi na probleme lokalnog sistema, poput zlonamernih skripti, kao i sve druge aplikacije, uz dodatni problem što mogu imati štetne posledice koje se prenose dalje na agentske AI sisteme.
Nijedan od ovih problema nije nepremostiv. Često su ustaljene mere sve što je potrebno da bi se osigurala bezbednost sistema. Mere kao što su uključivanje čoveka u proces, sprovođenje strogih kontrola nad osetljivim podacima i zaštita od napada na servere uobičajene su prakse.
Kakva je budućnost MCP arhitekture?
MCP se pokazao kao koristan i popularan otvoreni standard za programere. On prevazilazi mnoge probleme fiksno kodiranih API-ja u aplikacijama zasnovanim na LLM-ovima i znatno smanjuje obim kodiranja za programere.
U budućnosti će osnovna arhitektura hosta i servera u MCP-u gotovo sigurno ostati ista. Buduće inovacije biće usmerene na napredne agentske mogućnosti u radnim tokovima sa više koraka.
Pored toga, biće potrebne jače bezbednosne zaštite kako se te agentske funkcionalnosti budu uvodile, kao i skalabilna arhitektura, posebno u transportnom sloju, kako AI sistemi budu postajali obimniji i složeniji.