Kaj je strežnik MCP? Kako delujeta MCP in MCP UI v letu 2026

Dne 1. aprila 2025 je Invariant Labs objavil orodje z imenom add. Sprejelo je dve števili in vrnilo njuno vsoto. Njegov opis pa je vseboval še blok z oznako IMPORTANT, v vmesniku odjemalca neviden, ki je modelu naročil, naj prebere ~/.cursor/mcp.json in ~/.ssh/id_rsa ter obe datoteki pošlje ven prek odvečnega parametra. Model je ubogal. Uporabnik je videl seštevanje.

Ta demonstracija je najkoristnejši uvod v strežnike MCP, kar jih poznam, ker naenkrat pokaže obe polovici. Protokol je deloval natanko tako, kot je bil zasnovan: odjemalec AI je odkril orodje, prebral njegov opis in ga poklical. Model zaupanja je bil del, ki ga še nihče ni zgradil.

Kaj je strežnik MCP

Strežnik MCP je program, ki aplikacijam AI prek protokola Model Context Protocol (MCP) ponudi orodja, podatke in pozive. Uradna dokumentacija MCP opredeli kot „odprtokodni standard za povezovanje aplikacij AI z zunanjimi sistemi“. Odjemalec AI, na primer Claude, ChatGPT, Visual Studio Code ali Cursor, se poveže s strežnikom, vpraša, kaj ponuja, in te zmožnosti kliče v imenu uporabnika.

Anthropic je MCP napovedal 25. novembra 2024 s šestimi vnaprej pripravljenimi strežniki: Google Drive, Slack, GitHub, Git, Postgres in Puppeteer. OpenAI ga je sprejel marca 2025. Google DeepMind je sledil aprila. Decembra 2025 je Anthropic protokol podaril fundaciji Agentic AI Foundation, usmerjenemu skladu pod okriljem Linux Foundation, ki so ga soustanovili Anthropic, Block in OpenAI.

Težava je množenje povezav. Pred MCP je vsaka aplikacija AI za GitHub napisala svoj povezovalnik, vsak ponudnik pa povezavo za vsako aplikacijo AI. Deset modelov in deset orodij je lahko pomenilo sto integracij. MCP to zmanjša na dvajset: vsak odjemalec enkrat uvede protokol, vsak sistem pa izpostavi en strežnik.

Predstavljajte si ga kot ladijski zabojnik integracij AI. Pred zabojniki je vsako pristanišče vsak tovor nakladalo ročno, z lastnimi žerjavi in lastno posadko. Zabojnik je standardiziral škatlo, zato je lahko katera koli ladja, žerjav ali tovornjak prevažal kateri koli tovor. Ni pa standardiziral tega, kar je v škatli, in vsebine ni nikoli pregledal. MCP je enaka kupčija. Zapomnite si drugo polovico, vrne se v poglavju o varnosti.

Kako deluje strežnik MCP

Trenutna specifikacija, različica 2026-07-28, uporablja sporočila JSON-RPC 2.0 med tremi vlogami. Njen lastni opis je dolg tri vrstice: gostitelji so „aplikacije LLM, ki vzpostavljajo povezave“, odjemalci so „priključki znotraj gostiteljske aplikacije“, strežniki pa so „storitve, ki zagotavljajo kontekst in zmožnosti“.

Gostitelj, odjemalec, strežnik

Gostitelj je aplikacija, v katero tipkate: Claude Desktop, razvojno okolje IDE, vaš lastni agent. Znotraj nje teče po en odjemalec za vsako povezavo s strežnikom. Strežnik je na drugi strani in se pogovarja z resničnim sistemom, pa naj bo to podatkovna zbirka Postgres, GitHub API ali mapa na vašem disku. Gostitelj odloča, kaj model vidi in kaj mora uporabnik odobriti. Strežnik odloča, kaj bo naredil sistem v ozadju.

1. Gostitelj Claude Desktop · IDE · vaš lastni agent

   modelu pokaže orodja, uporabnika vpraša za privolitev

2. Odjemalec en na vsako povezavo s strežnikom

   govori JSON-RPC prek stdio ali Streamable HTTP

