MCP architektūra: išsami techninė analizė su diagramomis

MCP architektūra – tai pamatinis komponentų ir komunikacijos taisyklių rinkinys, leidžiantis veikti MCP (Model Context Protocol). MCP yra atvirojo kodo standartas, o MCP architektūra – pagrindinė infrastruktūra, kurioje jis veikia.

Kiekviena MCP architektūra apima tris pagrindinius komponentus ir yra kuriama aplink juos: pagrindinę programą (host), klientą ir serverį. MCP komunikacijos sistema dažnai apibūdinama kaip sudaryta iš duomenų sluoksnio ir transporto sluoksnio. Duomenų sluoksnis – tai taisyklių rinkinys, nustatantis, kaip formatuojami pranešimai (MCP užklausos siunčiamos JSON-RPC 2.0 formatu). Transporto sluoksnis perduoda tuos pranešimus, išoriniams ryšiams naudodamas Streaming HTTP.

MCP architektūra – tai serverio karkasas, įgyvendinantis Model Context Protocol – atvirąjį standartą, skirtą DI modeliams sujungti su įrankiais, ištekliais, pvz., duomenų bazėmis, ir raginimais, praplečiančiais įvesties kontekstą. Visi jie bendrai vadinami „primityvais“. Galiausiai MCP architektūra leidžia LLM aptikti, kokie įrankiai yra prieinami, ir vykdyti darbo eigas, nereikalaujant reguliarių atnaujinimų kliento pusėje.

MCP architektūros diagrama: DI programa keičiasi užklausomis su MCP serveriu, kuris teikia įrankius, išteklius ir raginimus.

Nuo tada, kai ją pristatė Anthropic, MCP architektūra plačiai naudojama DI darbo eigose. Daugiausia taip yra todėl, kad ji pakeičia daug priežiūros reikalaujančias sistemas, pavyzdžiui, sukurtas aplink kelis API ryšius, neprarandant našumo. Kadangi visos prieinamos funkcijos yra už MCP serverio, reikia tik vieno ryšio, o atnaujinimai ir papildymai iš karto tampa prieinami kliento programai.

MCP suteikia LLM galimybę aptikti ir iškviesti jiems prieinamus įrankius, raginimus ir išteklius – pagrindinės programos vietinėje sistemoje arba iš išorinio teikėjo.

Įrankių, suteikiančių prieigą prie išorinių funkcijų, atveju aptikimas reiškia, kad pagrindinė programa atlieka tools/list iškvietimą į MCP serverį ir sužino, kokie įrankiai yra prieinami. Tada LLM (arba kai kuriais atvejais pagrindinė programa) gali perskaityti prieinamų įrankių aprašus ir prireikus juos užklausti. Raginimams ir ištekliams taikomas panašus procesas.

MCP architektūros komponentų diagrama: pagrindinė programa, kurioje yra LLM, orkestratorius ir klientas, prisijungia prie MCP serverio dviem etapais – pirmiausia aptikimas, tada užklausos, o MCP serveris teikia įrankius, išteklius ir raginimus.

Tai skiriasi nuo individualiai kuriamos API pagrįstos architektūros, kuri programinės įrangos kūrime buvo įprasta norma: funkcijas už programos ribų reikėjo iškviesti per specialius ryšius, naudojant tiksliai suformatuotas užklausas.

Pagrindinė programa yra centrinė orkestravimo platforma, prisijungianti prie LLM. Gerai žinomi įrankiai, tokie kaip Perplexity ir Claude Desktop, MCP sistemoje gali veikti kaip pagrindinės programos.

Paprastoje darbo eigoje naudotojas užduoda klausimą pokalbių sąsajoje. Tada pagrindinės programos orkestratoriaus komponentas papildo klausimą kontekstu ir nurodo LLM, kokie MCP primityvai yra prieinami, kartu pateikdamas jų galimybių aprašą.

Klientas yra DI programos programinės įrangos komponentas. MCP suteikia standartinę sąsają, per kurią klientas, vadovaudamasis pagrindinės programos arba LLM nurodymais, bendrauja su vidiniais ir išoriniais MCP serveriais. Jo užduotis – užmegzti ryšį, formatuoti JSON-RPC pranešimus, siųsti užklausas ir gauti atsakymus.

Terminai „MCP pagrindinė programa“ (MCP host) ir „MCP klientas“ kartais vartojami kaip sinonimai. Vis dėlto šis skirtumas naudingas, nes pagrindinė programa, pvz., Perplexity, vienu metu gali orkestruoti kelis MCP klientus. Sudėtingai DI darbo eigai gali prireikti prieigos prie dešimčių ar net šimtų atskirų MCP serverių, ir kiekvienas jų naudos atskirą ryšį.

