MCP objašnjen: Šta povezuje, šta ne radi i gde se uklapa

Model Context Protocol (MCP) je otvoreni protokol za povezivanje AI aplikacija sa spoljnim mogućnostima i informacijama kroz standardizovane ugovore klijent-server. MCP server može da izloži alate, resurse i upite; MCP-kompatibilan host ili klijent otkriva i koristi te mogućnosti u ime AI aplikacije. MCP ne zahteva da server pokreće sopstveni jezički model i ne zamenjuje runtime agenta, poslovnu autorizaciju, izolaciju zakupaca, API-je aplikacije ili arhitekturu domena iza izloženih mogućnosti.

Šta MCP zaista standardizuje

Pre MCP-a, svaka AI aplikacija je mogla da integriše spoljne sisteme kroz sopstvenu šemu alata, format dodatka, konvenciju autentifikacije i kod za povezivanje. Isti servis je mogao da zahteva različite adaptere za desktop AI klijent, IDE agenta i prilagođenu aplikaciju.

MCP stvara granicu protokola koja se može ponovo koristiti. Spoljni sistem izlaže mogućnosti kroz MCP server, dok kompatibilni AI hostovi implementiraju MCP klijent. Ovo smanjuje spreganje integracije između AI aplikacije i osnovnog provajdera alata ili podataka.

Protokol ne standardizuje celu aplikaciju. On standardizuje kako se mogućnosti opisuju, otkrivaju i pozivaju preko te granice.

Najjednostavniji primer

Pretpostavimo da AI aplikacija za kodiranje treba pristup lokalnom direktorijumu projekta. Bez MCP-a, aplikacija bi mogla direktno da implementira sopstvenu integraciju sa fajl sistemom.

Sa MCP-om, server za fajl sistem može da izloži mogućnosti kao što su prikaz direktorijuma, čitanje odobrenih fajlova ili pisanje unutar dozvoljenog radnog prostora. AI host se povezuje preko MCP klijenta i predstavlja te mogućnosti modelu ili runtime-u agenta.

Server ne mora da razume korisnikov zahtev na prirodnom jeziku. Host/model odlučuje koja je mogućnost korisna; MCP server izvršava strukturisani zahtev pod sopstvenim bezbednosnim pravilima.

Gde se jednostavan primer zaustavlja

MCP ne definiše kako host bira alat, kako agent planira, kako se modeluje poslovni radni tok ili kako domenski objekat kao što je faktura ili implementacija treba da se ponaša.

Protokol može da učini integraciju interoperabilnom dok osnovna aplikacija ostaje netačna, nesigurna ili loše dizajnirana. Savršeno validan MCP zahtev i dalje može da pozove pogrešnu poslovnu mogućnost.

Centralna granica je: MCP standardizuje semantiku integracije, a ne istinitost aplikacije ili poslovnu ispravnost.

MCP arhitektura: host, klijent i server

Host može da se poveže sa više MCP servera, a jedan MCP server može da stoji ispred jednog ili više osnovnih sistema. Host ostaje odgovoran za integraciju MCP rezultata u širu AI aplikaciju.

Server može biti lokalan u odnosu na host, pokrenut kao odvojen proces ili udaljen preko mrežnog transporta. Topologija hostovanja i lokacija modela su nezavisne odluke.

Tri osnovna serverska primitiva

Alati: pozive mogućnosti

Alati su strukturisane operacije koje MCP server stavlja na raspolaganje hostu. Alat ima naziv, opis i ulaznu šemu; moderne implementacije mogu da obezbede i strukturisani izlaz.

Primeri uključuju pretragu repozitorijuma, čitanje zapisa o klijentu, kreiranje tiketa, pokretanje build-a ili slanje poruke. Alati mogu biti samo za čitanje ili imati sporedne efekte.

Dobra površina MCP alata treba da predstavlja koherentne ciljeve korisnika ili agenta, a ne da mehanički preslikava svaki interni API endpoint. Operacije sa različitim dozvolama, zahtevima za potvrdu ili obimom uticaja obično treba da budu odvojeni alati.

Resursi: čitljiv kontekst i podaci

