MCP arhitektuur: põhjalik tehniline ülevaade koos skeemidega

MCP arhitektuur on põhikomponentide ja suhtlusreeglite kogum, mis teeb MCP (Model Context Protocol) võimalikuks. MCP on avatud lähtekoodiga standard ja MCP arhitektuur on selle aluseks olev taristu, millel see töötab.

Iga MCP arhitektuur sisaldab kolme põhikomponenti ja on üles ehitatud nende ümber: host, klient ja server. MCP suhtlusraamistikku kirjeldatakse sageli andmekihist ja transpordikihist koosnevana. Andmekiht on reeglite kogum, mis määrab, kuidas sõnumid vormindatakse (MCP päringud saadetakse JSON-RPC 2.0 vormingus). Transpordikiht edastab neid sõnumeid, kasutades väliste ühenduste jaoks Streaming HTTP-d.

MCP arhitektuur on serveriraamistik, mis rakendab Model Context Protocoli – avatud standardit tehisintellekti mudelite ühendamiseks tööriistadega, ressurssidega (nt andmebaasid) ja sisendi konteksti laiendavate viipadega. Neid nimetatakse ühiselt „primitiivideks“. Lõppkokkuvõttes võimaldab MCP arhitektuur LLM-idel avastada, millised tööriistad on saadaval, ja käivitada töövooge, ilma et kliendipoolset tarkvara peaks regulaarselt uuendama.

MCP arhitektuuri skeem: tehisintellekti rakendus vahetab päringuid MCP serveriga, mis pakub tööriistu, ressursse ja viipasid.

Pärast seda, kui Anthropic MCP tutvustas, on MCP arhitektuur muutunud tehisintellekti töövoogudes laialt kasutatavaks. Peamiselt seetõttu, et see asendab suurema hooldusvajadusega süsteeme, näiteks mitme API-ühenduse ümber ehitatud lahendusi, ilma jõudluses järele andmata. Kuna kogu saadaolev funktsionaalsus asub MCP serveri taga, on vaja ainult ühte ühendust ning uuendused ja lisandused on kliendirakendusele kohe kättesaadavad.

MCP annab LLM-idele võimaluse avastada ja välja kutsuda neile saadaolevaid tööriistu, viipasid ja ressursse kas hostrakenduse kohalikus süsteemis või välise teenusepakkuja juures.

Tööriistade puhul, mis annavad juurdepääsu välisele funktsionaalsusele, tähendab avastamine seda, et host teeb MCP serverile tools/list kutse, et teada saada, millised tööriistad on saadaval. Seejärel saab LLM (või mõnel juhul host) lugeda saadaolevate tööriistade kirjeldusi ja neid vajaduse korral taotleda. Viibad ja ressursid kasutavad sarnast protsessi.

MCP arhitektuuri komponentide skeem: host, mis sisaldab LLM-i, orkestraatorit ja klienti, ühendub MCP serveriga kahes etapis – esmalt avastamine ja seejärel päringud – ning MCP server pakub tööriistu, ressursse ja viipasid.

See erineb eritellimusel loodud API-põhisest arhitektuurist, mis on olnud tarkvaraarenduses tavapärane ja kus rakendusevälist funktsionaalsust tuli välja kutsuda spetsiaalsete ühenduste kaudu täpselt vormindatud päringutega.

Hostrakendus on keskne orkestreerimisplatvorm, mis ühendub LLM-iga. Tuntud tööriistad, nagu Perplexity ja Claude Desktop, võivad MCP süsteemis toimida hostidena.

Lihtsas töövoos esitab kasutaja vestlusliidese kaudu küsimuse. Seejärel lisab hosti orkestraatorkomponent küsimusele konteksti, teatades LLM-ile, millised MCP primitiivid on saadaval, ja kirjeldades nende võimekusi.

Klient on tehisintellekti rakenduse tarkvarakomponent. MCP pakub kliendile standardse liidese, et suhelda sisemiste ja väliste MCP serveritega hosti või LLM-i juhiste alusel. Kliendi ülesanne on luua ühendus, vormindada JSON-RPC sõnumeid, saata päringuid ja võtta vastu vastuseid.

