MCP-arkitektúr: Ítarleg tæknileg greining með skýringarmyndum

Tæknileg greining á MCP-arkitektúr sem fjallar um hýsla, biðlara og þjóna, JSON-RPC-gagnalagið, flutningsleiðir, fjölleigjendauppsetningar, öryggisáhættu og yfirferð yfir beiðni í átta skrefum með skýringarmyndum.

Diagram of MCP architecture: an AI application exchanges requests with an MCP server, which provides tools, resources, and prompts.

MCP-arkitektúr er grunnsafn þeirra íhluta og samskiptareglna sem gera MCP (Model Context Protocol) mögulegt. MCP er opinn staðall með opnum frumkóða og MCP-arkitektúr er sá undirliggjandi innviður sem hann keyrir á.

Sérhver MCP-arkitektúr inniheldur þrjá meginíhluti og er byggður í kringum þá: hýsil, biðlara og þjón. Samskiptarammi MCP er oft sagður samanstanda af gagnalagi og flutningslagi. Gagnalagið er safn reglna um hvernig skilaboð eru sniðin (MCP-beiðnir eru sendar á JSON-RPC 2.0). Flutningslagið ber þessi skilaboð og notar streymandi HTTP fyrir ytri tengingar.

Hvað er MCP-arkitektúr?

MCP-arkitektúr er þjónarammi sem útfærir Model Context Protocol, opinn staðal til að tengja gervigreindarlíkön við verkfæri, tilföng á borð við gagnagrunna og kvaðningar sem auka við inntakssamhengið. Þetta kallast einu nafni „grunneiningar“. Í grunninn gerir MCP-arkitektúr mállíkönum (LLM) kleift að finna hvaða verkfæri eru í boði og keyra verkflæði, allt án þess að krefjast reglulegra uppfærslna hjá biðlaranum.

Frá því að Anthropic kynnti MCP-arkitektúr til sögunnar hefur hann orðið útbreiddur í verkflæðum gervigreindar. Það er að miklu leyti vegna þess að hann leysir af hólmi kerfi sem krefjast meira viðhalds, svo sem kerfi sem byggð eru á mörgum API-tengingum, án þess að fórna afköstum. Þar sem öll tiltæk virkni er að baki MCP-þjóninum þarf aðeins eina tengingu og uppfærslur og viðbætur verða strax aðgengilegar biðlaraforritinu.

Íhlutir MCP-arkitektúrs: hýslar, biðlarar og þjónar

MCP veitir mállíkönum leið til að finna og kalla á þau verkfæri, kvaðningar og tilföng sem þeim standa til boða, annaðhvort á staðbundnu kerfi hýsilforritsins eða frá ytri þjónustuveitanda.

Hvað verkfæri varðar, sem veita aðgang að ytri virkni, felst uppgötvun í því að hýsillinn sendir kall í tools/list til MCP-þjónsins til að finna hvaða verkfæri eru í boði. Mállíkanið (eða í sumum tilvikum hýsillinn) getur síðan lesið lýsingar tiltækra verkfæra og beðið um þau eftir þörfum. Kvaðningar og tilföng nota svipað ferli.

Þetta er ólíkt sérsniðnum API-byggðum arkitektúr, sem hefur verið viðmiðið í hugbúnaðarþróun, þar sem kalla þurfti á virkni utan forritsins um sérstakar tengingar með nákvæmlega sniðnum beiðnum.

Hýsill

Hýsilforritið er miðlægur samhæfingarvettvangur og tengist mállíkani. Þekkt verkfæri á borð við Perplexity og Claude Desktop geta gegnt hlutverki hýsla innan MCP-kerfis.

Í einföldu verkflæði spyr notandinn spurningar í gegnum spjallviðmótið. Stýrieining hýsilsins bætir síðan samhengi við spurninguna og segir mállíkaninu hvaða MCP-grunneiningar eru í boði ásamt lýsingu á getu þeirra.

Biðlari

Biðlarinn er hugbúnaðaríhlutur í gervigreindarforritinu. MCP býður upp á staðlað viðmót sem biðlarinn notar til að eiga samskipti við innri og ytri MCP-þjóna samkvæmt fyrirmælum hýsilsins eða mállíkansins. Hlutverk hans er að koma á tengingu, sníða JSON-RPC-skilaboð, senda beiðnir og taka við svörum.