Resursi izlažu podatke ili sadržaj koje klijent može da navede ili pročita. Prirodno odgovaraju kada je semantička operacija „daj mi ovaj artefakt ili informaciju“, a ne „izvrši ovu radnju“.

URI resursa nije odobrenje za pristup. Server i dalje poseduje kontrolu pristupa i mora da proveri koji principal sme da čita osnovni objekat.

Revizija protokola od 2026-07-28 dodaje semantiku keširanja za odgovore na listanje i čitanje resursa, uključujući svežinu i obim keša, čineći ponašanje keširanja eksplicitnijim.

Upiti: šabloni za višekratnu upotrebu

MCP upiti omogućavaju serveru da objavi šablone upita za višekratnu upotrebu kompatibilnim klijentima. To može da zadrži instrukcije specifične za domen blizu pružaoca mogućnosti.

Upit koji dostavlja MCP server ne nadjačava automatski sistemske ili bezbednosne instrukcije hosta. Host odlučuje kako materijal upita ulazi u njegovu hijerarhiju konteksta.

Sadržaj upita koji obezbeđuje protokol stoga treba tretirati kao podatke o mogućnostima sa eksplicitnom semantikom poverenja, a ne kao neograničeni autoritet instrukcija.

Alat ili resurs?

Gde se nalazi AI model?

MCP ne zahteva da model radi na MCP serveru. Model može biti hostovan u oblaku, lokalno hostovan, ugrađen u desktop aplikaciju ili dostupan preko drugog provajdera.

Host obično poseduje interakciju sa modelom. MCP server izlaže eksterne mogućnosti. Lokalni MCP server stoga može koristiti host čiji model radi u oblaku, a udaljeni MCP server može koristiti host čiji model radi lokalno.

Ako MCP server sam interno poziva LLM, taj model je deo implementacije servera iza granice protokola; MCP ga ne zahteva.

MCP ne zamenjuje API-je

MCP server često obavija postojeće API-je ili servise. REST, GraphQL, SQL, SDK pozivi i interni ugovori servisa mogu ostati tačno tamo gde jesu.

MCP dodaje sloj interoperabilnosti okrenut AI-ju. Osnovni domenski API može ostati autoritativni ugovor aplikacije za obične determinističke klijente.

Uobičajena arhitektura je stoga API/servis na prvom mestu, odabrana AI-orijentisana mogućnost na drugom — a ne „zameniti svaki API MCP-om“.

MCP naspram pozivanja funkcija

OpenAI trenutno izlaže udaljene MCP servere kao jedan tip alata uporedo sa običnim pozivanjem funkcija, web pretragom, shell-om i drugim alatima. Ta implementacija ilustruje arhitektonski odnos: MCP povezivost i sopstveni interfejs modela za pozivanje alata mogu se komponovati.

MCP ne stvara petlju agenta

AI agentu je potreban runtime koji može da odlučuje, poziva alate, posmatra rezultate, ažurira stanje i nastavlja ili zaustavlja. MCP može da obezbedi neke od alata i podataka koje ta petlja koristi.

MCP server automatski ne postaje planer, sistem memorije ili orkestrator. Te odgovornosti obično ostaju u hostu ili runtime-u agenta.

Neagentna aplikacija takođe može da koristi MCP. Jedan deterministički MCP poziv alata ne zahteva autonomnog agenta sa više koraka.

MCP naspram A2A

MCP prvenstveno povezuje AI host ili agenta sa mogućnostima kao što su alati, resursi i podaci. A2A je usmeren na saradnju između nezavisnih agentskih sistema.

Udaljeni agent može interno da koristi MCP za pristup bazama podataka i alatima, dok istovremeno izlaže A2A interfejs drugim agentima. Protokoli se stoga mogu slojevito kombinovati, a ne zamenjivati.

Postojeći članak o protokolskom steku pokriva šire poređenje MCP/A2A/UCP/AP2/A2UI; G02 ostaje kanonska definicija MCP-a.

Lokalna i udaljena MCP upotreba imaju različite transportne realnosti

MCP može da se poveže sa lokalnim i udaljenim serverima. Lokalne desktop integracije obično koriste transporte na nivou procesa kao što je stdio; udaljeni serveri koriste HTTP-orijentisani transport.

