MCP arhitektura: detaljna tehnička analiza s dijagramima

MCP arhitektura temeljni je skup komponenti i komunikacijskih pravila koji omogućuju MCP (Model Context Protocol). MCP je standard otvorenog koda, a MCP arhitektura temeljna je infrastruktura na kojoj on radi.

Svaka MCP arhitektura sadrži tri ključne komponente i izgrađena je oko njih: host, klijent i poslužitelj. Komunikacijski okvir MCP-a često se opisuje kao sastavljen od podatkovnog i transportnog sloja. Podatkovni sloj skup je pravila o tome kako se poruke oblikuju (MCP zahtjevi šalju se u formatu JSON-RPC 2.0). Transportni sloj prenosi te poruke, a za vanjske veze koristi Streaming HTTP.

MCP arhitektura okvir je poslužitelja koji implementira Model Context Protocol, otvoreni standard za povezivanje AI modela s alatima, resursima poput baza podataka i promptovima koji proširuju ulazni kontekst. Oni se zajednički nazivaju „primitivi“. U konačnici, MCP arhitektura omogućuje LLM-ovima da otkriju koji su alati dostupni i izvršavaju tijekove rada, a da pritom nisu potrebna redovita ažuriranja na strani klijenta.

Dijagram MCP arhitekture: AI aplikacija razmjenjuje zahtjeve s MCP poslužiteljem, koji pruža alate, resurse i promptove.

Otkako ju je predstavio Anthropic, MCP arhitektura postala je široko rasprostranjena u AI tijekovima rada. To je ponajprije zato što zamjenjuje sustave zahtjevnije za održavanje, poput onih izgrađenih oko više API veza, bez gubitka performansi. Budući da se sva dostupna funkcionalnost nalazi iza MCP poslužitelja, potrebna je samo jedna veza, a ažuriranja i dodaci odmah su dostupni klijentskoj aplikaciji.

MCP daje LLM-ovima način da otkriju i pozovu alate, promptove i resurse koji su im dostupni, bilo na lokalnom sustavu host aplikacije bilo od vanjskog pružatelja.

Kod alata, koji omogućuju pristup vanjskoj funkcionalnosti, otkrivanje podrazumijeva da host uputi poziv tools/list MCP poslužitelju kako bi saznao koji su alati dostupni. LLM (ili u nekim slučajevima host) zatim može pročitati opise dostupnih alata i po potrebi ih zatražiti. Promptovi i resursi koriste sličan postupak.

Dijagram komponenti MCP arhitekture: host koji sadrži LLM, orkestrator i klijent povezuje se s MCP poslužiteljem u dva koraka, najprije otkrivanjem, a zatim zahtjevima, a MCP poslužitelj stavlja na raspolaganje alate, resurse i promptove.

To je u suprotnosti s prilagođenom arhitekturom temeljenom na API-jima, koja je bila norma u razvoju softvera i u kojoj se funkcionalnost izvan aplikacije morala pozivati putem namjenskih veza s precizno oblikovanim zahtjevima.

Host aplikacija središnja je platforma za orkestraciju i povezuje se s LLM-om. Poznati alati poput aplikacija Perplexity i Claude Desktop mogu djelovati kao hostovi unutar MCP sustava.

U jednostavnom tijeku rada korisnik postavlja pitanje putem sučelja za chat. Komponenta orkestratora unutar hosta zatim pitanju dodaje kontekst i obavještava LLM koji su MCP primitivi dostupni, uz opis njihovih mogućnosti.

Klijent je softverska komponenta u AI aplikaciji. MCP pruža standardno sučelje putem kojeg klijent komunicira s internim i vanjskim MCP poslužiteljima na temelju uputa hosta ili LLM-a. Njegov je zadatak uspostaviti vezu, oblikovati JSON-RPC poruke, slati zahtjeve i primati odgovore.

Pojmovi „MCP host“ i „MCP klijent“ ponekad se koriste kao sinonimi. Ipak, riječ je o korisnom razlikovanju jer host kao što je Perplexity može istodobno orkestrirati više MCP klijenata. Složen AI tijek rada mogao bi zahtijevati pristup desecima ili čak stotinama zasebnih MCP poslužitelja, a svaki od njih koristit će zasebnu vezu.