Hugtökin „MCP-hýsill“ og „MCP-biðlari“ eru stundum notuð jöfnum höndum. Aðgreiningin er þó gagnleg, því hýsill á borð við Perplexity gæti stýrt mörgum MCP-biðlurum samtímis. Flókið gervigreindarverkflæði gæti krafist aðgangs að tugum eða jafnvel hundruðum aðskildra MCP-þjóna og hver þeirra notar sérstaka tengingu.

Þjónn

Þjónninn býður fram öll þau verkfæri sem gervigreindarlausnin getur notað. Frá sjónarhóli arkitektúrs túlkar MCP-þjónninn beiðnina sem berst og tengist, þegar þörf krefur, þeim grunneiningum sem beðið er um.

MCP-þjónar geta veitt aðgang að þremur flokkum grunneininga:

  • Verkfæri: Þetta er í raun ytri hugbúnaðarvirkni. Ef litið er til hefðbundinnar API-nálgunar gæti vefgreiningarforrit sótt gögn með sniðinni beiðni til ytri þjóns. Í MCP-arkitektúr er öll virkni þriðja aðila frá þjónustuveitanda aðgengileg um eina tengingu og beiðnir eru búnar til samkvæmt stöðluðum sniðreglum.
  • Tilföng: Tilföng eru gagnalindir sem veita skrifvarið samhengi. Gagnagrunnsskemu eru gott dæmi. MCP-þjónninn býður fram hinar ýmsu upplýsingalindir sem eru hýslinum aðgengilegar. Ef hýsillinn sendir fyrirspurn í gagnagrunninn, til dæmis með SQL-leit sem mállíkan býr til, telst það verkfærabeiðni.
  • Kvaðningar: Þetta eru endurnýtanleg kvaðningasniðmát sem hjálpa mállíkönum að leysa tiltekin verkefni. Notandi eða hýsill kallar á kvaðningu í stað verkfæris vegna þess að tilbúin fyrirmæli þarf til að ljúka verkefninu. Oft eru forstillt verkefni í hýsilforriti, svo sem valkostirnir „yfirfara kóða“ eða „greina gögn“, vistuð sem kvaðningar sem notandinn getur valið.

Rétt er líka að benda á að MCP og API eru ekki tækni sem útilokar hvor aðra. MCP-þjónninn getur boðið fram API-köll sem eru aðgengileg sem svar við uppgötvunarbeiðni. Lykilatriðið er að það er í höndum MCP-þjónustuveitandans að viðhalda þeim, ekki biðlarans.

Hvað er gagnalagið í MCP-arkitektúr?

Gagnalagið í MCP-arkitektúr er safn reglna sem skilgreina hvernig beiðnir, svör og tilkynningar eru sniðin. Staðlaða málið fyrir skilaboð er JSON-RPC.

Allur MCP-arkitektúr fylgir grunnferli sem felst í (1) frumstillingu og uppgötvun af hálfu hýsilsins, (2) svari frá MCP-þjóninum og (3) kalli frá hýslinum (sem mállíkanið ákveður stundum), þar sem hvert stig samsvarar sérstökum JSON-skilaboðum.

Skoðum hvernig uppgötvun verkfæra virkar með tveimur dæmum (þau gætu einnig átt við um tilföng eða kvaðningar):

  • Finna verkfæri áður en mállíkanið býr til svar: Hýsillinn ræsir MCP-biðlarann, sem sendir beiðni um tools/list (lista MCP-þjónsins yfir tiltæk verkfæri). Mállíkanið fer yfir listann meðan á myndun svarsins stendur og ákvarðar hvort þörf sé á tilteknu verkfæri, tilfangi eða kvaðningu.
  • Gefa mállíkaninu kost á að framkvæma leit: Í kerfi með gervigreindarfulltrúum bætir hýsillinn uppgötvunarvalkosti, svo sem search-tools, við samhengisinntakið og mállíkanið getur beðið um leit ef þörf krefur.

Verkfæri, sem eru að mestu leyti ytri forritavirkni, eru yfirleitt valin af mállíkaninu eða hýslinum. Tilföng og kvaðningar eru hins vegar oftast sótt að beiðni notandans eða af hýslinum.

Svona lítur beiðni um tools/list til MCP-þjóns út frá ímynduðu glósuforriti:

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

Í þessu dæmi auðkennir “id”:101 beiðnina með auðkenni svo biðlarinn geti parað saman svör, og reiturinn “params” inniheldur viðbótarupplýsingar um biðlarann, svo sem heiti biðlarans (notes-app-client) og getu hans.

