MCP архитектурасы: диаграммалармен толық техникалық талдау
MCP архитектурасының техникалық талдауы: хосттар, клиенттер және серверлер, JSON-RPC деректер деңгейі, тасымалдау нұсқалары, көп тенантты конфигурациялар, қауіпсіздік тәуекелдері және диаграммалары бар сегіз қадамдық сұрау шолуы.

MCP архитектурасы — MCP (Model Context Protocol) жұмысын мүмкін ететін негізгі компоненттер мен байланыс ережелерінің жиынтығы. MCP — ашық бастапқы кодты стандарт, ал MCP архитектурасы — ол жұмыс істейтін базалық инфрақұрылым.
Кез келген MCP архитектурасы үш негізгі компоненттен тұрады және солардың төңірегінде құрылады: хост, клиент және сервер. MCP-дің байланыс құрылымы көбінесе деректер деңгейі мен тасымалдау деңгейінен тұрады деп сипатталады. Деректер деңгейі — хабарламалардың қалай пішімделетінін анықтайтын ережелер жиынтығы (MCP сұраулары JSON-RPC 2.0 форматында жіберіледі). Тасымалдау деңгейі осы хабарламаларды жеткізеді және сыртқы қосылымдар үшін Streaming HTTP пайдаланады.
MCP архитектурасы дегеніміз не?
MCP архитектурасы — Model Context Protocol хаттамасын іске асыратын серверлік құрылым. Бұл хаттама — ЖИ модельдерін құралдарға, дерекқорлар сияқты ресурстарға және кіріс контекстін кеңейтетін промпттарға қосуға арналған ашық стандарт. Бұлардың барлығы жалпы «примитивтер» деп аталады. Түптеп келгенде, MCP архитектурасы LLM-дерге қандай құралдар қолжетімді екенін анықтауға және клиент жағында тұрақты жаңартуларды қажет етпей-ақ жұмыс процестерін орындауға мүмкіндік береді.
Anthropic ұсынғаннан бері MCP архитектурасы ЖИ жұмыс процестерінде кеңінен қолданылып келеді. Бұған негізгі себеп — ол өнімділікке нұқсан келтірмей, бірнеше API қосылымына негізделген жүйелер сияқты қызмет көрсетуді көп қажет ететін жүйелерді алмастырады. Барлық қолжетімді функционалдылық MCP серверінің артында орналасқандықтан, тек бір қосылым қажет болады, ал жаңартулар мен толықтырулар клиент қосымшасына бірден қолжетімді болады.
MCP архитектурасының компоненттері: хосттар, клиенттер және серверлер
MCP LLM-дерге хост қосымшасының жергілікті жүйесінде немесе сыртқы провайдерде қолжетімді құралдарды, промпттарды және ресурстарды табуға және шақыруға мүмкіндік береді.
Сыртқы функционалдылыққа қол жеткізуді қамтамасыз ететін құралдар жағдайында анықтау барысында хост қандай құралдар қолжетімді екенін білу үшін MCP серверіне tools/list шақыруын жібереді. Содан кейін LLM (немесе кейбір жағдайларда хост) қолжетімді құралдардың сипаттамаларын оқып, оларды қажетіне қарай сұрай алады. Промпттар мен ресурстар да осыған ұқсас процесті пайдаланады.
Бұл бағдарламалық жасақтама әзірлеуде қалыпты тәжірибе болып келген арнайы API-ге негізделген архитектурадан түбегейлі ерекшеленеді: онда қосымшадан тыс функционалдылықты арнайы қосылымдар арқылы, дәл пішімделген сұраулармен шақыру қажет болатын.
Хост
Хост қосымшасы — орталық оркестрлеу платформасы, ол LLM-ге қосылады. Perplexity және Claude Desktop сияқты белгілі құралдар MCP жүйесінде хост рөлін атқара алады.
Қарапайым жұмыс процесінде пайдаланушы чат интерфейсі арқылы сұрақ қояды. Содан кейін хосттың оркестратор компоненті сұраққа контекст қосып, LLM-ге қандай MCP примитивтері қолжетімді екенін және олардың мүмкіндіктерінің сипаттамасын хабарлайды.
Клиент
Клиент — ЖИ қосымшасындағы бағдарламалық компонент. MCP клиентке хосттың немесе LLM-нің нұсқауларына сәйкес ішкі және сыртқы MCP серверлерімен байланысуға арналған стандартты интерфейс ұсынады. Оның міндеті — қосылым орнату, JSON-RPC хабарламаларын пішімдеу, сұраулар жіберу және жауаптар алу.
«MCP хосты» және «MCP клиенті» терминдері кейде бір-бірінің орнына қолданылады. Дегенмен бұл ажырату пайдалы, себебі Perplexity сияқты хост бір уақытта бірнеше MCP клиентін оркестрлей алады. Күрделі ЖИ жұмыс процесі ондаған, тіпті жүздеген жеке MCP серверіне қол жеткізуді қажет етуі мүмкін және олардың әрқайсысы жеке қосылымды пайдаланады.
Сервер
Сервер ЖИ негізіндегі құрал пайдалана алатын барлық құралдарды ұсынады. Архитектуралық тұрғыдан MCP сервері кіріс сұрауды түсіндіреді және қажет болғанда сұралған примитивтерге қосылады.
MCP серверлері примитивтердің үш санатына қол жеткізуді қамтамасыз ете алады:
- Құралдар: Бұл негізінен сыртқы бағдарламалық функциялар. Дәстүрлі API-ге негізделген тәсілді алсақ, веб-аналитика қосымшасы деректерді сыртқы серверге пішімделген сұрау жіберу арқылы алуы мүмкін. MCP архитектурасында провайдердің барлық үшінші тарап функционалдылығы бір қосылым арқылы қолжетімді, ал сұраулар стандартты пішімдеу ережелеріне сай құрылады.
- Ресурстар: Ресурстар — тек оқуға арналған контекст беретін дерек көздері. Дерекқор схемалары — жақсы мысал. MCP сервері хостқа қолжетімді әртүрлі ақпарат көздерін ұсынады. Егер хост дерекқорға сұрау жасаса, мысалы, LLM құрастырған SQL іздеуі арқылы, бұл құрал сұрауы болып саналады.
- Промпттар: Бұл LLM-дерге нақты тапсырмаларды орындауға көмектесетін қайта пайдаланылатын промпт үлгілері. Пайдаланушы немесе хост құралдың орнына промптты шақырады, себебі тапсырманы орындау үшін дайын нұсқаулар қажет. Көбінесе хост қосымшасындағы «кодты тексеру» немесе «деректерді талдау» сияқты алдын ала орнатылған тапсырмалар пайдаланушы таңдай алатын промпттар ретінде сақталады.
Сондай-ақ MCP мен API бірін-бірі жоққа шығаратын технологиялар емес екенін атап өткен жөн. MCP сервері анықтау сұрауына жауап ретінде қолжетімді API шақыруларын ұсына алады. Ең бастысы — оларға клиент емес, MCP провайдері қызмет көрсетеді.
MCP архитектурасындағы деректер деңгейі дегеніміз не?
MCP архитектурасындағы деректер деңгейі — сұраулардың, жауаптардың және хабарландырулардың қалай пішімделетінін анықтайтын ережелер жиынтығы. Хабарламалардың стандартты тілі — JSON-RPC.
Кез келген MCP архитектурасы мынадай негізгі процеске сүйенеді: (1) хост тарапынан инициализация және анықтау, (2) MCP серверінің жауабы және (3) хост тарапынан шақыру (кейде оны LLM шешеді); әр кезең жеке JSON хабарламасы болып табылады.
Құралдарды анықтаудың қалай жұмыс істейтінін екі мысал арқылы қарастырайық (бұлар ресурстарға немесе промпттарға да қатысты болуы мүмкін):
- LLM генерациясына дейін құралдарды анықтау: Хост MCP клиентін іске қосады, ал клиент tools/list сұрауын (MCP серверіндегі қолжетімді құралдар тізімі) жібереді. LLM генерация барысында осы тізімді қарап, белгілі бір құрал, ресурс немесе промпт қажет пе екенін анықтайды.
- LLM-ге іздеу жүргізу мүмкіндігін беру: Агенттік жүйеде хост контекст кірісіне search-tools сияқты анықтау опциясын қосады, ал LLM қажет болса іздеуді сұрай алады.
Негізінен сыртқы қосымшалардың функциялары болып табылатын құралдарды әдетте LLM немесе хост таңдайды. Ресурстар мен промпттар көбінесе пайдаланушының қалауымен немесе хост тарапынан сұралады.
Ойдан шығарылған жазбалар қосымшасынан MCP серверіне жіберілетін tools/list сұрауы былай көрінеді:
{
"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 құралы болуы мүмкін: ол жазбалар қосымшасына қосылған тапсырмаларды басқару немесе күнтізбе қосымшасында тапсырмалар жасап, әр тапсырмаға атау мен басымдық тағайындауға мүмкіндік береді.
Сұрау мына түрде болуы мүмкін:
{
"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-де екі тасымалдау жолы бар:
- Стандартты кіріс/шығыс: Бұл MCP сервері хост қосымшасымен бірдей жергілікті ортада жұмыс істегенде қолданылады. Клиент JSON сұрауын сервердің стандартты кірісіне жазады. Сервер оны оқып, сұралған әрекетті орындайды және жауапты стандартты шығысқа жазады.
- Streamable HTTP: MCP сервері хост қосымшасынан тыс жұмыс істегенде, MCP клиенті серверге сұрауларды HTTP POST арқылы жібереді. Сервер бір JSON хабарламасымен немесе Server-Sent Events (SSE) ағынымен жауап береді. Бұл ағын — тұрақты «тыңдау» арнасы, ол уақыт өте келе бірнеше хабарлама қайтаруға мүмкіндік береді.
MCP көп тенантты архитектурасы дегеніміз не?
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 клиенті өзінің MCP серверіне tools/call сұрауын жібереді.
- Құралды орындау: MCP сервері көрсетілген атауы мен басымдығы бар жаңа тапсырма жасау үшін тапсырмаларды басқару қосымшасының API-ін шақырады.
- Нәтижені қайтару: Сервер нәтижені MCP клиентіне қайтарады, ал клиент оны хостқа береді. Хост оны LLM-ге берілетін ақпаратқа қосады.
- Жауап генерациясы: LLM нәтижені пайдаланып, пайдаланушыға жауап құрастырады, мысалы: «Жобаны қарап шығу үшін орташа басымдықпен тапсырма жасадым».
MCP архитектурасы дәстүрлі API архитектурасынан немен ерекшеленеді?
MCP мен дәстүрлі API архитектурасын жиі шатастырады, бірақ олар бірін-бірі толықтыратын технологиялар. MCP арнайы ЖИ негізіндегі қосымшаларға арналып жасалған. Ол қатаң кодталған бірнеше API қосылымын енгізу мен басқарудың ауыр қызмет көрсету жүктемесін жеңуге көмектеседі.
Хост қосымшасына әр функционалдылық провайдеріне немесе ішкі ресурсқа бір қосылым беру арқылы MCP шамадан тыс ұлғайған контекст кірісі (барлық API-лерді тізімдеу) немесе API-ге негізделген шектеулі қосымша скрипттері мәселесін шешуге көмектеседі.
Оның орнына MCP серверлері API-лерді (дәлірек айтқанда, API-лерді шақыратын функционалдылықты) өз құралдар тізімінің бөлігі ретінде ұсына алады. Провайдер қосымшасын жаңартып, жаңа API пайда болған сайын немесе құжаттама өзгерген кезде, ол тек MCP серверін жаңартады. Хост қосымшасы тарапынан кодты өзгерту қажет емес.
MCP архитектурасы қауіпсіз бе?
MCP қауіпсіздігі пайда болғаннан бері көп талқыланып келеді. Ол жалпы қауіпсіз технология болып саналғанымен, бірнеше қауіпсіздік тәуекелі бар және олардың көбі күрделі архитектуралық іске асыруларда айқынырақ байқалады.
MCP архитектурасының ықтимал әлсіз тұстары:
- Промпт инъекциясы: Пайдаланушы сыртқы деректерге зиянды промпт енгізеді, ал ЖИ моделі оны қате түсініп, нұсқау ретінде қабылдайды.
- Шамадан тыс артықшылықты қол жеткізу: MCP серверлері ЖИ моделіне көптеген құралдарды ашуы мүмкін, бұл қауіпсіздік мәселелерінің ықтималдығын (зақымдану радиусын) арттыруы мүмкін.
- Деректердің кездейсоқ ағуы: Нашар конфигурацияланған іске асырулар API кілттері немесе дерекқордың тіркелгі деректері сияқты құпия ақпараттың LLM-ге берілуіне әкелуі мүмкін.
- Жергілікті жүйені манипуляциялау: Жергілікті MCP серверлері кез келген басқа қосымша сияқты зиянды скрипттер секілді жергілікті жүйе мәселелеріне осал, оның үстіне олар агенттік ЖИ жүйелеріне кейінгі кезеңдерде зиянды әсер етуі мүмкін.
Бұл мәселелердің ешқайсысы шешілмейтін емес. Көбінесе жүйе қауіпсіздігін қамтамасыз ету үшін қалыптасқан шаралар жеткілікті. Процеске адамды қатыстыру, құпия деректерге қатаң бақылау орнату және серверлік шабуылдардан қорғау сияқты шаралар — кең таралған тәжірибе.
MCP архитектурасының болашағы қандай?
MCP әзірлеушілер үшін пайдалы әрі танымал ашық стандарт екенін дәлелдеді. Ол LLM негізіндегі қосымшалардағы қатаң кодталған API-лердің көптеген мәселелерін шешеді және әзірлеушілердің код жазу жүктемесін айтарлықтай азайтады.
Алдағы уақытта MCP-дің негізгі хост және сервер архитектурасы өзгеріссіз қалатыны дерлік анық. Болашақ инновациялар көп қадамды жұмыс процестеріндегі кеңейтілген агенттік мүмкіндіктерге бағытталады.
Сонымен қатар агенттік функционалдылықтар енгізілген сайын қауіпсіздіктің күштірек кепілдіктері, ал ЖИ жүйелері кеңейіп, күрделене түскен сайын, әсіресе тасымалдау деңгейінде, масштабталатын архитектура қажет болады.