MCP arhitektūra: pilns tehniskais pārskats ar diagrammām

MCP arhitektūra ir pamata komponentu un saziņas noteikumu kopums, kas padara iespējamu MCP (Model Context Protocol). MCP ir atvērtā pirmkoda standarts, un MCP arhitektūra ir pamatā esošā infrastruktūra, uz kuras tas darbojas.

Jebkura MCP arhitektūra ietver trīs galvenos komponentus un ir veidota ap tiem: saimniekprogrammu, klientu un serveri. MCP saziņas sistēmu bieži raksturo kā tādu, kas sastāv no datu slāņa un transporta slāņa. Datu slānis ir noteikumu kopums, kas nosaka, kā tiek formatēti ziņojumi (MCP pieprasījumi tiek sūtīti JSON-RPC 2.0 formātā). Transporta slānis pārnes šos ziņojumus, ārējiem savienojumiem izmantojot Streaming HTTP.

MCP arhitektūra ir servera ietvars, kas īsteno Model Context Protocol — atvērtu standartu MI modeļu savienošanai ar rīkiem, resursiem, piemēram, datubāzēm, un uzvednēm, kas paplašina ievades kontekstu. Tos kopā sauc par „primitīviem”. Galu galā MCP arhitektūra ļauj LLM noskaidrot, kuri rīki ir pieejami, un izpildīt darbplūsmas — turklāt bez nepieciešamības regulāri veikt atjauninājumus klienta pusē.

MCP arhitektūras diagramma: MI lietotne apmainās ar pieprasījumiem ar MCP serveri, kas nodrošina rīkus, resursus un uzvednes.

Kopš Anthropic to ieviesa, MCP arhitektūra ir kļuvusi plaši izmantota MI darbplūsmās. Tas galvenokārt skaidrojams ar to, ka tā aizstāj sistēmas, kuru uzturēšana prasa vairāk pūļu, piemēram, tādas, kas veidotas ap vairākiem API savienojumiem, un tas nenotiek uz veiktspējas rēķina. Tā kā visa pieejamā funkcionalitāte atrodas aiz MCP servera, nepieciešams tikai viens savienojums, un atjauninājumi un papildinājumi klienta lietotnei ir pieejami nekavējoties.

MCP nodrošina LLM iespēju atklāt un izsaukt rīkus, uzvednes un resursus, kas tiem pieejami vai nu saimniekprogrammas lokālajā sistēmā, vai no ārēja pakalpojumu sniedzēja.

Rīku gadījumā, kas nodrošina piekļuvi ārējai funkcionalitātei, atklāšana nozīmē, ka saimniekprogramma veic tools/list izsaukumu uz MCP serveri, lai noskaidrotu, kuri rīki ir pieejami. Pēc tam LLM (vai dažos gadījumos saimniekprogramma) var izlasīt pieejamo rīku aprakstus un pēc vajadzības tos pieprasīt. Uzvednēm un resursiem tiek izmantots līdzīgs process.

MCP arhitektūras komponentu diagramma: saimniekprogramma, kurā ir LLM, orķestrētājs un klients, savienojas ar MCP serveri divos soļos — vispirms atklāšana, pēc tam pieprasījumi —, un MCP serveris nodrošina piekļuvi rīkiem, resursiem un uzvednēm.

Tas ir pretstatā pielāgotai, uz API balstītai arhitektūrai, kas līdz šim bijusi norma programmatūras izstrādē un kurā ārpus lietotnes esošā funkcionalitāte bija jāizsauc, izmantojot īpašus savienojumus ar precīzi formatētiem pieprasījumiem.

Saimniekprogramma ir centrālā orķestrēšanas platforma, kas savienojas ar LLM. Labi zināmi rīki, piemēram, Perplexity un Claude Desktop, MCP sistēmā var darboties kā saimniekprogrammas.

Vienkāršā darbplūsmā lietotājs uzdod jautājumu, izmantojot tērzēšanas saskarni. Pēc tam saimniekprogrammas orķestrētāja komponents papildina jautājumu ar kontekstu, norādot LLM, kuri MCP primitīvi ir pieejami, un sniedzot to iespēju aprakstu.

Klients ir MI lietotnes programmatūras komponents. MCP nodrošina standarta saskarni, ar kuras palīdzību klients sazinās ar iekšējiem un ārējiem MCP serveriem atbilstoši saimniekprogrammas vai LLM norādījumiem. Tā uzdevums ir izveidot savienojumu, formatēt JSON-RPC ziņojumus, sūtīt pieprasījumus un saņemt atbildes.

Termini „MCP saimniekprogramma” un „MCP klients” dažkārt tiek lietoti kā sinonīmi. Tomēr šī nošķiršana ir noderīga, jo saimniekprogramma, piemēram, Perplexity, var vienlaikus orķestrēt vairākus MCP klientus. Sarežģītai MI darbplūsmai var būt nepieciešama piekļuve desmitiem vai pat simtiem atsevišķu MCP serveru, un katrs no tiem izmantos atsevišķu savienojumu.

