Breaking Down Model Context Protocol (MCP)

Arkitektura ng Client-Server ng MCP

Ang MCP ay binuo sa isang client-server na modelo na bumubuo sa kung paano kumukuha at nakikipag-ugnayan ang mga modelo ng AI sa mga external na data source.

• Ang mga kliyente ng MCP ay mga ahente ng AI, application, o anumang system na humihiling ng structured na data.
• Ang mga MCP server ay kumikilos bilang mga tagapamagitan, kumukuha ng data mula sa iba't ibang API, database, o enterprise system at ibinabalik ito sa pare-parehong format.

Sa halip na ang mga modelo ng AI ay gumagawa ng mga direktang kahilingan sa API, pinangangasiwaan ng mga server ng MCP ang pagiging kumplikado ng pagpapatunay, pagkuha ng data, at normalisasyon ng tugon. Nangangahulugan ito na hindi na kailangan ng mga ahente ng AI na pamahalaan ang maraming kredensyal ng API, iba't ibang format ng kahilingan, o hindi magkatugmang mga istruktura ng pagtugon.

Halimbawa, kung ang isang modelo ng AI ay kailangang kumuha ng impormasyon mula sa maraming serbisyo tulad ng Google Drive, Slack , at isang database, hindi nito itinatanong ang bawat API nang hiwalay. Nagpapadala ito ng iisang structured na kahilingan sa isang MCP server, na nagpoproseso ng kahilingan, nangangalap ng data mula sa mga kinakailangang source, at nagbabalik ng maayos na tugon.

Lifecycle ng Kahilingan-Tugon ng MCP

Ang isang tipikal na pakikipag-ugnayan ng MCP ay sumusunod sa isang structured na ikot ng pagtugon sa kahilingan na nag-aalis ng mga paulit-ulit na tawag sa API at nagsa-standardize ng pagkuha ng data.

1. Nagpapadala ang ahente ng AI ng nakabalangkas na kahilingan sa MCP server. Sa halip na gumawa ng mga indibidwal na kahilingan sa API, tinutukoy ng ahente kung anong data ang kailangan nito sa isang pare-parehong format.

{
  "request_id": "xyz-987",
  "queries": [
    {
      "source": "github",
      "action": "get_recent_commits",
      "repo": "company/project"
    },
    {
      "source": "slack",
      "action": "fetch_unread_messages",
      "channel": "engineering"
    }
  ]
}

‍

2. Pinoproseso ng MCP server ang kahilingan sa pamamagitan ng pagpapatunay sa pagpapatunay, pagsuri ng mga pahintulot, at pagtukoy kung aling mga external na system ang itatanong.

3. Ang mga query ay isinasagawa nang magkatulad, ibig sabihin, ang data mula sa maraming serbisyo ay kinukuha nang sabay-sabay sa halip na sunud-sunod, na binabawasan ang pangkalahatang latency.

4. Ang mga tugon mula sa iba't ibang mapagkukunan ay na-standardize sa isang structured na format na madaling maproseso ng mga modelo ng AI.

{
  "github": {
    "recent_commits": [
      {
        "author": "Alice",
        "message": "Refactored AI pipeline",
        "timestamp": "2024-03-12T10:15:00Z"
      }
    ]
  },
  "slack": {
    "unread_messages": [
      {
        "user": "Bob",
        "text": "Hey, can you review the PR?",
        "timestamp": "2024-03-12T09:45:00Z"
      }
    ]
  }
}

Hindi tulad ng mga hilaw na tugon ng API na nangangailangan ng manual na pag-parse, tinitiyak ng MCP na ang lahat ng nakuhang data ay sumusunod sa isang predictable, structured na format, na ginagawang mas madali para sa mga modelo ng AI na maunawaan at magamit.

Pagpapatupad ng Query at Pagsasama-sama ng Tugon

Ang MCP ay idinisenyo upang i-optimize kung paano nakikipag-ugnayan ang mga modelo ng AI sa mga panlabas na system sa pamamagitan ng pagpapakilala ng isang structured na proseso ng pagpapatupad.

1. Tinitiyak ng pagpapatunay ng kahilingan na ang modelo ng AI ay may mga kinakailangang pahintulot bago makuha ang anumang data.
2. Tinutukoy ng pagruruta ng query kung aling mga panlabas na serbisyo ang kailangang i-access.
3. Kinukuha ng parallel execution ang data mula sa maraming pinagmulan nang sabay-sabay, na binabawasan ang mga pagkaantala na dulot ng mga sunud-sunod na kahilingan sa API.
4. Pinagsasama-sama ng pagsasama-sama ng tugon ang nakabalangkas na data sa iisang tugon, na inaalis ang pangangailangan para sa mga modelo ng AI na manu-manong magproseso ng maramihang mga raw na output ng API.

Sa pamamagitan ng pagbabawas ng mga paulit-ulit na kahilingan, pag-normalize ng mga tugon, at pangangasiwa sa pagpapatotoo sa gitnang paraan, inaalis ng MCP ang hindi kinakailangang overhead ng API at ginagawang mas scalable ang automation na hinimok ng AI.

Mga Hamon sa Pagpapatunay

Ang isa sa mga pinakamalaking pangako ng MCP ay gawing hindi gaanong umaasa ang mga ahente ng AI sa mga pagsasama-samang partikular sa API. Gayunpaman, ang pagpapatunay (AuthN) ay nananatiling isang malaking hamon.

Ngayon, ang API authentication ay isang pira-pirasong proseso—ang ilang mga serbisyo ay gumagamit ng OAuth, ang iba ay umaasa sa mga API key, at ang ilan ay nangangailangan ng session-based na authentication. Dahil sa hindi pagkakapare-parehong ito, nauubos ng oras ang onboarding ng mga bagong API, at ang MCP ay kasalukuyang walang built-in na balangkas ng pagpapatotoo upang mahawakan ang pagiging kumplikadong ito.