Dijagram MCP hosta, kao što je Perplexity, koji orkestrira tri MCP klijenta, od kojih je svaki povezan s vlastitim MCP poslužiteljem, kao što su baza podataka, datoteke ili vanjski API.

Poslužitelj stavlja na raspolaganje sve alate koje alat temeljen na umjetnoj inteligenciji može koristiti. S arhitekturnog gledišta, MCP poslužitelj tumači dolazni zahtjev i, kada je potrebno, povezuje se sa zatraženim primitivima.

MCP poslužitelji mogu omogućiti pristup trima kategorijama primitiva:

Alati: To su u biti funkcionalnosti vanjskog softvera. Ako uzmete u obzir tradicionalni pristup temeljen na API-jima, aplikacija za web-analitiku mogla bi dohvaćati podatke putem oblikovanog zahtjeva vanjskom poslužitelju. U MCP arhitekturi sva funkcionalnost trećih strana od jednog pružatelja dostupna je putem jedne veze, a zahtjevi se izrađuju prema standardnim pravilima oblikovanja.
Resursi: Resursi su izvori podataka koji pružaju kontekst samo za čitanje. Dobar su primjer sheme baza podataka. MCP poslužitelj stavlja hostu na raspolaganje različite dostupne izvore informacija. Ako host šalje upit bazi podataka, primjerice SQL pretraživanjem koje je generirao LLM, to se smatra zahtjevom za alat.
Promptovi: To su predlošci promptova za višekratnu upotrebu koji pomažu LLM-ovima u obavljanju određenih zadataka. Korisnik ili host pozvat će prompt umjesto alata jer su za dovršetak zadatka potrebne gotove upute. Unaprijed postavljeni zadaci u host aplikaciji, poput opcija „pregledaj kôd“ ili „analiziraj podatke“, često se pohranjuju kao promptovi koje korisnik može odabrati.

Valja napomenuti i da MCP i API nisu tehnologije koje se međusobno isključuju. MCP poslužitelj može staviti na raspolaganje API pozive koji su dostupni kao odgovor na zahtjev za otkrivanje. Ključno je da ih održava pružatelj MCP-a, a ne klijent.

Podatkovni sloj u MCP arhitekturi skup je pravila koja definiraju kako se oblikuju zahtjevi, odgovori i obavijesti. Standardni jezik za poruke je JSON-RPC.

Svaka MCP arhitektura slijedi osnovni postupak koji obuhvaća (1) inicijalizaciju i otkrivanje od strane hosta, (2) odgovor MCP poslužitelja i (3) poziv od strane hosta (o kojem ponekad odlučuje LLM), pri čemu svaka faza predstavlja zasebnu JSON poruku.

Dijagram MCP podatkovnog sloja: korisnik šalje prompt host aplikaciji, u kojoj LLM radi s MCP klijentom; klijent šalje zahtjev MCP poslužitelju (alati, resursi, promptovi) i prima rezultat, a host vraća odgovor korisniku.

Pogledajmo na dva primjera kako funkcionira otkrivanje alata (isto bi se moglo primijeniti na resurse ili promptove):

Otkrivanje alata prije generiranja odgovora LLM-a: Host pokreće MCP klijent, koji šalje zahtjev tools/list (popis dostupnih alata MCP poslužitelja). LLM ga pregledava tijekom procesa generiranja i utvrđuje je li potreban određeni alat, resurs ili prompt.
Davanje LLM-u mogućnosti pokretanja pretraživanja: U agentnom sustavu host dodaje opciju otkrivanja, kao što je search-tools, u ulazni kontekst, a LLM po potrebi može zatražiti pretraživanje.

Alate, koji su uglavnom funkcionalnosti vanjskih aplikacija, obično odabire LLM ili host. Resurse i promptove obično traži host, samostalno ili na zahtjev korisnika.

Evo kako izgleda zahtjev tools/list MCP poslužitelju iz zamišljene aplikacije za bilješke:

json