Diagramma, kurā MCP saimniekprogramma, piemēram, Perplexity, orķestrē trīs MCP klientus, no kuriem katrs ir savienots ar savu MCP serveri, piemēram, datubāzi, failiem vai ārēju API.

Serveris nodrošina piekļuvi visiem rīkiem, ko var izmantot uz MI balstītais rīks. No arhitektūras viedokļa MCP serveris interpretē ienākošo pieprasījumu un vajadzības gadījumā savienojas ar pieprasītajiem primitīviem.

MCP serveri var nodrošināt piekļuvi trīs primitīvu kategorijām:

Rīki: Būtībā tās ir ārējas programmatūras funkcijas. Ja aplūko tradicionālu, uz API balstītu pieeju, tīmekļa analītikas lietotne varētu iegūt datus, nosūtot formatētu pieprasījumu uz ārēju serveri. MCP arhitektūrā visa pakalpojumu sniedzēja trešās puses funkcionalitāte ir pieejama, izmantojot vienu savienojumu, un pieprasījumi tiek veidoti atbilstoši standarta formatēšanas noteikumiem.
Resursi: Resursi ir datu avoti, kas nodrošina kontekstu tikai lasīšanai. Labs piemērs ir datubāzu shēmas. MCP serveris dara saimniekprogrammai pieejamus dažādos informācijas avotus. Ja saimniekprogramma veic vaicājumu datubāzē, piemēram, ar LLM ģenerētu SQL meklēšanu, tas tiek uzskatīts par rīka pieprasījumu.
Uzvednes: Tās ir atkārtoti izmantojamas uzvedņu veidnes, kas palīdz LLM veikt konkrētus uzdevumus. Lietotājs vai saimniekprogramma izsauc uzvedni, nevis rīku, jo uzdevuma izpildei ir nepieciešami gatavi norādījumi. Bieži vien iepriekš iestatīti uzdevumi saimniekprogrammā, piemēram, iespēja „pārskatīt kodu” vai „analizēt datus”, tiek glabāti kā uzvednes, kuras lietotājs var atlasīt.

Ir arī vērts atzīmēt, ka MCP un API nav savstarpēji izslēdzošas tehnoloģijas. MCP serveris var piedāvāt API izsaukumus, kas ir pieejami, atbildot uz atklāšanas pieprasījumu. Būtiski ir tas, ka to uzturēšana ir MCP nodrošinātāja, nevis klienta ziņā.

Datu slānis MCP arhitektūrā ir noteikumu kopums, kas nosaka, kā tiek formatēti pieprasījumi, atbildes un paziņojumi. Standarta valoda ziņojumiem ir JSON-RPC.

Jebkura MCP arhitektūra darbojas pēc vienkārša procesa: (1) saimniekprogramma veic inicializāciju un atklāšanu, (2) MCP serveris sniedz atbildi un (3) saimniekprogramma veic izsaukumu (dažkārt to izlemj LLM), un katrs posms ir atsevišķs JSON ziņojums.

MCP datu slāņa diagramma: lietotājs nosūta uzvedni saimniekprogrammai, kurā LLM sadarbojas ar MCP klientu; klients nosūta pieprasījumu MCP serverim (rīki, resursi, uzvednes) un saņem rezultātu, un saimniekprogramma atgriež lietotājam atbildi.

Apskatīsim, kā darbojas rīku atklāšana, izmantojot divus piemērus (tie var attiekties arī uz resursiem vai uzvednēm):

Rīku atklāšana pirms LLM ģenerēšanas: Saimniekprogramma palaiž MCP klientu, kas nosūta tools/list pieprasījumu (MCP servera pieejamo rīku sarakstu). LLM to pārskata ģenerēšanas procesā un nosaka, vai ir nepieciešams konkrēts rīks, resurss vai uzvedne.
Iespēja LLM veikt meklēšanu: Aģentiskā sistēmā saimniekprogramma pievieno atklāšanas iespēju, piemēram, search-tools, konteksta ievadei, un LLM pēc vajadzības var pieprasīt meklēšanu.

Rīkus, kas lielākoties ir ārēju lietotņu funkcijas, parasti atlasa LLM vai saimniekprogramma. Resursus un uzvednes parasti pieprasa pēc lietotāja vēlmes vai saimniekprogramma.

Lūk, kā izskatās tools/list pieprasījums MCP serverim no iedomātas piezīmju lietotnes:

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

Šajā piemērā “id”:101 identificē pieprasījumu ar ID, lai klients varētu sasaistīt atbildes, un laukā “params” ir papildu informācija par klientu, piemēram, klienta nosaukums (notes-app-client) un iespējas.