Revizija od 2026-07-28 čini jezgro protokola bezstanjem. Zahtevi nose informacije potrebne za rukovanje protokolom umesto da zavise od ranijeg modela sesije na nivou protokola.

Trenutna revizija takođe postavlja nazive metoda i mogućnosti u HTTP zaglavlja kako bi gateway-i, WAF-ovi, ograničivači brzine i balanseri opterećenja mogli prirodnije da usmeravaju i mere MCP saobraćaj.

Zašto je poznavanje MCP verzije važno

Verzija SDK-a i verzija protokola su takođe različite stvari. Trenutni TypeScript v2 SDK je stabilna linija za reviziju 2026-07-28, dok stariji v1.x ostaje linija za održavanje za ponašanje iz 2025. godine.

Arhitektonska dokumentacija treba da zabeleži i verziju SDK-a/biblioteke i reviziju protokola tamo gde ponašanje interoperabilnosti zavisi od njih.

Šta se promenilo u MCP 2026-07-28

Roots, sampling i logging više nisu pravac za nove implementacije

Izdanje 2026-07-28 označava roots, sampling i logging kao zastarele mogućnosti protokola sa definisanim periodom kompatibilnosti.

Stariji tutorijali možda još uvek prikazuju ove funkcije kao centralne primitive. Novi rad na implementaciji treba da prati trenutnu specifikaciju, a ne da slepo kopira starije dijagrame životnog ciklusa.

Ukidanje ne znači trenutno uklanjanje. Znači da novi sistemi treba da izbegavaju nepotrebne nove zavisnosti od mogućnosti od kojih se protokol udaljava.

Dugotrajni rad nije isto što i obično pozivanje MCP alata

Dugotrajne operacije zahtevaju semantiku životnog ciklusa koja prevazilazi jednostavan trenutni rezultat alata. U trenutnom ekosistemu, Zadaci su premešteni u namensko MCP proširenje.

Ovo pojačava koristan princip dizajna: osnovni protokol ne mora da apsorbuje svaku brigu o izvršavanju agenta.

Aplikacija takođe može u potpunosti da zadrži vlasništvo nad dugotrajnim radnim tokom u svom sopstvenom izvršnom okruženju i da koristi obične MCP alate kao osnovne operacije.

MCP aplikacije proširuju UI mogućnosti bez redefinisanja osnovnog protokola

MCP aplikacije povezuju bogatija interaktivna UI iskustva sa MCP alatima kroz model proširenja.

Domaćin i dalje kontroliše kako se taj UI ugrađuje, izoluje i obezbeđuje.

Razmena osnovnih mogućnosti i renderovanje UI stoga treba da ostanu odvojene arhitektonske odgovornosti.

MCP autorizacija nije vaš kompletan model autorizacije

Udaljeni MCP zahteva mehanizme autentifikacije i autorizacije na nivou protokola kako bi klijenti i serveri mogli da uspostave pouzdan pristup. Trenutna specifikacija nastavlja da ojačava ponašanje povezano sa OAuth/OIDC.

Taj sloj odgovara na pitanje da li je klijentu dozvoljeno da se poveže ili zatraži opsege protokola. On automatski ne odgovara na pitanje da li Alice može da refundira porudžbinu 123, da li agent može da upiše produkcionu konfiguraciju ili da li Zakupac A može da čita podatke Zakupca B.

Te domenske odluke pripadaju modelu autorizacije servera/aplikacije i moraju se sprovesti pre pozivanja osnovne operacije.

Identitet može preći nekoliko granica

MCP zahtev može uključivati MCP klijentsku aplikaciju, prijavljenog čoveka, identitet agenta/sesije i nalog usluge nizvodno.

Serveru je potrebna eksplicitna politika o tome u ime kog principala se operacija izvršava. U suprotnom, moćna akreditacija usluge može postati put zloupotrebe poverenja.

Za poslovnu upotrebu, korelacija između identiteta korisnika, identiteta agenta, MCP veze i nizvodne autorizacije jednako je važna kao i kompatibilnost protokola.

Izolacija zakupaca ostaje izvan MCP otkrivanja mogućnosti