Mõisteid „MCP host“ ja „MCP klient“ kasutatakse mõnikord samas tähenduses. Siiski on see kasulik eristus, sest host, näiteks Perplexity, võib korraga orkestreerida mitut MCP klienti. Keerukas tehisintellekti töövoog võib vajada juurdepääsu kümnetele või isegi sadadele eraldi MCP serveritele ning igaüks neist kasutab eraldi ühendust.

Skeem, kus MCP host, näiteks Perplexity, orkestreerib kolme MCP klienti, millest igaüks on ühendatud oma MCP serveriga, nagu andmebaas, failid või väline API.

Server teeb kättesaadavaks kõik tööriistad, mida tehisintellektil põhinev tööriist saab kasutada. Arhitektuuri seisukohast tõlgendab MCP server sissetulevat päringut ja ühendub vajaduse korral soovitud primitiividega.

MCP serverid võivad anda juurdepääsu kolme kategooria primitiividele:

Tööriistad: need on sisuliselt välise tarkvara funktsioonid. Traditsioonilise API-põhise lähenemise puhul võib veebianalüütika rakendus hankida andmeid välisele serverile saadetud vormindatud päringu abil. MCP arhitektuuris on kogu teenusepakkuja kolmanda osapoole funktsionaalsus saadaval ühe ühenduse kaudu ning päringud koostatakse standardsete vormindusreeglite järgi.
Ressursid: ressursid on andmeallikad, mis pakuvad ainult loetavat konteksti. Hea näide on andmebaasiskeemid. MCP-server teeb hostile nähtavaks erinevad talle kättesaadavad teabeallikad. Kui host esitab päringu andmebaasile, näiteks LLM-i loodud SQL-otsinguga, loetakse seda tööriistapäringuks.
Viibad: need on korduvkasutatavad viibamallid, mis aitavad LLM-idel konkreetseid ülesandeid täita. Kasutaja või host kutsub tööriista asemel välja viiba, kuna ülesande täitmiseks on vaja valmisjuhiseid. Sageli salvestatakse hostrakenduse eelseadistatud ülesanded, näiteks valikud „vaata kood üle“ või „analüüsi andmeid“, viipadena, mida kasutaja saab valida.

Tasub ka märkida, et MCP ja API ei ole üksteist välistavad tehnoloogiad. MCP server võib avastamispäringu vastuseks teha kättesaadavaks API-kutseid. Oluline on see, et nende haldamine on MCP pakkuja, mitte kliendi ülesanne.

MCP arhitektuuri andmekiht on reeglite kogum, mis määrab, kuidas päringud, vastused ja märguanded vormindatakse. Sõnumite standardkeel on JSON-RPC.

Iga MCP arhitektuur järgib põhiprotsessi, mis koosneb (1) hosti tehtavast lähtestamisest ja avastamisest, (2) MCP serveri vastusest ning (3) hosti tehtavast kutsest (mille üle otsustab mõnikord LLM), kusjuures iga etapp on eraldi JSON-sõnum.

MCP andmekihi skeem: kasutaja saadab viiba hostrakendusele, kus LLM töötab koos MCP kliendiga; klient saadab päringu MCP serverile (tööriistad, ressursid, viibad) ja saab tulemuse ning host tagastab kasutajale vastuse.

Vaatame kahe näite abil, kuidas tööriistade avastamine toimib (need võivad kehtida ka ressursside või viipade kohta):

Tööriistade avastamine enne LLM-i genereerimist: host käivitab MCP kliendi, mis saadab tools/list päringu (MCP serveri saadaolevate tööriistade loend). LLM vaatab selle genereerimise käigus üle ja otsustab, kas on vaja konkreetset tööriista, ressurssi või viipa.
LLM-ile otsingu käivitamise võimaluse andmine: agentses süsteemis lisab host kontekstisisendisse avastamisvaliku, näiteks search-tools, ja LLM saab vajaduse korral otsingut taotleda.

Tööriistu, mis on enamjaolt väliste rakenduste funktsioonid, valib tavaliselt LLM või host. Ressursse ja viipasid taotletakse tavaliselt kasutaja soovil või hosti poolt.

Selline näeb välja väljamõeldud märkmerakenduse tools/list päring MCP serverile:

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

Selles näites tuvastab “id”:101 päringu ID abil, et klient saaks vastused päringuga vastavusse viia, ning väli “params” sisaldab lisateavet kliendi kohta, näiteks kliendi nime (notes-app-client) ja võimekusi.