Nangangailangan pa rin ang MCP ng ilang panlabas na mekanismo para ma-authenticate ang mga kahilingan sa API, na nangangahulugang ang mga ahente ng AI na gumagamit ng MCP ay dapat umasa sa mga karagdagang solusyon, gaya ng Composito, upang pamahalaan ang mga kredensyal ng API. Ang pagpapatotoo ay nasa roadmap para sa MCP, ngunit hanggang sa ganap itong maipatupad, ang mga developer ay mangangailangan pa rin ng mga workaround upang mahawakan ang pagpapatotoo sa maraming system.

Hindi Malinaw na Pamamahala ng Pagkakakilanlan

Ang isa pang hindi nalutas na isyu ay ang pamamahala ng pagkakakilanlan—sino ang nakikita ng isang external na system kapag humiling ang isang ahente ng AI sa pamamagitan ng MCP?

Halimbawa, kung nagtatanong ang isang AI assistant Slack sa pamamagitan ng MCP, dapat Slack kilalanin ang kahilingan na nagmula sa:

• Ang end user? (Ibig sabihin, kumikilos ang AI sa ngalan ng isang tao.)
• Ang AI agent mismo? (Na mangangailangan Slack upang pangasiwaan ang mga pakikipag-ugnayan na nakabatay sa AI nang hiwalay.)
• Isang nakabahaging system account? (Na maaaring magpakilala ng mga alalahanin sa seguridad at kontrol sa pag-access.)

Ang isyung ito ay mas kumplikado sa mga kapaligiran ng enterprise, kung saan tinutukoy ng mga patakaran sa kontrol sa pag-access kung sino ang maaaring kunin kung anong data. Kung walang malinaw na pagmamapa ng pagkakakilanlan, maaaring harapin ng mga pagsasama ng MCP ang pinaghihigpitang pag-access, mga panganib sa seguridad, o mga hindi pagkakapare-pareho sa iba't ibang platform.

Ang suporta sa OAuth ay pinlano para sa MCP, na maaaring makatulong na linawin ang pangangasiwa ng pagkakakilanlan, ngunit hanggang sa ganap itong maipatupad, maaaring mahirapan ang mga modelo ng AI sa pag-access na nakabatay sa pahintulot sa mga serbisyo ng third-party. 

Lock-in ng Vendor at Pagkapira-piraso ng Ecosystem

Ang MCP ay kasalukuyang isang Anthropic -pinamumunuan ang inisyatiba, na nagtataas ng mga tanong tungkol sa pangmatagalang standardisasyon nito. Habang umuunlad ang mga AI ecosystem, malaki ang posibilidad na ang iba pang pangunahing manlalaro—gaya ng OpenAI o DeepSeek—ay bubuo ng sarili nilang mga protocol para sa mga pakikipag-ugnayan ng AI-to-system.

Kung lalabas ang maraming magkakakumpitensyang pamantayan, maaaring mahati ang industriya, na pumipilit sa mga developer na pumili sa pagitan ng iba't ibang mga hindi tugmang diskarte. Kung ang MCP ay nananatiling nangingibabaw na diskarte o naging isa lamang sa ilang mapagkumpitensyang opsyon ay nananatiling alamin.

1. Maaari bang i-configure ang MCP upang sumunod sa mga pamantayan ng SOC 2, HIPAA, o GDPR?

Oo, ngunit depende ito sa kung paano mo ito ipapatupad at i-host. Dahil ang MCP ay isang protocol lamang, kakailanganin mong tiyaking ligtas na pinangangasiwaan ng iyong MCP server ang data, na may pag-encrypt, mga kontrol sa pag-access, at pag-log ng audit, upang matugunan ang mga kinakailangan sa pagsunod.

2. Paano tinutukoy ng mga ahente ng AI kung kailan magti-trigger ng MCP kumpara sa pag-asa sa internal memory?

Kadalasan, umaasa sila sa agarang lohika o mga custom na panuntunan, tulad ng pagsuri kung ang impormasyon ay maaaring luma na o hindi available sa loob. Kung ang isang tanong ay nangangailangan ng bago o panlabas na data, iyon ay kapag ang AI agent ay tumawag sa MCP upang kunin ito.

3. Tugma ba ang MCP sa mga kasalukuyang arkitektura ng RAG (retrieval-augmented generation)?

Oo. Maaaring isaksak mismo ng MCP sa isang RAG setup sa pamamagitan ng pagkilos bilang structured data retriever, na pinapalitan ang mga manual na API call ng mas pare-pareho at streamline na diskarte.

4. Anong mga uri ng mga daloy ng trabaho sa negosyo ang higit na nakikinabang sa pagsasama ng MCP?

Anumang bagay na kinasasangkutan ng maraming tool o data silo, tulad ng suporta sa customer, panloob na IT ops, pagpapagana sa pagbebenta, o pamamahala ng kaalaman, ay maaaring makinabang nang malaki mula sa pagpapasimple ng MCP kung paano nakukuha ng mga ahente ng AI ang impormasyong kailangan nila.

5. Paano maaaring gamitin ng mga startup ang MCP nang hindi ino-overhaul ang kanilang buong arkitektura ng data?

Magsimula sa maliit. Maaari mong gamitin muna ang MCP para sa isa o dalawang pangunahing pagsasama, tulad ng Slack o isang CRM, pagkatapos ay palawakin kung kinakailangan. Dahil inaalis nito ang karamihan sa magulo na gawain ng API, medyo magaan ang pag-angat nito sa simula.