3. Strežnik MCP orodja · viri · pozivi

   opiše, kaj ponuja, in izvaja klice

4. Sistem v ozadju podatkovna zbirka · SaaS API · lokalne datoteke

   opravi delo

Orodja, viri in pozivi

Strežnik lahko ponuja tri vrste stvari:

• Orodja (tools) so funkcije, ki jih model lahko izvede: create_issue, query_orders, send_email. Vsako ima ime, opis in JSON Schema za svoje vhode.
• Viri (resources) so kontekst in podatki, ki jih bere uporabnik ali model: datoteka, shema podatkovne zbirke, zapis.
• Pozivi (prompts) so predloge sporočil in potekov dela, ki jih izbere uporabnik, na primer „povzemi ta pull request“.

Orodja dobijo največ pozornosti, ker delujejo. Prav zato nosijo tudi največ tveganja.

Klic orodja, korak za korakom

Revizija 2026-07-28 je MCP naredila brez stanja. Rokovanja initialize ni več. Vsaka zahteva v polju _meta nosi različico protokola in zmožnosti odjemalca, strežniki pa morajo implementirati metodo server/discover, da lahko odjemalec vnaprej vpraša, kaj podpirajo. En sam klic orodja zdaj poteka takole:

1. Uporabnik prosi: ustvari zahtevek za to napako

2. Korak 1

   Odkrivanje

   • Odjemalec lahko pokliče server/discover za različice in zmožnosti
3. Korak 2

   Seznam orodij

   • tools/list vrne imena, opise in sheme vhodov
4. Korak 3

   Model izbere orodje

   • Gostitelj modelu preda definicije orodij
5. Korak 4

   Privolitev uporabnika

   • Specifikacija pravi, da mora gostitelj pred klicem katerega koli orodja dobiti izrecno privolitev
6. Korak 5

   Klic

   • tools/call z argumenti, različica protokola v _meta

7. Manjka vhod? Strežnik vrne input_required, odjemalec poskusi znova z odgovori

   Korak 6

   Rezultat

8. Rezultat se vrne modelu kot kontekst

Korak 6 je v tej reviziji nov. Strežnik, ki potrebuje več informacij, odjemalcu ne pošlje več lastne zahteve. Vrne rezultat z oznako input_required, odjemalec zbere odgovor in prvotni klic ponovi. Specifikacija temu pravi vzorec Multi Round-Trip Request.

Transporti: stdio in Streamable HTTP

Specifikacija opredeli dva standardna transporta:

• stdio: odjemalec zažene strežnik kot podproces in si z njim prek standardnega vhoda in izhoda izmenjuje JSON-RPC, ločen z novimi vrsticami. Tako teče večina lokalnih strežnikov, kar pomeni, da strežnik teče na vašem računalniku z vašimi pravicami.
• Streamable HTTP: vsako sporočilo je HTTP POST na eno samo končno točko, odgovori pa pridejo kot objekt JSON ali kot tok dogodkov, vezan na zahtevo. Tako tečejo oddaljeni, gostovani strežniki.

Starejši transport HTTP+SSE je uradno opuščen. Revizija 2026-07-28 je odstranila tudi seje na ravni protokola in glavo Mcp-Session-Id. Strežnik, ki potrebuje stanje med klici, zdaj sam ustvari svoj identifikator in ga dobi nazaj kot navaden argument orodja.

Avtorizacija

Avtorizacija je v MCP izbirna in velja samo za HTTP. Pri stdio specifikacija pravi, naj strežniki poverilnice raje vzamejo iz okolja. Pri HTTP zaščiteni strežnik MCP deluje kot strežnik virov po OAuth 2.1. Objaviti mora OAuth Protected Resource Metadata (RFC 9728), da odjemalci najdejo njegov avtorizacijski strežnik. Odjemalci morajo navesti točno tisti strežnik, za katerega je žeton namenjen (indikatorji virov po RFC 8707). Strežniki morajo zavrniti vsak žeton, ki ni bil izdan zanje, varnostna navodila pa „token passthrough“, torej nespremenjeno posredovanje odjemalčevega žetona naprej v drug API, izrecno prepovedujejo.

