MCP архитектура: потпуна техничка анализа са дијаграмима

MCP архитектура је основни скуп компоненти и правила комуникације који омогућавају MCP (Model Context Protocol). MCP је стандард отвореног кода, а MCP архитектура је инфраструктура на којој он почива.

Свака MCP архитектура садржи три основне компоненте и изграђена је око њих: хост, клијент и сервер. Комуникациони оквир MCP-а често се описује као састављен од слоја података и транспортног слоја. Слој података је скуп правила о томе како се поруке форматирају (MCP захтјеви се шаљу у формату JSON-RPC 2.0). Транспортни слој преноси те поруке, користећи Streaming HTTP за спољне везе.

MCP архитектура је серверски оквир који имплементира Model Context Protocol, отворени стандард за повезивање AI модела са алатима, ресурсима као што су базе података и промптовима који проширују улазни контекст. Они се заједнички називају „примитиви“. На крају, MCP архитектура омогућава LLM-овима да открију који су алати доступни и извршавају токове рада, и то без потребе за редовним ажурирањима на страни клијента.

Дијаграм MCP архитектуре: AI апликација размјењује захтјеве са MCP сервером, који пружа алате, ресурсе и промптове.

Откако ју је представио Anthropic, MCP архитектура се широко користи у AI токовима рада. То је углавном зато што замјењује системе који захтијевају више одржавања, као што су они изграђени око више API веза, без губитка перформанси. Пошто се сва доступна функционалност налази иза MCP сервера, потребна је само једна веза, а ажурирања и нове могућности одмах су доступни клијентској апликацији.

MCP пружа LLM-овима начин да открију и позову алате, промптове и ресурсе који су им доступни, било на локалном систему хост апликације или од спољног провајдера.

Када је ријеч о алатима, који омогућавају приступ спољним функционалностима, откривање подразумијева да хост упути tools/list позив MCP серверу како би сазнао који су алати доступни. LLM (или у неким случајевима хост) затим може прочитати описе доступних алата и затражити их по потреби. Промптови и ресурси користе сличан процес.

Дијаграм компоненти MCP архитектуре: хост који садржи LLM, оркестратор и клијент повезује се са MCP сервером у два корака, прво откривањем, а затим захтјевима, а MCP сервер ставља на располагање алате, ресурсе и промптове.

То је у супротности са прилагођеном архитектуром заснованом на API-јима, која је била норма у развоју софтвера, гдје је функционалност ван апликације морала да се позива преко намјенских веза са прецизно форматираним захтјевима.

Хост апликација је централна платформа за оркестрацију и повезује се са LLM-ом. Познати алати као што су Perplexity и Claude Desktop могу да функционишу као хостови у оквиру MCP система.

У једноставном току рада корисник поставља питање преко интерфејса за ћаскање. Компонента оркестратора у хосту затим додаје контекст питању, саопштавајући LLM-у који су MCP примитиви доступни, заједно са описом њихових могућности.

Клијент је софтверска компонента у AI апликацији. MCP пружа стандардни интерфејс преко ког клијент комуницира са интерним и спољним MCP серверима на основу упутстава хоста или LLM-а. Његов задатак је да успостави везу, форматира JSON-RPC поруке, шаље захтјеве и прима одговоре.

Термини „MCP хост“ и „MCP клијент“ понекад се користе као синоними. Ипак, ово разликовање је корисно јер хост, као што је Perplexity, може истовремено да оркестрира више MCP клијената. Сложен AI ток рада може захтијевати приступ десетинама или чак стотинама засебних MCP сервера, а сваки од њих ће користити засебну везу.

Дијаграм MCP хоста, као што је Perplexity, који оркестрира три MCP клијента, од којих је сваки повезан са сопственим MCP сервером, као што је база података, датотеке или спољни API.

Сервер ставља на располагање све алате које алат заснован на AI-ју може да користи. Из архитектонске перспективе, MCP сервер тумачи долазни захтјев и, по потреби, повезује се са траженим примитивима.

MCP сервери могу да пруже приступ трима категоријама примитива:

Алати: Ово су у суштини спољне софтверске функционалности. Ако узмете у обзир традиционални приступ заснован на API-јима, апликација за веб аналитику може преузимати податке помоћу форматираног захтјева упућеног спољном серверу. У MCP архитектури сва функционалност трећих страна од једног провајдера доступна је преко једне везе, а захтјеви се креирају према стандардним правилима форматирања.
Ресурси: Ресурси су извори података који пружају контекст само за читање. Шеме база података су добар примјер. MCP сервер ставља на располагање различите изворе информација који су доступни хосту. Ако хост шаље упит бази података, на примјер помоћу SQL претраге коју је генерисао LLM, то се сматра захтјевом за алат.
Промптови: Ово су шаблони промптова за вишекратну употребу који помажу LLM-овима да изврше одређене задатке. Корисник или хост позваће промпт умјесто алата јер су за извршење задатка потребна готова упутства. Унапријед подешени задаци у хост апликацији, као што су опције „преглед кода“ или „анализа података“, често се чувају као промптови које корисник може да изабере.