Vastuseks tagastab MCP server tööriistade definitsioonid, mis sisaldavad saadaolevate tööriistade nimesid ja nendega seotud üksikasju. Näiteks võib loendis olla tööriist add-task, mis võimaldab märkmerakendusel luua ülesandeid ühendatud ülesannete haldamise või kalendri rakenduses ning määrata igale ülesandele pealkirja ja prioriteedi.

Päring võiks välja näha selline:

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

Väli “method” annab MCP serverile teada, et tegemist on tööriistakutsega, “name” määrab, millist tööriista kutsuda, ja “arguments” esitab nõutavad sisendid.

Kui andmekiht on kliendi ja MCP serveri vahelise ühenduse mis, siis transpordikiht on selle kuidas. See määrab, kuidas sõnumid liiguvad: konkreetse kanali ja reeglid, mis reguleerivad päringute ja vastuste edastamist.

MCP-l on kaks transporditeed:

Standardsisend/-väljund: seda kasutatakse siis, kui MCP server töötab hostrakendusega samas kohalikus keskkonnas. Klient kirjutab JSON-päringu serveri standardsisendisse. Server loeb selle, teeb soovitud toimingu ja kirjutab vastuse standardväljundisse.
Voogedastatav HTTP: kui MCP server töötab hostrakendusest väljaspool, saadab MCP klient serverile päringuid meetodiga HTTP POST. Server vastab kas ühe JSON-sõnumiga või Server-Sent Events (SSE) vooga – püsiva „kuulamiskanaliga“, mis võimaldab tal aja jooksul tagastada mitu sõnumit.

MCP mitme rentnikuga arhitektuur on teostusviis, mis suudab teenindada mitut kasutajat (rentnikku) samaaegselt.

Siin võib rentnik olla üksikisik, inimeste rühm või organisatsioon. Teostus võib hõlmata iga rentniku jaoks eraldi MCP serveri käitamist, juurdepääsu andmist ühele jagatud serverile või serverite komplekti paigutamist keskse lüüsi taha. Lüüsi kasutamisel suunab see päringud õigetesse lõpp-punktidesse kasutaja identiteedi või päringu olemuse alusel.

See toimib samal põhimõttel nagu tavaline MCP arhitektuur, kuid üksikute kasutajate päringud toimivad oma tööruumis (isegi kui see tähendab jagatud ressursse) ja autenditakse eraldi. See on levinud ettevõttekeskkondades ning sageli eelistatakse jagatud ressursse, sest mitme MCP serveri käitamine oleks asjatult kulukas.

Kuidas näeb otsast lõpuni MCP päring praktikas välja? Sellel on kaheksa põhietappi, millest igaüks hõlmab eraldi arhitektuurikomponenti.

Vooskeem otsast lõpuni MCP päringust kaheksas etapis: tööriistade avastamine, kasutaja sisend, mudeli töötlus, tööriista valik, päring, tööriista käivitamine, tulemus ja vastuse genereerimine.

Nii näeb MCP tööriistakutse praktikas välja, kasutades varasemat näidet märkmerakendusest, mis on ühendatud ülesannete haldamise teenusega:

Tööriistade avastamine: märkmerakendus (host) kasutab oma MCP-klienti, et küsida päringuga tools/list serveri saadaolevaid tööriistu. Server tagastab nende nimed, kirjeldused ja oodatavad sisendid, sealhulgas tööriista add-task omad. See võib toimuda enne, kui viiba esitate.
Kasutaja sisend: esitate LLM-põhisele märkmerakendusele rakendusesisese vestlusroboti kaudu päringu, näiteks: „Loo mu kalendrisse keskmise prioriteediga ülesanne mu uue mustandi ülevaatamiseks.“
Mudeli töötlus: host saadab teie päringu ja asjakohased tööriistade definitsioonid LLM-ile.
Tööriista valik: LLM genereerib struktureeritud tööriistapäringu, määrates tööriista ja selle sisendid: add-task, kus title: Review the draft ja priority: Medium. Host kontrollib, kas toiming on lubatud, ja edastab päringu MCP kliendile, mis saadab JSON-RPC sõnumi.
Päring: MCP klient saadab oma MCP serverile tools/call päringu.
Tööriista käivitamine: MCP server kutsub välja ülesannete haldamise rakenduse API, et luua määratud pealkirja ja prioriteediga uus ülesanne.
Tulemuse tagastamine: server saadab tulemuse tagasi MCP kliendile, mis edastab selle hostile. Host lisab selle LLM-ile antavale teabele.
Vastuse genereerimine: LLM kasutab tulemust, et genereerida kasutajale vastus, näiteks: „Lõin keskmise prioriteediga ülesande mustandi ülevaatamiseks.“