MCP server sa više zakupaca mora primeniti opseg zakupca kada čita ili menja resurse koji pripadaju zakupcu. Vraćanje alata pod nazivom search_documents ne definiše koji su dokumenti zakupca podobni.

Opseg zakupca treba izvesti iz pouzdanog identiteta ili članstva i preneti ga u baze podataka, keševe, vektorsku pretragu, skladište objekata i nizvodne API-je.

Dohvatanje sadržaja između zakupaca i traženje od modela da ga ne koristi već je neuspeh izolacije.

MCP ne definiše izvor istine

MCP server može izložiti bazu podataka, repozitorijum dokumenata, servis za web pretragu ili AI-generisani rezime. Protokol ne deklariše koji je izvor merodavan za tvrdnju.

Pravila izvora istine pripadaju arhitekturi aplikacije/domena. Domaćin ili server mogu kodirati autoritet kroz dizajn alata, metapodatke, politiku pristupa ili validaciju, ali sam MCP ne čini jednu mogućnost „istinitom“.

Alat stoga može biti savršeno pozivljiv putem MCP-a i ipak vraćati zastarele, sekundarne ili neautoritativne informacije.

MCP i inženjering konteksta

MCP može povećati mogućnosti i informacije dostupne AI aplikaciji, ali inženjering konteksta i dalje određuje šta stiže do modela.

Katalozi alata troše kontekst vidljiv modelu u mnogim domaćinima. Rezultati alata mogu biti veliki. Resursi mogu biti brojni. Domaćin treba selekciju, filtriranje, dinamičko učitavanje i sažimanje umesto izlaganja svega u svakom koraku.

Dostupnost mogućnosti i kontekst vidljiv modelu stoga treba tretirati kao odvojene slojeve.

Dizajnirajte MCP alate oko ishoda i granica rizika

Odobrenja pripadaju arhitekturi izvršavanja

Domaćin može zahtevati odobrenje korisnika pre pozivanja izabranih MCP alata. OpenAI-jeva trenutna MCP integracija podržava automatske ili obrasce izvršavanja sa eksplicitnim odobrenjem.

Odobrenje domaćina je korisno, ali ne bi trebalo da bude jedina zaštita servera jer drugi kompatibilni MCP klijent može koristiti drugačiji model odobravanja.

Za destruktivne ili finansijski značajne radnje, koristite odbranu u dubinu: jasan ugovor o alatima, odobrenje u vreme izvršavanja gde je prikladno, autorizaciju na strani servera, poslovnu validaciju i reviziju.

MCP observabilnost treba da poveže protokolske pozive sa domen­skim radnjama

MCP trag je najkorisniji kada može da se poveže sa osnovnim pozivom aplikacije, promenom u bazi podataka ili poslovnom transakcijom.

Ekosistem od 2026-07-28 standardizuje konvencije propagacije W3C Trace Context, što olakšava praćenje zahteva kroz host, klijenta, server i nizvodne servise.

Sami protokolski logovi nisu dovoljni za značajne operacije. Revizijski dokazi takođe treba da zabeleže relevantnog principala, tenanta, ciljni resurs, odobrenje i rezultujuću promenu stanja.

Šta MCP ne može da popravi

Dokazi originalne implementacije: Aaasaasa AI Client

Aplikacija može da pokrene autentifikovanu Streamable HTTP MCP krajnju tačku na loopback-u. Krajnja tačka izlaže samo direktorijume izabrane kroz centralni broker dozvola radnog prostora.

Lokalna krajnja tačka i udaljena ruta su odvojene stvari: lokalni konektor može da se veže samo na loopback, dok Secure MCP Tunnel može da učini odobreni MCP servis dostupnim dozvoljenom eksternom AI klijentu bez izlaganja cele lokalne mašine.

Centralni model dozvola razlikuje profile samo za ćaskanje, samo za čitanje, za pisanje u projekat i prilagođene direktorijume. Direct Chat nema pristup fajl sistemu ili shell-u; agent runtime-i sa mogućnošću alata koriste izabrani profil dozvola.

Ovo je direktna implementacija G02 granice: MCP obezbeđuje standardizovanu vezu mogućnosti, dok broker dozvola u vlasništvu aplikacije odlučuje koje direktorijume server može da izloži.