To zadnje pravilo je pomembnejše, kot se zdi. Strežnik, ki posreduje kateri koli žeton, ki ga prejme, postane posrednik za vsakogar, ki ima žeton.

Kaj doda MCP UI: strežniki, ki vrnejo vmesnik

Besedilni odgovori nehajo delovati v trenutku, ko mora uporabnik primerjati štirideset vrstic, popraviti obrazec z dvanajstimi polji ali odobriti paket sprememb eno za drugo. „MCP UI“ je ime, pod katerim ljudje iščejo rešitev: strežnik vrne interaktivni vmesnik, ki se izriše znotraj odjemalca AI, poleg pogovora.

Stanje je treba opisati natančno. Zamisel se je začela kot skupnostni projekt MCP-UI. OpenAI je podoben mehanizem zgradil v Apps SDK. Projekt MCP je 21. novembra 2025 z obema predlagal skupni standard, 26. januarja 2026 pa objavil MCP Apps kot prvo uradno razširitev MCP. Paketi MCP-UI zdaj izvajajo ta standard in ostajajo prostor za preizkušanje izboljšav.

MCP UI torej danes pomeni MCP Apps. Je uraden in je razširitev, ne jedro protokola. Razširitve so izbirne: podpirati jih morata odjemalec in strežnik, dokumentacija pa naravnost pove, da se „podpora gostiteljev razlikuje od odjemalca do odjemalca“. Dokumentacija MCP Apps kot podprte gostitelje navaja Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam in Archestra.AI. Strežnik, katerega orodja vračajo vmesnik, mora še vedno delovati tudi za odjemalca, ki prikazuje samo besedilo.

Mehansko uporabi gradnike, ki jih MCP že ima:

1. Opis orodja vsebuje _meta.ui.resourceUri, ki kaže na vir ui://.
2. Gostitelj pridobi ta vir, stran HTML z njenimi skriptami, in jo lahko naloži že pred klicem orodja.
3. Gostitelj jo izriše v izoliranem iframe, ki ne more brati nadrejene strani, njenih piškotkov ali shrambe.
4. Aplikacija in gostitelj se pogovarjata prek postMessage v narečju MCP, ki temelji na JSON-RPC. Aplikacija lahko zahteva klice orodij, gostitelj pa odloči, katere dovoli.

Cena je resnična. Zdaj dostavljate spletni vmesnik znotraj tuje aplikacije, s pravilnikom content security policy, ki ga morate deklarirati, s pravili izrisa, ki jih ne nadzorujete, in z besedilno alternativo za vsakega gostitelja, ki vmesnik prezre. Dobiček je v tem, da odobritve niso več prepis klepeta. Seznam primernih primerov v dokumentaciji se konča z „odobravanjem potnih stroškov, pregledovanjem sprememb kode ali razvrščanjem težav“, kar je pošteno jedro stvari: MCP UI je najboljši za odločitve, ne za okras.

Primer Tajo samo za branje

Tajo površina Alto MCP vključuje query_contacts, ki išče stike, shranjene v povezanem prostoru. Poiščite obstoječ stik po e-pošti in preverite ID, stanje privolitve za e-pošto ter čas zadnjega opažanja. Ločeno orodje get_contact_topic_status bere naročnine po temah.

To so branja iz prostora. Ne pridobijo svežega posnetka pri ponudniku, ne zaženejo sinhronizacije in ne pošljejo sporočila. Prav tako ne dokazujejo, da vsi povezovalniki delujejo. Manjkajoče ali stare podatke raziščite pri viru. Prazen rezultat ne dokazuje, da osebe ni v Brevu.

V dokumentaciji Tajo MCP povežite podprtega odjemalca in si oglejte orodja, ki jih vaš pooblaščeni prostor dejansko izpostavi. Interaktivna plošča lahko olajša pregled, če gostitelj podpira MCP Apps. Besedilni rezultat mora še vedno pojasniti izid.

Klic orodja ni trajna sinhronizacija