MCP pagrindinės programos, pvz., Perplexity, diagrama: ji orkestruoja tris MCP klientus, kurių kiekvienas prijungtas prie savo MCP serverio, pvz., duomenų bazės, failų ar išorinės API.

Serveris pateikia visus įrankius, kuriuos gali naudoti DI pagrįstas įrankis. Architektūros požiūriu MCP serveris interpretuoja gaunamą užklausą ir, kai reikia, prisijungia prie užklaustų primityvų.

MCP serveriai gali suteikti prieigą prie trijų kategorijų primityvų:

Įrankiai: iš esmės tai išorinės programinės įrangos funkcijos. Jei svarstytume tradicinį API pagrįstą metodą, žiniatinklio analitikos programa galėtų gauti duomenis siųsdama suformatuotą užklausą į išorinį serverį. MCP architektūroje visos teikėjo trečiųjų šalių funkcijos prieinamos per vieną ryšį, o užklausos kuriamos pagal standartines formatavimo taisykles.
Ištekliai: ištekliai – tai duomenų šaltiniai, teikiantys tik skaitymui skirtą kontekstą. Geras pavyzdys – duomenų bazių schemos. MCP serveris pateikia įvairius informacijos šaltinius, prieinamus pagrindinei programai. Jei pagrindinė programa pateikia užklausą duomenų bazei, pavyzdžiui, LLM sugeneruota SQL paieška, tai laikoma įrankio užklausa.
Raginimai: tai daugkartinio naudojimo raginimų šablonai, padedantys LLM atlikti konkrečias užduotis. Naudotojas arba pagrindinė programa iškviečia raginimą, o ne įrankį, nes užduočiai atlikti reikia iš anksto paruoštų instrukcijų. Dažnai pagrindinėje programoje iš anksto nustatytos užduotys, pvz., parinktis „peržiūrėti kodą“ arba „analizuoti duomenis“, saugomos kaip raginimai, kuriuos naudotojas gali pasirinkti.

Taip pat verta paminėti, kad MCP ir API nėra viena kitą atmetančios technologijos. MCP serveris gali pateikti API iškvietimus, prieinamus atsakant į aptikimo užklausą. Svarbiausia, kad juos prižiūrėti turi MCP teikėjas, o ne klientas.

Duomenų sluoksnis MCP architektūroje – tai taisyklių rinkinys, apibrėžiantis, kaip formatuojamos užklausos, atsakymai ir pranešimai. Standartinė pranešimų kalba yra JSON-RPC.

Visa MCP architektūra vadovaujasi pagrindiniu procesu: (1) pagrindinės programos atliekamas inicijavimas ir aptikimas, (2) MCP serverio atsakymas ir (3) pagrindinės programos iškvietimas (kartais apie jį sprendžia LLM); kiekvienas etapas yra atskiras JSON pranešimas.

MCP duomenų sluoksnio diagrama: naudotojas siunčia raginimą pagrindinei programai, kurioje LLM veikia kartu su MCP klientu; klientas siunčia užklausą MCP serveriui (įrankiai, ištekliai, raginimai) ir gauna rezultatą, o pagrindinė programa grąžina atsakymą naudotojui.

Pažiūrėkime, kaip veikia įrankių aptikimas, remdamiesi dviem pavyzdžiais (jie gali būti taikomi ir ištekliams ar raginimams):

Įrankių aptikimas prieš LLM generavimą: pagrindinė programa inicijuoja MCP klientą, kuris siunčia tools/list užklausą (MCP serverio prieinamų įrankių sąrašas). LLM peržiūri jį generavimo metu ir nustato, ar reikia konkretaus įrankio, ištekliaus ar raginimo.
LLM suteikiama galimybė atlikti paiešką: agentinėje sistemoje pagrindinė programa prideda aptikimo parinktį, pvz., search-tools, prie įvesties konteksto, ir LLM prireikus gali paprašyti atlikti paiešką.

Įrankius, kurie daugiausia yra išorinių programų funkcijos, paprastai pasirenka LLM arba pagrindinė programa. Išteklių ir raginimų paprastai užklausiama naudotojo prašymu arba pagrindinės programos iniciatyva.

Štai kaip atrodo tools/list užklausa MCP serveriui iš įsivaizduojamos užrašų programos:

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

Šiame pavyzdyje “id”:101 identifikuoja užklausą pagal ID, kad klientas galėtų susieti atsakymus, o lauke “params” pateikiama papildoma informacija apie klientą, pvz., kliento pavadinimas (notes-app-client) ir galimybės.