MCP-d ja traditsioonilist API-arhitektuuri aetakse sageli segi, kuid need on teineteist täiendavad tehnoloogiad. MCP loodi spetsiaalselt tehisintellektil põhinevate rakenduste jaoks. See kõrvaldab mitme jäigalt kodeeritud API-ühenduse loomise ja haldamisega kaasneva suure hoolduskoormuse.

Pakkudes hostrakendusele iga funktsionaalsuse pakkuja või sisemise ressursi kohta ühe ühenduse, aitab MCP lahendada paisunud kontekstisisendi (kõigi API-de loetlemine) või piiratud API-põhiste rakendusskriptide probleemi.

Selle asemel saavad MCP-d teha API-d (õigemini API-sid väljakutsuva funktsionaalsuse) kättesaadavaks oma tööriistaloendi osana. Kui pakkuja uuendab oma rakendust ja lisandub uus API või muutub dokumentatsioon, uuendab ta lihtsalt MCP serverit. Hostrakenduse poolel pole koodimuudatusi vaja.

MCP turvalisus on alates selle kasutuselevõtust olnud palju arutelu teema. Kuigi seda peetakse üldiselt turvaliseks tehnoloogiaks, on sellel mitu turvariski, millest paljud ilmnevad selgemini keerukate arhitektuurilahenduste puhul.

MCP arhitektuuril on järgmised võimalikud nõrkused:

Viibasüst: kasutaja sisestab välistesse andmetesse pahatahtliku viiba, mida tehisintellektimudel tõlgendab ekslikult juhisena.
Liigsed õigused: MCP serverid võivad teha tehisintellekti mudelile kättesaadavaks suure hulga tööriistu, mis võib suurendada turbeprobleemide võimalikku ulatust (mõjuraadiust).
Juhuslikud andmelekked: halvasti seadistatud lahenduste tõttu võib tundlik teave, nagu API-võtmed või andmebaasi sisselogimisandmed, jõuda LLM-ini.
Kohaliku süsteemiga manipuleerimine: kohalikud MCP serverid on kohaliku süsteemi probleemide, näiteks pahatahtlike skriptide suhtes sama haavatavad kui mis tahes muu rakendus, lisaks võib neil olla agentsetele tehisintellekti süsteemidele kahjulik järelmõju.

Ükski neist probleemidest pole ületamatu. Sageli piisab süsteemi turvalisuse tagamiseks väljakujunenud meetmetest. Sellised meetmed nagu inimese kaasamine protsessi, tundlike andmete range kontroll ja serverirünnakute eest kaitsmine on kõik levinud tavad.

MCP on osutunud arendajatele kasulikuks ja populaarseks avatud standardiks. See lahendab paljud LLM-põhiste rakenduste jäigalt kodeeritud API-dega seotud probleemid ja vähendab oluliselt arendajate kodeerimiskoormust.

Edaspidi jääb MCP aluseks olev hosti- ja serveriarhitektuur peaaegu kindlasti samaks. Tulevased uuendused keskenduvad täiustatud agentsetele võimekustele mitmeetapilistes töövoogudes.

Lisaks on agentsete funktsioonide rakendamisel vaja tugevamaid turvameetmeid ning tehisintellekti süsteemide laienemise ja keerukamaks muutumisega ka skaleeritavat arhitektuuri, eriti transpordikihis.

Mis on MCP arhitektuur?

MCP arhitektuuri komponendid: hostid, kliendid ja serverid

Host

Klient

Server

Mis on andmekiht MCP arhitektuuris?

Mis on transpordikiht MCP arhitektuuris?

Mis on MCP mitme rentnikuga arhitektuur?

MCP arhitektuuri skeem: samm-sammuline ülevaade

Mille poolest erineb MCP arhitektuur traditsioonilisest API-arhitektuurist?

Kas MCP arhitektuur on turvaline?

Mis ootab MCP arhitektuuri ees?