Í svari sínu skilar MCP-þjónninn skilgreiningum verkfæra, sem innihalda heiti tiltækra verkfæra og tengdar upplýsingar. Listinn gæti til dæmis innihaldið verkfærið add-task sem gerir glósuforritinu kleift að búa til verkefni í tengdu verkefnastjórnunar- eða dagatalsforriti og gefa hverju verkefni titil og forgang.

Svona gæti beiðni litið út:

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

Reiturinn “method” segir MCP-þjóninum að um verkfærakall sé að ræða, “name” tilgreinir hvaða verkfæri á að kalla á og “arguments” veitir nauðsynleg inntaksgildi.

Hvað er flutningslagið í MCP-arkitektúr?

Ef gagnalagið er hvað tengingarinnar milli biðlara og MCP-þjóns, þá er flutningslagið hvernig. Það skilgreinir hvernig skilaboð ferðast: tiltekna rás og þær reglur sem stýra því hvernig beiðnir og svör eru afhent.

MCP hefur tvær flutningsleiðir:

  • Staðalinntak/-úttak: Þetta er notað þegar MCP-þjónninn keyrir í sama staðbundna umhverfi og hýsilforritið. Biðlarinn skrifar JSON-beiðnina í staðalinntak þjónsins. Þjónninn les hana, framkvæmir umbeðna aðgerð og skrifar svarið í staðalúttak.
  • Streymanlegt HTTP: Þegar MCP-þjónninn keyrir utan hýsilforritsins sendir MCP-biðlarinn beiðnir til þjónsins með HTTP POST. Þjónninn svarar annaðhvort með stökum JSON-skilaboðum eða með Server-Sent Events (SSE)-straumi, viðvarandi „hlustunarrás“ sem gerir honum kleift að skila mörgum skilaboðum með tímanum.

Hvað er MCP-fjölleigjendaarkitektúr?

MCP-fjölleigjendaarkitektúr er tegund útfærslu sem getur þjónað mörgum notendum (leigjendum) samtímis.

Hér getur leigjandi verið einstaklingur, hópur einstaklinga eða stofnun. Útfærslan getur falist í því að keyra sérstakan MCP-þjón fyrir hvern leigjanda, veita aðgang að einum sameiginlegum þjóni eða setja hóp þjóna á bak við miðlæga gátt. Þegar gátt er notuð beinir hún beiðnum á rétta endapunkta út frá auðkenni notandans eða eðli beiðninnar.

Þetta fyrirkomulag byggir á sömu grunnreglu og hefðbundinn MCP-arkitektúr, en beiðnir einstakra notenda keyra í eigin vinnusvæði (jafnvel þótt það feli í sér sameiginleg tilföng) og eru auðkenndar sérstaklega. Þetta er algengt í fyrirtækjaumhverfi og sameiginleg tilföng eru oft valin vegna þess að það yrði að óþörfu kostnaðarsamt að keyra marga MCP-þjóna.

Skýringarmynd af MCP-arkitektúr: Yfirferð skref fyrir skref

Hvernig lítur MCP-beiðni frá upphafi til enda út í raun? Meginstigin eru átta og hvert þeirra tengist sérstökum íhlut arkitektúrsins.

Svona lítur MCP-verkfærakall út í raun, með fyrra dæminu um glósuforrit sem er tengt verkefnastjórnunarþjónustu:

  1. Uppgötvun verkfæra: Glósuforritið (hýsillinn) notar MCP-biðlara sinn til að biðja um tiltæk verkfæri þjónsins með beiðni um tools/list. Þjónninn skilar heitum þeirra, lýsingum og væntanlegum inntaksgildum, þar á meðal fyrir verkfærið add-task. Þetta getur gerst áður en þú sendir inn kvaðningu.
  2. Inntak notanda: Þú sendir beiðni til glósuforritsins, sem byggir á mállíkani, í gegnum spjallmenni forritsins, til dæmis: „Búðu til verkefni í dagatalinu mínu um að yfirfara nýju drögin mín með miðlungsforgangi.“
  3. Úrvinnsla líkans: Hýsillinn sendir beiðnina þína og viðeigandi verkfæraskilgreiningar til mállíkansins.
  4. Val á verkfæri: Mállíkanið býr til skipulagða verkfærabeiðni sem tilgreinir verkfærið og inntaksgildi þess: add-task með title: Yfirfara drögin og priority: Medium. Hýsillinn kannar hvort aðgerðin sé leyfð og sendir beiðnina áfram til MCP-biðlarans, sem sendir JSON-RPC-skilaboð.
  5. Beiðni: MCP-biðlarinn sendir beiðni um tools/call til MCP-þjóns síns.
  6. Keyrsla verkfæris: MCP-þjónninn kallar á API verkefnastjórnunarforritsins til að búa til nýtt verkefni með tilgreindum titli og forgangi.
  7. Niðurstöðu skilað: Þjónninn sendir niðurstöðuna aftur til MCP-biðlarans, sem sendir hana áfram til hýsilsins. Hýsillinn bætir henni við þær upplýsingar sem mállíkaninu eru veittar.
  8. Myndun svars: Mállíkanið notar niðurstöðuna til að búa til svar fyrir notandann, til dæmis: „Ég hef búið til verkefni um að yfirfara drögin með miðlungsforgangi.“