Atsakydamas MCP serveris grąžins įrankių apibrėžtis, kuriose nurodomi prieinamų įrankių pavadinimai ir susijusi informacija. Pavyzdžiui, sąraše gali būti įrankis add-task, leidžiantis užrašų programai kurti užduotis prijungtoje užduočių valdymo ar kalendoriaus programoje ir kiekvienai užduočiai priskirti pavadinimą bei prioritetą.

Štai kaip galėtų atrodyti užklausa:

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

Laukas “method” nurodo MCP serveriui, kad tai įrankio iškvietimas, “name” nurodo, kurį įrankį iškviesti, o “arguments” pateikia reikiamus įvesties duomenis.

Jei duomenų sluoksnis yra kliento ir MCP serverio ryšio kas, tai transporto sluoksnis yra kaip. Jis apibrėžia, kokiu būdu keliauja pranešimai: konkretų kanalą ir taisykles, pagal kurias pristatomos užklausos ir atsakymai.

MCP turi du transporto būdus:

Standartinė įvestis / išvestis: naudojama, kai MCP serveris veikia toje pačioje vietinėje aplinkoje kaip ir pagrindinė programa. Klientas įrašo JSON užklausą į serverio standartinę įvestį. Serveris ją nuskaito, atlieka užklaustą operaciją ir įrašo atsakymą į standartinę išvestį.
Streamable HTTP: kai MCP serveris veikia už pagrindinės programos ribų, MCP klientas siunčia užklausas serveriui naudodamas HTTP POST. Serveris atsako vienu JSON pranešimu arba Server-Sent Events (SSE) srautu – nuolatiniu „klausymosi“ kanalu, leidžiančiu jam laikui bėgant grąžinti kelis pranešimus.

MCP kelių nuomininkų architektūra – tai įgyvendinimo tipas, galintis vienu metu aptarnauti kelis naudotojus (nuomininkus).

Šiuo atveju nuomininkas gali būti asmuo, asmenų grupė arba organizacija. Įgyvendinant galima kiekvienam nuomininkui paleisti atskirą MCP serverį, suteikti prieigą prie vieno bendro serverio arba serverių rinkinį patalpinti už centrinio šliuzo. Kai naudojamas šliuzas, jis nukreipia užklausas į tinkamus galinius taškus pagal naudotojo tapatybę arba užklausos pobūdį.

Ji veikia tuo pačiu pagrindiniu principu kaip ir standartinė MCP architektūra, tačiau kiekviena naudotojo užklausa vykdoma savo darbo erdvėje (net jei naudojami bendri ištekliai) ir autentifikuojama atskirai. Tai įprasta įmonių aplinkoje, o bendriems ištekliams dažnai teikiama pirmenybė, nes paleisti kelis MCP serverius būtų be reikalo brangu.

Kaip praktiškai atrodo visa MCP užklausos eiga nuo pradžios iki pabaigos? Yra aštuoni pagrindiniai etapai, kurių kiekviename dalyvauja atskiras architektūros komponentas.

Blokinė schema, vaizduojanti visą MCP užklausos eigą aštuoniais žingsniais: įrankių aptikimas, naudotojo įvestis, modelio apdorojimas, įrankio pasirinkimas, užklausa, įrankio vykdymas, rezultatas ir atsakymo generavimas.

Štai kaip praktiškai atrodo MCP įrankio iškvietimas, naudojant ankstesnį užrašų programos, prijungtos prie užduočių valdymo paslaugos, pavyzdį:

Įrankių aptikimas: užrašų programa (pagrindinė programa) per savo MCP klientą pateikia tools/list užklausą, kuria paprašo serverio prieinamų įrankių. Serveris grąžina jų pavadinimus, aprašus ir laukiamus įvesties duomenis, įskaitant add-task įrankio duomenis. Tai gali įvykti dar prieš jums pateikiant raginimą.
Naudotojo įvestis: per programoje integruotą pokalbių robotą pateikiate užklausą LLM pagrįstai užrašų programai, pvz.: „Sukurk mano kalendoriuje vidutinio prioriteto užduotį peržiūrėti naują juodraštį.“
Modelio apdorojimas: pagrindinė programa siunčia jūsų užklausą ir atitinkamas įrankių apibrėžtis LLM.
Įrankio pasirinkimas: LLM sugeneruoja struktūrizuotą įrankio užklausą, nurodydamas įrankį ir jo įvesties duomenis: add-task su title: Peržiūrėti juodraštį ir priority: Vidutinis. Pagrindinė programa patikrina, ar veiksmas leidžiamas, ir perduoda užklausą MCP klientui, kuris išsiunčia JSON-RPC pranešimą.
Užklausa: MCP klientas siunčia tools/call užklausą savo MCP serveriui.
Įrankio vykdymas: MCP serveris iškviečia užduočių valdymo programos API, kad sukurtų naują užduotį su nurodytu pavadinimu ir prioritetu.
Rezultato grąžinimas: serveris siunčia rezultatą atgal MCP klientui, kuris jį perduoda pagrindinei programai. Pagrindinė programa įtraukia jį į LLM pateikiamą informaciją.
Atsakymo generavimas: LLM pagal rezultatą sugeneruoja atsakymą naudotojui, pvz.: „Sukūriau vidutinio prioriteto užduotį peržiūrėti juodraštį.“