Такође вриједи напоменути да MCP и API нису међусобно искључиве технологије. MCP сервер може да стави на располагање API позиве који су доступни као одговор на захтјев за откривање. Кључно је то што је одржавање тих позива одговорност MCP провајдера, а не клијента.

Слој података у MCP архитектури је скуп правила која дефинишу како се форматирају захтјеви, одговори и обавјештења. Стандардни језик за поруке је JSON-RPC.

Свака MCP архитектура прати основни процес који чине (1) иницијализација и откривање од стране хоста, (2) одговор MCP сервера и (3) позив од стране хоста (о ком понекад одлучује LLM), при чему свака фаза представља засебну JSON поруку.

Дијаграм слоја података MCP-а: корисник шаље промпт хост апликацији, у којој LLM ради са MCP клијентом; клијент шаље захтјев MCP серверу (алати, ресурси, промптови) и прима резултат, а хост враћа одговор кориснику.

Погледајмо на два примјера како функционише откривање алата (ово се може примијенити и на ресурсе или промптове):

Откривање алата прије него што LLM почне генерисање: Хост покреће MCP клијент, који шаље tools/list захтјев (листу доступних алата MCP сервера). LLM то прегледа током процеса генерисања и одређује да ли је потребан одређени алат, ресурс или промпт.
Омогућавање LLM-у да покрене претрагу: У агентском систему хост додаје опцију откривања, као што је search-tools, у улазни контекст, а LLM по потреби може да затражи претрагу.

Алате, који су углавном функционалности спољних апликација, обично бира LLM или хост. Ресурсе и промптове обично захтијева корисник или их тражи хост.

Ево како изгледа tools/list захтјев MCP серверу из једне замишљене апликације за биљешке:

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": {}
    }
  }
}

У овом примјеру “id”:101 идентификује захтјев помоћу ID-ја како би клијент могао да упари одговоре, а поље “params” садржи додатне информације о клијенту, као што су назив клијента (notes-app-client) и могућности.

Као одговор, MCP сервер ће вратити дефиниције алата, које укључују називе доступних алата и њихове пратеће детаље. На примјер, листа може садржати алат add-task који апликацији за биљешке омогућава да креира задатке у повезаној апликацији за управљање задацима или календару, додјељујући сваком задатку наслов и приоритет.

Ево како би захтјев могао да изгледа:

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": {}
    }
  }
}

Поље “method” говори MCP серверу да је ријеч о позиву алата, “name” наводи који алат треба позвати, а “arguments” пружа потребне улазне податке.

Ако је слој података оно шта у вези између клијента и MCP сервера, транспортни слој је оно како. Он дефинише начин на који поруке путују: конкретан канал и правила која одређују како се захтјеви и одговори испоручују.

MCP има два транспортна пута:

Стандардни улаз/излаз: Користи се када MCP сервер ради у истом локалном окружењу као хост апликација. Клијент уписује JSON захтјев на стандардни улаз сервера. Сервер га чита, извршава тражену операцију и уписује одговор на стандардни излаз.
Streamable HTTP: Када MCP сервер ради ван хост апликације, MCP клијент шаље захтјеве серверу помоћу метода HTTP POST. Сервер одговара или једном JSON поруком или стримом Server-Sent Events (SSE), трајним каналом за „слушање“, што му омогућава да током времена враћа више порука.

MCP архитектура са више закупаца је тип имплементације која може истовремено да опслужује више корисника (закупаца).

Овдје закупац може бити појединац, група појединаца или организација. Имплементација може подразумијевати покретање засебног MCP сервера за сваког закупца, обезбјеђивање приступа једном заједничком серверу или постављање скупа сервера иза централног гејтвеја. Када се користи гејтвеј, он усмјерава захтјеве ка одговарајућим крајњим тачкама на основу идентитета корисника или природе захтјева.

Она функционише по истом основном принципу као стандардна MCP архитектура, али појединачни кориснички захтјеви раде у сопственом радном простору (чак и ако то подразумијева заједничке ресурсе) и засебно се аутентификују. Уобичајена је у пословним сценаријима, а заједнички ресурси се често преферирају јер би покретање више MCP сервера било непотребно скупо.

Како у пракси изгледа MCP захтјев од почетка до краја? Постоји осам кључних фаза, од којих свака укључује засебну компоненту архитектуре.

Дијаграм тока MCP захтјева од почетка до краја у осам корака: откривање алата, кориснички унос, обрада у моделу, избор алата, захтјев, извршавање алата, резултат и генерисање одговора.