Atbildot MCP serveris atgriezīs rīku definīcijas, kurās ietverti pieejamo rīku nosaukumi un ar tiem saistītā informācija. Piemēram, sarakstā varētu būt rīks add-task, kas ļauj piezīmju lietotnei izveidot uzdevumus pievienotā uzdevumu pārvaldības vai kalendāra lietotnē, katram uzdevumam piešķirot nosaukumu un prioritāti.

Lūk, kā varētu izskatīties pieprasījums:

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

Lauks “method” norāda MCP serverim, ka tas ir rīka izsaukums, “name” norāda, kuru rīku izsaukt, un “arguments” nodrošina nepieciešamos ievaddatus.

Ja datu slānis ir savienojuma starp klientu un MCP serveri kas, tad transporta slānis ir kā. Tas nosaka, kādā veidā ziņojumi tiek pārsūtīti: konkrēto kanālu un noteikumus, kas regulē pieprasījumu un atbilžu piegādi.

MCP ir divi transporta ceļi:

Standarta ievade/izvade: To izmanto, ja MCP serveris darbojas tajā pašā lokālajā vidē, kurā saimniekprogramma. Klients ieraksta JSON pieprasījumu servera standarta ievadē. Serveris to nolasa, veic pieprasīto darbību un ieraksta atbildi standarta izvadē.
Streamable HTTP: Ja MCP serveris darbojas ārpus saimniekprogrammas, MCP klients sūta pieprasījumus serverim, izmantojot HTTP POST. Serveris atbild vai nu ar vienu JSON ziņojumu, vai ar Server-Sent Events (SSE) straumi — pastāvīgu „klausīšanās” kanālu, kas ļauj tam laika gaitā atgriezt vairākus ziņojumus.

MCP daudznomnieku arhitektūra ir tāds ieviešanas veids, kas var vienlaikus apkalpot vairākus lietotājus (nomniekus).

Šajā gadījumā nomnieks var būt indivīds, indivīdu grupa vai organizācija. Ieviešana var ietvert atsevišķa MCP servera darbināšanu katram nomniekam, piekļuves nodrošināšanu vienam koplietotam serverim vai serveru kopas izvietošanu aiz centrālas vārtejas. Ja tiek izmantota vārteja, tā novirza pieprasījumus uz pareizajiem galapunktiem, pamatojoties uz lietotāja identitāti vai pieprasījuma būtību.

Tā darbojas pēc tā paša pamatprincipa kā standarta MCP arhitektūra, taču atsevišķu lietotāju pieprasījumi tiek apstrādāti katrs savā darbvietā (pat ja tas nozīmē koplietotus resursus) un tiek autentificēti atsevišķi. Tā ir izplatīta uzņēmumu scenārijos, un bieži vien priekšroka tiek dota koplietotiem resursiem, jo vairāku MCP serveru darbināšana būtu nevajadzīgi dārga.

Kā praksē izskatās pilns MCP pieprasījums no sākuma līdz beigām? Ir astoņi galvenie posmi, un katrā no tiem ir iesaistīts atšķirīgs arhitektūras komponents.

Plūsmkarte, kurā pilns MCP pieprasījums attēlots astoņos soļos: rīku atklāšana, lietotāja ievade, modeļa apstrāde, rīka atlase, pieprasījums, rīka izpilde, rezultāts un atbildes ģenerēšana.

Lūk, kā praksē izskatās MCP rīka izsaukums, izmantojot iepriekšējo piemēru ar piezīmju lietotni, kas savienota ar uzdevumu pārvaldības pakalpojumu:

Rīku atklāšana: Piezīmju lietotne (saimniekprogramma) izmanto savu MCP klientu, lai ar tools/list pieprasījumu pieprasītu servera pieejamos rīkus. Serveris atgriež to nosaukumus, aprakstus un sagaidāmos ievaddatus, tostarp rīkam add-task. Tas var notikt, pirms jūs iesniedzat uzvedni.
Lietotāja ievade: Jūs iesniedzat pieprasījumu uz LLM balstītajai piezīmju lietotnei, izmantojot lietotnē iebūvēto tērzēšanas robotu, piemēram: „Izveido manā kalendārā uzdevumu pārskatīt manu jauno melnrakstu ar vidēju prioritāti.”
Modeļa apstrāde: Saimniekprogramma nosūta jūsu pieprasījumu un attiecīgās rīku definīcijas uz LLM.
Rīka atlase: LLM ģenerē strukturētu rīka pieprasījumu, norādot rīku un tā ievaddatus: add-task ar title: Pārskatīt melnrakstu un priority: Vidēja. Saimniekprogramma pārbauda, vai darbība ir atļauta, un nodod pieprasījumu MCP klientam, kas nosūta JSON-RPC ziņojumu.
Pieprasījums: MCP klients nosūta tools/call pieprasījumu savam MCP serverim.
Rīka izpilde: MCP serveris izsauc uzdevumu pārvaldības lietotnes API, lai izveidotu jaunu uzdevumu ar norādīto nosaukumu un prioritāti.
Rezultāta atgriešana: Serveris nosūta rezultātu atpakaļ MCP klientam, kas to nodod saimniekprogrammai. Saimniekprogramma to pievieno informācijai, kas tiek sniegta LLM.
Atbildes ģenerēšana: LLM izmanto rezultātu, lai ģenerētu atbildi lietotājam, piemēram: „Uzdevums pārskatīt melnrakstu ar vidēju prioritāti ir izveidots.”