MCP ir tradicinė API architektūra dažnai painiojamos, tačiau tai viena kitą papildančios technologijos. MCP buvo sukurtas specialiai DI pagrįstoms programoms. Jis pašalina didelę priežiūros naštą, susijusią su kelių griežtai užkoduotų API ryšių įgyvendinimu ir valdymu.

Suteikdamas pagrindinei programai po vieną ryšį kiekvienam funkcijų teikėjui ar vidiniam ištekliui, MCP padeda išspręsti per didelės konteksto įvesties (kai išvardijamos visos API) arba ribotų API pagrindu veikiančių programų scenarijų problemą.

Vietoj to MCP gali pateikti API (tiksliau, funkcijas, kurios iškviečia API) kaip savo įrankių sąrašo dalį. Kai teikėjas atnaujina savo programą ir atsiranda nauja API arba pasikeičia dokumentacija, jis tiesiog atnaujina MCP serverį. Pagrindinės programos pusėje kodo keisti nereikia.

MCP saugumas nuo pat jo pristatymo kelia daug diskusijų. Nors ši technologija paprastai laikoma saugia, yra keletas saugumo rizikų, kurių daugelis ryškesnės sudėtingose architektūros realizacijose.

MCP architektūra turi šių galimų silpnųjų vietų:

Raginimų injekcija: naudotojas į išorinius duomenis įterpia kenkėjišką raginimą, kurį DI modelis klaidingai interpretuoja kaip instrukciją.
Perteklinės prieigos teisės: MCP serveriai DI modeliui gali pateikti daug įrankių, todėl gali padidėti saugumo problemų tikimybė (poveikio spindulys).
Atsitiktiniai duomenų nutekėjimai: dėl netinkamai sukonfigūruotų realizacijų LLM gali būti perduota neskelbtina informacija, pvz., API raktai ar duomenų bazių prisijungimo duomenys.
Vietinės sistemos manipuliavimas: vietiniai MCP serveriai yra lygiai taip pat pažeidžiami dėl vietinės sistemos problemų, pvz., kenkėjiškų scenarijų, kaip ir bet kurios kitos programos, be to, jie gali daryti žalingą poveikį toliau grandinėje esančioms agentinio DI sistemoms.

Nė viena iš šių problemų nėra neįveikiama. Dažnai sistemos saugumui užtikrinti pakanka nusistovėjusių priemonių. Tokios priemonės kaip žmogaus dalyvavimas procese, griežta neskelbtinų duomenų kontrolė ir apsauga nuo serverių atakų yra įprasta praktika.

MCP įrodė esąs naudingas ir populiarus atvirasis standartas kūrėjams. Jis išsprendžia daugelį griežtai užkoduotų API problemų LLM pagrįstose programose ir gerokai sumažina kūrėjų programavimo naštą.

Ateityje MCP pagrindinės programos ir serverio architektūros pagrindai beveik neabejotinai išliks tokie patys. Būsimos inovacijos bus sutelktos į pažangias agentines galimybes kelių žingsnių darbo eigose.

Be to, diegiant šias agentines funkcijas reikės stipresnių saugumo apsaugos priemonių, o DI sistemoms tampant platesnėmis ir sudėtingesnėmis – ir keičiamo mastelio architektūros, ypač transporto sluoksnyje.

Kas yra MCP architektūra?

MCP architektūros komponentai: pagrindinės programos, klientai ir serveriai

Pagrindinė programa (host)

Klientas

Serveris

Kas yra duomenų sluoksnis MCP architektūroje?

Kas yra transporto sluoksnis MCP architektūroje?

Kas yra MCP kelių nuomininkų architektūra?

MCP architektūros diagrama: paaiškinimas žingsnis po žingsnio

Kuo MCP architektūra skiriasi nuo tradicinės API architektūros?

Ar MCP architektūra saugi?

Kas laukia MCP architektūros ateityje?