Ponavljajoča sinhronizacija zahteva tudi urnik, stabilno identiteto zapisov, shranjen napredek, odločitve o ponovitvah in evidenco zaključenih zapisov. Za to je odgovorna izvajalska aplikacija. MCP standardizira dostop do orodij; seznam jih ne spremeni v poslovna pravila.

Po časovni omejitvi lahko branje običajno ponovimo. Pošiljanje ali plačilo se je morda že zgodilo. Shranite zapis izvajanja in preverite izid pred novo ponovitvijo. Zaupanje modela ne daje dovoljenja in ponovitve ne naredi varne.

Vodnik za API Brevo opiše ciljno pisanje za konkreten stik. Vodnik reverse ETL pomaga presoditi, kdaj izračunana polja potrebujejo lastno vzdrževano sinhronizacijo.

Varnostni račun pride skupaj s protokolom

Ugovor si zasluži, da ga navedemo v celoti: „MCP verjetnostnemu modelu izroči seznam funkcij, ki lahko brišejo podatke in pošiljajo e-pošto, nato pa zaupa besedilu neznancev, ki jih opisuje. To ni integracijski standard. To je napad na dobavno verigo s specifikacijo.“ Večina tega drži. Specifikacija se s premiso strinja. Njeno varnostno poglavje pravi, da orodja „predstavljajo poljubno izvajanje kode in z njimi je treba ravnati z ustrezno previdnostjo“, da je treba opise orodij „šteti za nezaupanja vredne, razen če izvirajo iz zaupanja vrednega strežnika“, in da MCP „teh varnostnih načel ne more uveljaviti na ravni protokola“.

Tole je dosedanja bilanca:

• Tool poisoning (zastrupitev orodij). Razkritje Invariant Labs iz aprila 2025, zgoraj omenjeno orodje add. Ista objava je opisala tako imenovani rug pull, ko strežnik spremeni opis orodja potem, ko ste ga odobrili, in shadowing (senčenje), ko en zlonamerni strežnik prepiše vedenje modela do zaupanja vrednega strežnika.
• Kompromitiran lokalni strežnik. Julija 2025 je JFrog razkril CVE-2025-6514 v mcp-remote v različicah od 0.0.5 do 0.1.15, ki je zlonamernemu strežniku omogočila izvajanje ukazov na uporabnikovem računalniku. Istega poletja je CVE-2025-49596 prizadela Anthropicov lastni MCP Inspector, ki je bil privzeto dobavljen brez avtentikacije.
• Napihovanje obsegov. Uradne najboljše varnostne prakse vzorec poimenujejo: žetoni z files:* ali admin:*, dodeljeni že na začetku, ker je strežnik navedel vse obsege in jih je odjemalec zahteval vse.
• Uradna zaskrbljenost. Maja 2026 je ameriška Nacionalna varnostna agencija (NSA) zapisala, da je „hitro širjenje MCP prehitelo razvoj njegovega varnostnega modela“.

Kjer se ugovor zmoti, je sklep. Rešitev ni bila nikoli v tem, da modelov ne bi več povezovali s sistemi. Ekipe so to že počele s surovimi ključi API, prilepljenimi v pozive in skripte, povsem brez revizijske sledi. Rešitev je, da s strežnikom MCP ravnate kot s katero koli drugo privilegirano odvisnostjo:

• Strežnike nameščajte samo iz virov, ki bi jim enake poverilnice zaupali tudi zunaj MCP.
• Oddaljene strežnike z OAuth in ozkimi obsegi imejte raje kot lokalne binarne datoteke z dolgoživimi ključi.
• Za vsak zapis zahtevajte človeško odobritev in beležite, kdo je kaj odobril.
• Zaklenite različice strežnikov in jih ponovno preglejte, ko se opis orodja spremeni.
• Ponudite orodja, prirejena nalogam, ne celotnega API-ja. Model ne more zlorabiti končne točke za brisanje, ki ni bila nikoli ponujena.

Protokol je standardiziral škatlo. Pregled tovora je še vedno vaša naloga.

Zgraditi strežnik MCP ali uporabiti obstoječega