Ево како у пракси изгледа позив MCP алата, на претходном примјеру апликације за биљешке повезане са сервисом за управљање задацима:

Откривање алата: Апликација за биљешке (хост) користи свој MCP клијент да затражи доступне алате сервера путем tools/list захтјева. Сервер враћа њихове називе, описе и очекиване улазне податке, укључујући и оне за алат add-task. Ово се може догодити прије него што пошаљете промпт.
Кориснички унос: Шаљете захтјев апликацији за биљешке заснованој на LLM-у преко четбота у апликацији, на примјер: „Креирај задатак у мом календару да прегледам нови нацрт, са средњим приоритетом.“
Обрада у моделу: Хост шаље ваш захтјев и релевантне дефиниције алата LLM-у.
Избор алата: LLM генерише структурисани захтјев за алат, наводећи алат и његове улазне податке: add-task са title: Review the draft и priority: Medium. Хост провјерава да ли је радња дозвољена и прослеђује захтјев MCP клијенту, који шаље JSON-RPC поруку.
Захтјев: MCP клијент шаље tools/call захтјев свом MCP серверу.
Извршавање алата: MCP сервер позива API апликације за управљање задацима како би креирао нови задатак са наведеним насловом и приоритетом.
Враћање резултата: Сервер шаље резултат назад MCP клијенту, који га прослеђује хосту. Хост га додаје информацијама које се достављају LLM-у.
Генерисање одговора: LLM користи резултат да генерише одговор за корисника, на примјер: „Креирао сам задатак да прегледате нацрт, са средњим приоритетом.“

MCP и традиционална API архитектура често се мијешају, али су то комплементарне технологије. MCP је посебно осмишљен за апликације засноване на AI-ју. Он превазилази велико оптерећење одржавања које подразумијевају имплементација и управљање већим бројем чврсто кодираних API веза.

Пружајући хост апликацији једну везу по провајдеру функционалности или интерном ресурсу, MCP помаже да се ријеши проблем преоптерећеног улазног контекста (навођење свих API-ја) или ограничених скрипти апликација заснованих на API-јима.

Умјесто тога, MCP-ови могу да ставе на располагање API-је (односно функционалност која позива API-је) као дио своје листе алата. Кад год провајдер ажурира своју апликацију и појави се нови API, или ако се документација промијени, довољно је да ажурира MCP сервер. На страни хост апликације нису потребне никакве измјене кода.

Безбједност MCP-а је од његовог увођења тема бројних расправа. Иако се генерално сматра безбједном технологијом, постоји неколико безбједносних ризика, од којих су многи израженији у сложеним имплементацијама архитектуре.

MCP архитектура има сљедеће потенцијалне слабости:

Убацивање промпта: Корисник убацује злонамјерни промпт у спољне податке, који AI модел погрешно тумачи као упутство.
Приступ са прекомјерним привилегијама: MCP сервери потенцијално могу ставити на располагање велики број алата AI моделу, што може повећати могућност безбједносних проблема (радијус штете).
Случајно цурење података: Лоше конфигурисане имплементације могу довести до тога да осјетљиве информације, као што су API кључеви или акредитиви за базу података, буду прослијеђене LLM-у.
Манипулација локалним системом: Локални MCP сервери подједнако су рањиви на проблеме локалног система, као што су злонамјерне скрипте, као и било које друге апликације, уз додатни проблем да могу имати штетне посљедице на агентске AI системе даље у ланцу.

Ниједан од ових проблема није непремостив. Често су устаљене мјере све што је потребно да би се обезбиједила безбједност система. Мјере као што су укључивање човјека у процес, спровођење строгих контрола над осјетљивим подацима и заштита од напада на сервере уобичајене су праксе.

MCP се показао као користан и популаран отворени стандард за програмере. Он превазилази многе проблеме чврсто кодираних API-ја у апликацијама заснованим на LLM-у и знатно смањује обим кодирања за програмере.

Убудуће ће основна архитектура хоста и сервера у MCP-у готово сигурно остати иста. Будуће иновације биће усмјерене на напредне агентске способности у токовима рада са више корака.

Поред тога, биће потребне јаче безбједносне заштите како се те агентске функционалности буду имплементирале, као и скалабилна архитектура, нарочито у транспортном слоју, како AI системи буду постајали обимнији и сложенији.

Шта је MCP архитектура?

Компоненте MCP архитектуре: хостови, клијенти и сервери

Хост

Клијент

Сервер

Шта је слој података у MCP архитектури?

Шта је транспортни слој у MCP архитектури?

Шта је MCP архитектура са више закупаца?

Дијаграм MCP архитектуре: објашњење корак по корак

По чему се MCP архитектура разликује од традиционалне API архитектуре?

Да ли је MCP архитектура безбједна?

Шта је сљедеће за MCP архитектуру?