MCP un tradicionālā API arhitektūra bieži tiek jauktas, taču tās ir viena otru papildinošas tehnoloģijas. MCP tika īpaši izstrādāts uz MI balstītām lietotnēm. Tas novērš lielo uzturēšanas slogu, ko rada vairāku iekodētu API savienojumu ieviešana un pārvaldība.

Nodrošinot saimniekprogrammai vienu savienojumu katram funkcionalitātes nodrošinātājam vai iekšējam resursam, MCP palīdz atrisināt pārslogotas konteksta ievades (visu API uzskaitīšanas) vai ierobežotu, uz API balstītu lietotņu skriptu problēmu.

Tā vietā MCP serveri var piedāvāt API (vai, precīzāk, funkcionalitāti, kas izsauc API) kā daļu no sava rīku saraksta. Ikreiz, kad pakalpojumu sniedzējs atjaunina savu lietotni un parādās jauns API vai mainās dokumentācija, tas vienkārši atjaunina MCP serveri. Saimniekprogrammas pusē koda izmaiņas nav nepieciešamas.

Kopš MCP ieviešanas par tā drošību notiek plašas diskusijas. Lai gan to parasti uzskata par drošu tehnoloģiju, pastāv vairāki drošības riski, no kuriem daudzi ir izteiktāki sarežģītās arhitektūras implementācijās.

MCP arhitektūrai ir šādas iespējamās vājās vietas:

Uzvedņu injekcija: Lietotājs ievieto ārējos datos ļaunprātīgu uzvedni, ko MI modelis kļūdaini interpretē kā norādījumu.
Pārmērīgas piekļuves tiesības: MCP serveri potenciāli var nodrošināt MI modelim piekļuvi lielam skaitam rīku, kas var palielināt drošības problēmu iespējamību (tā saukto ietekmes rādiusu).
Nejaušas datu noplūdes: Slikti konfigurētu implementāciju dēļ sensitīva informācija, piemēram, API atslēgas vai datubāzes akreditācijas dati, var tikt nodota LLM.
Lokālās sistēmas manipulācijas: Lokālie MCP serveri ir tikpat neaizsargāti pret lokālās sistēmas problēmām, piemēram, ļaunprātīgiem skriptiem, kā jebkuras citas lietotnes, turklāt tie var radīt kaitīgas sekas tālāk aģentiskajās MI sistēmās.

Neviena no šīm problēmām nav nepārvarama. Bieži vien sistēmas drošības nodrošināšanai pietiek ar vispāratzītiem pasākumiem. Tādi pasākumi kā cilvēka iesaiste procesā, stingra kontrole pār sensitīviem datiem un aizsardzība pret uzbrukumiem serveriem ir izplatīta prakse.

MCP ir izrādījies noderīgs un populārs atvērtais standarts izstrādātājiem. Tas novērš daudzas iekodētu API problēmas uz LLM balstītās lietotnēs un ievērojami samazina izstrādātāju programmēšanas slogu.

Turpmāk MCP pamatā esošā saimniekprogrammas un servera arhitektūra gandrīz noteikti paliks nemainīga. Nākotnes inovācijas būs vērstas uz progresīvām aģentiskām spējām vairāku soļu darbplūsmās.

Turklāt, ieviešot šīs aģentiskās funkcijas, būs nepieciešami stingrāki drošības pasākumi, kā arī mērogojama arhitektūra, jo īpaši transporta slānī, jo MI sistēmas kļūst arvien plašākas un sarežģītākas.

Kas ir MCP arhitektūra?

MCP arhitektūras komponenti: saimniekprogrammas, klienti un serveri

Saimniekprogramma

Klients

Serveris

Kas ir datu slānis MCP arhitektūrā?

Kas ir transporta slānis MCP arhitektūrā?

Kas ir MCP daudznomnieku arhitektūra?

MCP arhitektūras diagramma: skaidrojums soli pa solim

Ar ko MCP arhitektūra atšķiras no tradicionālās API arhitektūras?

Vai MCP arhitektūra ir droša?

Kas sagaida MCP arhitektūru nākotnē?