Javni imeniki, kot je mcp.so, katalogizirajo strežnike skupnosti, mnogi ponudniki SaaS pa objavljajo svoje. Brevo na primer ponuja strežnik MCP, ki je razdeljen tudi na posamezne strežnike, tako da agent lahko dobi stike brez kampanj. Odločitev je manj stvar truda in bolj vprašanje, kdo naj določa obliko orodij.

Kateri strežnik MCP naj uporablja vaš agent?

1. Ponudnik objavi strežnik, ki pokrije nalogo

   Uporabite ponudnikov strežnik

   Sledi API-ju in ga vzdržuje ponudnik.

2. En sistem, vendar potrebujete manj ali varnejših dejanj

   Uporabite ga z zoženim obsegom

   Dodelite najmanjše obsege in ponudite samo skupine orodij, ki jih agent potrebuje.

3. Notranji podatki ali sistem brez strežnika

   Zgradite majhen strežnik

   Nekaj orodij, prirejenih nalogam, nad vašim lastnim API-jem, z vašo lastno avtentikacijo.

4. Naloga zajema dva ali več sistemov

   Zgradite ali prevzemite upravljano plast

   En nabor orodij, pravil privolitve in revizijske zgodovine za vse sisteme.

Zgraditi osnovni strežnik je lažji del. Z uradnim SDK je delujoč strežnik stdio z enim orodjem delo za eno popoldne. Stroški pridejo pozneje: OAuth za različico HTTP, opustitve (revizija 2026-07-28 je opustila Roots, Sampling in Logging ter Dynamic Client Registration) in stalno delo pisanja opisov orodij, ki jih model pravilno prebere. Ovijanje API-ja po načelu ena končna točka, eno orodje je najpogostejša napaka. Vsak opis orodja je besedilo, ki ga mora model prebrati in pretehtati, zato kratek seznam orodij, prirejenih nalogam, premaga celotno površino API-ja.

MCP, API-ji, integracije in iPaaS

MCP ne nadomešča API-jev. Skoraj vsak strežnik MCP je ovoj okoli enega. Delo se še vedno opravi v API-ju, z njegovimi omejitvami hitrosti, podatkovnim modelom in posebnostmi. MCP spremeni, kdo ga lahko kliče: model, med izvajanjem, ki klic izbere na podlagi opisa, namesto razvijalca, ki ga vnaprej trdo zakodira.

Ta razlika jasno loči MCP od drugih dveh stvari, s katerima ga ljudje zamenjujejo:

• Integracije in iPaaS (glavne platforme so primerjane tukaj) premikajo podatke po urniku ali ob sprožilcu, deterministično, ne glede na to, ali je kdo v klepetu. Nočna sinhronizacija 40.000 naročil v CRM ne bi smela biti odvisna od tega, ali se model odloči za 40.000 klicev orodij.
• Obratni ETL potiska modelirane podatke iz podatkovnega skladišča nazaj v operativna orodja. Kaj je obratni ETL in kdaj je primeren je tema zase, in gre za cevovod, ne za pogovor.
• MCP je za trenutke, ko mora človek ali agent v teh sistemih nekaj vprašati, pregledati ali narediti, na zahtevo.

Napaka gre v obe smeri. Nekatere ekipe gradijo strežnike MCP za množično sinhronizacijo in dobijo počasne, drage in neponovljive cevovode. Druge ekipe zgradijo skrbne integracije, nato pa svojemu asistentu AI dajo surov ključ API, da jih poizveduje, in dobijo nenadzorovana stranska vrata.

Pri podprti integraciji naj trajno opravilo in orodja za pregled delijo jasno mejo dovoljenj. Za konkretni potek preverite povezovalnik, dovoljene ukrepe in zabeležene izide. Dokumentacija integracij loči navodila za nastavitev od poti, ki še potrebujejo dokaz v produkciji. MCP lahko izpostavi ločena odobrena orodja; njihov seznam ne dokazuje ponavljajoče sinhronizacije ali vseh aktivnih kontrol.

V 22 mesecih je MCP prešel od šestih referenčnih strežnikov do projekta Linux Foundation, ki ga govorijo Claude, ChatGPT, VS Code in Cursor. Povezati model s sistemom je zdaj poceni del. Pravo delo je odločiti, kaj tam sme početi.