Hvernig er MCP-arkitektúr frábrugðinn hefðbundnum API-arkitektúr?

MCP og hefðbundnum API-arkitektúr er oft ruglað saman, en þetta er tækni sem bætir hvor aðra upp. MCP var sérstaklega hannað fyrir gervigreindarforrit. Það yfirstígur þá miklu viðhaldsbyrði sem fylgir því að útfæra og stjórna mörgum harðkóðuðum API-tengingum.

Með því að veita hýsilforriti eina tengingu fyrir hvern virkniveitanda eða hvert innra tilfang hjálpar MCP til við að leysa vandann sem fylgir uppblásnu samhengisinntaki (þar sem öll API eru talin upp) eða takmörkuðum API-byggðum forritaskriftum.

Þess í stað getur MCP boðið fram API (eða öllu heldur virknina sem kallar á API) sem hluta af verkfæralista sínum. Í hvert sinn sem þjónustuveitandi uppfærir forritið sitt og nýtt API kemur til, eða ef skjölun breytist, uppfærir hann einfaldlega MCP-þjóninn. Engar kóðabreytingar þarf að gera hjá hýsilforritinu.

Er MCP-arkitektúr öruggur?

Öryggi MCP hefur verið mikið til umræðu frá því að það kom fram. Þótt MCP sé almennt talið örugg tækni eru nokkrir öryggisáhættuþættir til staðar og margir þeirra eru meira áberandi í flóknum útfærslum á arkitektúrnum.

MCP-arkitektúr hefur eftirfarandi mögulega veikleika:

  • Innspýting kvaðninga: Notandi setur illgjarna kvaðningu inn í ytri gögn sem gervigreindarlíkanið mistúlkar sem fyrirmæli.
  • Of víðtækar aðgangsheimildir: MCP-þjónar geta hugsanlega veitt gervigreindarlíkani aðgang að miklum fjölda verkfæra, sem getur aukið hættuna á öryggisvandamálum (áhrifasvæðið).
  • Gagnaleki fyrir slysni: Illa stilltar útfærslur geta leitt til þess að viðkvæmar upplýsingar, eins og API-lyklar eða aðgangsupplýsingar að gagnagrunnum, berist til mállíkans.
  • Misnotkun staðbundinna kerfa: Staðbundnir MCP-þjónar eru jafn berskjaldaðir fyrir vandamálum í staðbundnum kerfum, eins og illgjörnum skriftum, og hvaða önnur forrit sem er, með þeim viðbótarvanda að þeir geta haft skaðleg keðjuáhrif á gervigreindarkerfi sem byggja á gervigreindarfulltrúum.

Ekkert þessara vandamála er óyfirstíganlegt. Oft þarf ekki annað en viðurkenndar ráðstafanir til að tryggja öryggi kerfisins. Ráðstafanir á borð við mannlega aðkomu í ferlinu, strangar stýringar á viðkvæmum gögnum og varnir gegn árásum á þjóna eru allt algengar starfsvenjur.

Hvað er fram undan hjá MCP-arkitektúr?

MCP hefur reynst gagnlegur og vinsæll opinn staðall fyrir forritara. Hann yfirstígur mörg vandamál harðkóðaðra API í forritum sem byggja á mállíkönum og dregur verulega úr kóðunarbyrði forritara.

Undirliggjandi hýsla- og þjónaarkitektúr MCP mun nær örugglega haldast óbreyttur í framtíðinni. Nýjungar framtíðarinnar munu snúast um háþróaða getu gervigreindarfulltrúa í fjölþrepa verkflæðum.

Auk þess verður þörf á öflugri öryggisvörnum eftir því sem slík virkni gervigreindarfulltrúa er innleidd, og á skalanlegum arkitektúr, einkum í flutningslaginu, eftir því sem gervigreindarkerfi verða umfangsmeiri og flóknari.