Kada je MCP dobro rešenje

Kada vam MCP nije potreban

Ne dodajte MCP samo zato što aplikacija koristi AI. Ako vaš backend već poziva jedan interni API i nijedan nezavisni MCP klijent ne zahteva tu mogućnost, običan poziv funkcije ili servisa može biti jasniji.

MCP dodaje vrednost na granici interoperabilnosti. Bez te granice, protokol može postati nepotreban sloj adaptera.

Arhitektonsko pitanje nije „Da li ovaj projekat ima AI?“ već „Da li nezavisno evoluirajući AI hostovi i pružaoci mogućnosti imaju koristi od standardnog ugovora?“

MCP bezbednosna kontrolna lista

Uobičajene zablude

Praktičan redosled MCP dizajna

MCP arhitektonska kontrolna lista

Rubni slučajevi i ograničenja

Lokalni stdio MCP server može imati malu mrežnu izloženost, a ipak biti opasan ako sam proces ima prekomerne dozvole za fajl sistem ili shell.

Udaljeni MCP server može izlagati samo javnu dokumentaciju ili visoko osetljive poslovne radnje. „Udaljeni MCP“ malo govori o riziku bez konteksta mogućnosti i autorizacije.

Neki serveri mogu koristiti samo alate i ignorisati resurse/promptove. MCP kompatibilnost ne zahteva da svaki opcioni primitiv bude jednako važan.

Host može prevoditi između svog internog modela alata i MCP-a. Korisnici možda nikada neće direktno videti granicu protokola, što je prihvatljivo ako bezbednost i pripisivanje ostanu jasni.

MCP nastavlja brzo da se razvija. Ekstenzije, obrasci autorizacije, SDK API-ji i konvencije ekosistema mogu se menjati brže od osnovne arhitektonske razlike.

Šta bi promenilo ovaj odgovor?

Buduće revizije MCP-a mogu promeniti životni ciklus, transporte, autorizaciju i mehanizme ekstenzija. Revizija iz jula 2026. već pokazuje zašto tvrdnje specifične za implementaciju moraju biti datirane.

Kanonska granica bi se promenila samo ako bi se MCP proširio sa interoperabilnog protokola na standard za end-to-end arhitekturu aplikacija/agenata. To nije ono što trenutni protokol definiše.

Za implementacioni rad uvek proverite trenutnu specifikaciju i tačnu liniju SDK-a umesto kopiranja primera osetljivih na verziju iz starijih tutorijala.

Povezano kanonsko znanje

MCP pripada nizvodno od Agentic AI: prvo razumite granicu agent/runtime/alat, zatim koristite MCP kada eksterne sposobnosti zahtevaju prenosivi protokolarni ugovor.

MCP takođe zavisi od RBAC-a i izolacije zakupaca jer izlaganje sposobnosti na nivou protokola ne određuje autorizaciju aplikacije.

Širi članak o protokolarnom steku objašnjava gde se MCP nalazi pored A2A, UCP, AP2 i A2UI. G02 ostaje kanonski izvor za sam MCP.

Često postavljana pitanja

Pojmovnik

Zaključak

MCP je najlakše razumeti kada njegova granica ostane uska: povezuje AI aplikacije sa eksternim sposobnostima kroz standardni protokol.

Model ne mora da živi na MCP serveru. Server ne postaje agent runtime. Navedeni alat ne postaje autorizovana poslovna akcija. I MCP ne zamenjuje osnovni API, izvor istine, izolaciju zakupaca ili domensku arhitekturu.

Ta uskost je snaga protokola. MCP može standardizovati način na koji AI sistemi dosežu alate i podatke, dok vlasništvo nad aplikacijom, bezbednost, poslovnu semantiku i izbor modela ostavlja u slojevima koji ih zaista poseduju.

Primarni izvori i trenutna dokumentacija

MCP se brzo razvija, pa su tvrdnje osetljive na verziju u ovom članku vezane za stanje od 8. oktobra 2026. Odsek Aaasaasa AI Client je originalni implementacioni dokaz i eksplicitno je ograničen na verifikovani MCP konektor i opseg posrednika dozvola.