{
  "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 primjeru “id”:101 identificira zahtjev pomoću ID-a kako bi klijent mogao povezati odgovore, a polje “params” sadrži dodatne informacije o klijentu, kao što su naziv klijenta (notes-app-client) i mogućnosti.

Kao odgovor, MCP poslužitelj vratit će definicije alata, koje uključuju nazive dostupnih alata i povezane pojedinosti. Na primjer, popis bi mogao uključivati alat add-task koji aplikaciji za bilješke omogućuje stvaranje zadataka u povezanoj aplikaciji za upravljanje zadacima ili kalendaru, pri čemu se svakom zadatku dodjeljuju naslov i prioritet.

Evo kako bi mogao izgledati zahtjev:

json

{
  "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” govori MCP poslužitelju da je riječ o pozivu alata, “name” određuje koji alat treba pozvati, a “arguments” pruža potrebne ulazne podatke.

Ako podatkovni sloj određuje što se prenosi vezom između klijenta i MCP poslužitelja, transportni sloj određuje kako. On definira način na koji poruke putuju: određeni kanal i pravila koja uređuju kako se dostavljaju zahtjevi i odgovori.

MCP ima dva transportna puta:

Standardni ulaz/izlaz: Koristi se kada MCP poslužitelj radi u istom lokalnom okruženju kao i host aplikacija. Klijent zapisuje JSON zahtjev na standardni ulaz poslužitelja. Poslužitelj ga čita, izvodi zatraženu operaciju i zapisuje odgovor na standardni izlaz.
Streamable HTTP: Kada MCP poslužitelj radi izvan host aplikacije, MCP klijent šalje zahtjeve poslužitelju putem metode HTTP POST. Poslužitelj odgovara jednom JSON porukom ili tokom Server-Sent Events (SSE), trajnim kanalom za „slušanje“, što mu omogućuje da s vremenom vrati više poruka.

Višekorisnička (multi-tenant) MCP arhitektura vrsta je implementacije koja može istodobno posluživati više korisnika (tzv. zakupaca).

Zakupac ovdje može biti pojedinac, skupina pojedinaca ili organizacija. Implementacija može uključivati pokretanje zasebnog MCP poslužitelja za svakog zakupca, omogućavanje pristupa jednom zajedničkom poslužitelju ili smještanje skupa poslužitelja iza središnjeg pristupnika. Kada se koristi pristupnik, on usmjerava zahtjeve na odgovarajuće krajnje točke na temelju identiteta korisnika ili prirode zahtjeva.

Radi na istom osnovnom načelu kao standardna MCP arhitektura, ali se zahtjevi pojedinačnih korisnika izvršavaju u vlastitom radnom prostoru (čak i ako to podrazumijeva zajedničke resurse) i zasebno se autentificiraju. Uobičajena je u poslovnim okruženjima, a zajednički resursi često su poželjniji jer bi pokretanje više MCP poslužitelja bilo nepotrebno skupo.

Kako cjeloviti MCP zahtjev izgleda u praksi? Postoji osam ključnih faza, a svaka od njih uključuje zasebnu komponentu arhitekture.

Dijagram toka cjelovitog MCP zahtjeva u osam koraka: otkrivanje alata, korisnički unos, obrada u modelu, odabir alata, zahtjev, izvršavanje alata, rezultat i generiranje odgovora.

Evo kako MCP poziv alata izgleda u praksi, na prethodnom primjeru aplikacije za bilješke povezane s uslugom za upravljanje zadacima:

Otkrivanje alata: Aplikacija za bilješke (host) koristi svoj MCP klijent kako bi zahtjevom tools/list zatražila dostupne alate poslužitelja. Poslužitelj vraća njihove nazive, opise i očekivane ulazne podatke, uključujući one za alat add-task. To se može dogoditi i prije nego što pošaljete prompt.
Korisnički unos: Putem chatbota u aplikaciji šaljete zahtjev aplikaciji za bilješke temeljenoj na LLM-u, primjerice: „Izradi zadatak u mojem kalendaru za pregled mojeg novog nacrta sa srednjim prioritetom.“
Obrada u modelu: Host šalje vaš zahtjev i relevantne definicije alata LLM-u.
Odabir alata: LLM generira strukturirani zahtjev za alat u kojem navodi alat i njegove ulazne podatke: add-task s vrijednostima title: Pregled nacrta i priority: Srednji. Host provjerava je li radnja dopuštena i prosljeđuje zahtjev MCP klijentu, koji šalje JSON-RPC poruku.
Zahtjev: MCP klijent šalje zahtjev tools/call svojem MCP poslužitelju.
Izvršavanje alata: MCP poslužitelj poziva API aplikacije za upravljanje zadacima kako bi izradio novi zadatak s navedenim naslovom i prioritetom.
Vraćanje rezultata: Poslužitelj šalje rezultat natrag MCP klijentu, koji ga prosljeđuje hostu. Host ga dodaje informacijama koje se prosljeđuju LLM-u.
Generiranje odgovora: LLM koristi rezultat kako bi generirao odgovor za korisnika, primjerice: „Izradio sam zadatak za pregled nacrta sa srednjim prioritetom.“

MCP i tradicionalna API arhitektura često se brkaju, no riječ je o komplementarnim tehnologijama. MCP je osmišljen posebno za aplikacije temeljene na umjetnoj inteligenciji. Uklanja velik teret održavanja koji nose implementacija i upravljanje brojnim čvrsto kodiranim API vezama.

Pružajući host aplikaciji jednu vezu po pružatelju funkcionalnosti ili internom resursu, MCP pomaže riješiti problem preopterećenog ulaznog konteksta (navođenja svih API-ja) ili ograničenih skripti aplikacija temeljenih na API-jima.

Umjesto toga, MCP poslužitelji mogu staviti na raspolaganje API-je (odnosno funkcionalnost koja poziva API-je) kao dio svojeg popisa alata. Kad god pružatelj ažurira svoju aplikaciju i pojavi se novi API ili se promijeni dokumentacija, dovoljno je ažurirati MCP poslužitelj. Na strani host aplikacije nisu potrebne nikakve izmjene koda.

Sigurnost MCP-a tema je brojnih rasprava otkako je predstavljen. Iako se općenito smatra sigurnom tehnologijom, postoji nekoliko sigurnosnih rizika, od kojih su mnogi izraženiji u složenim implementacijama arhitekture.

MCP arhitektura ima sljedeće potencijalne slabosti:

Ubacivanje promptova (prompt injection): Korisnik umeće zlonamjerni prompt u vanjske podatke, a AI model ga pogrešno tumači kao uputu.
Pristup s prevelikim ovlastima: MCP poslužitelji potencijalno mogu AI modelu staviti na raspolaganje velik broj alata, što može povećati mogućnost sigurnosnih problema (tzv. radijus štete).
Slučajno curenje podataka: Loše konfigurirane implementacije mogu dovesti do toga da se osjetljive informacije, poput API ključeva ili vjerodajnica baze podataka, proslijede LLM-u.
Manipulacija lokalnim sustavom: Lokalni MCP poslužitelji jednako su ranjivi na probleme lokalnog sustava, poput zlonamjernih skripti, kao i sve druge aplikacije, uz dodatni problem da mogu imati štetne posljedice za agentne AI sustave dalje u lancu.

Nijedan od tih problema nije nepremostiv. Često su ustaljene mjere sve što je potrebno za osiguravanje sigurnosti sustava. Mjere poput uključivanja čovjeka u proces, provođenja strogih kontrola nad osjetljivim podacima i zaštite od napada na poslužitelje uobičajene su prakse.

MCP se pokazao korisnim i popularnim otvorenim standardom za razvojne programere. Rješava mnoge probleme čvrsto kodiranih API-ja u aplikacijama temeljenima na LLM-ovima i znatno smanjuje opterećenje programera kodiranjem.

Ubuduće će temeljna arhitektura hosta i poslužitelja u MCP-u gotovo sigurno ostati ista. Buduće inovacije usredotočit će se na napredne agentne mogućnosti u višekoračnim tijekovima rada.

Osim toga, s implementacijom tih agentnih funkcionalnosti bit će potrebne snažnije sigurnosne zaštite, a kako AI sustavi postaju opsežniji i složeniji, bit će potrebna i skalabilna arhitektura, osobito u transportnom sloju.

Što je MCP arhitektura?

Komponente MCP arhitekture: hostovi, klijenti i poslužitelji

Host

Klijent

Poslužitelj

Što je podatkovni sloj u MCP arhitekturi?

Što je transportni sloj u MCP arhitekturi?

Što je višekorisnička (multi-tenant) MCP arhitektura?

Dijagram MCP arhitekture: prikaz korak po korak

Po čemu se MCP arhitektura razlikuje od tradicionalne API arhitekture?

Je li MCP arhitektura sigurna?

Što slijedi za MCP arhitekturu?