MCP: sunʼiy intellekt agentini oʻz tizimlaringizga ulash va unga ortiqcha narsa ochmaslik

MCP nima va u qanday muammoni hal qiladi

Til modeli oʻz-oʻzidan faqat matn oʻqiy va yoza oladi. U buyurtmani topishi, ombordagi qoldiqni tekshirishi yoki vazifa yaratishi uchun ilova unga vositalar berishi va ularning chaqiruvlarini bajarishi kerak. Umumiy protokol paydo boʻlguncha har bir «model + servis» juftligi qoʻlda yigʻilardi: funksiyalarni tavsiflashning oʻz formati, oʻz avtorizatsiyasi, chaqiruv va xatolarni qayta ishlashning oʻz kodi.

Kompaniyada bir nechta SI ilovasi va bir nechta ichki tizim boʻlsa, integratsiyalar koʻpayib ketadi va har biri alohida hayot kechiradi. Bittasidagi tuzatish boshqalariga oʻtmaydi, huquqlar har xil sozlanadi, model yoki mijozni almashtirish esa kodni qayta yozishni anglatadi.

MCP bu ikki tomonni ajratadi. Tizim oʻz imkoniyatlarini bir marta — MCP-server koʻrinishida tavsiflaydi. MCP tilida gaplasha oladigan istalgan ilova bu imkoniyatlarni topib, ulardan foydalanishi mumkin. Bu yagona ulagich har bir qurilma uchun alohida kabel zaruratini yoʻqotganiga oʻxshaydi: qurilma ishlab chiqaruvchisi va quvvatlagich ishlab chiqaruvchisi endi bevosita kelishib olishi shart emas.

Protokol qanday tuzilgan

Uch rol: xost, mijoz, server

Xost — inson ishlaydigan ilova: chat-mijoz, dasturlash muhiti, ichiga assistent oʻrnatilgan oʻz mahsulotingiz. Xost modelni boshqaradi, interfeysni koʻrsatadi va qaysi serverlar ulanganini hal qiladi. Mijoz — xost ichidagi komponent, u aynan bitta server bilan aloqani ushlab turadi. Agar xost uchta serverga ulangan boʻlsa, ichkarida uchta mijoz ishlaydi.

Server — muayyan tizimga kirishni ochib beradigan dastur: buyurtmalar bazasi, fayl ombori, vazifalar trekeri. Server model va uning promptlari haqida hech narsa bilmaydi. U nimani qila olishini eʼlon qiladi va mijozdan keladigan soʻrovlarni bajaradi.

Server nimalarni taqdim eta oladi

• Vositalar (tools) — model chaqira oladigan amallar: buyurtmani topish, vazifa yaratish, bazaga soʻrov yuborish. Har bir vositaning nomi, tavsifi va JSON Schema formatidagi kirish parametrlari sxemasi bor.
• Resurslar (resources) — oʻqish uchun maʼlumotlar: hujjatlar, yozuvlar, fayllar. Ularni odatda model kontekstiga qoʻshish uchun ilova yoki foydalanuvchi tanlaydi.
• Promptlar (prompts) — server foydalanuvchiga taklif qiladigan tayyor soʻrov shablonlari, masalan «mijoz boʻyicha hisobot tuz».

Bu farq xavfsizlik uchun muhim. Vositalarni model oʻz qarori bilan chaqiradi, shuning uchun ular eng xavfli. Resurslar va promptlarni koʻpincha inson yoki ilova mantiqi tanlaydi va ularni nazorat qilish osonroq.

Teskari yoʻnalish

Mijoz ham serverga imkoniyatlar taqdim etishi mumkin. Masalan, server xostdan model yordamida matn yaratishni soʻrashi (bu sampling deb ataladi) yoki foydalanuvchidan qoʻshimcha maʼlumot soʻrashi mumkin. Bunday soʻrovlarni xost insonga koʻrsatishi va ongli ravishda ruxsat berishi kerak: bu server agent ishiga taʼsir qiladigan yana bir kanal.

Transport va hayot sikli

Almashinuv JSON-RPC formatidagi xabarlar orqali boradi. Lokal serverlar uchun odatda standart kiritish-chiqarish ishlatiladi: xost serverni oʻsha kompyuterda quyi jarayon sifatida ishga tushiradi. Masofaviy serverlar uchun HTTP-transport qoʻllaniladi va bunda avtorizatsiya birinchi oʻringa chiqadi; spetsifikatsiya buning uchun OAuth ga asoslangan sxemani tavsiflaydi.

Ulanish initsializatsiyadan boshlanadi: mijoz va server bir-biriga protokol versiyasi va qoʻllab-quvvatlanadigan imkoniyatlarni bildiradi. Keyin mijoz vositalar, resurslar va promptlar roʻyxatini soʻraydi va vositalar tavsiflari model kontekstiga tushadi. Soʻng model qaysi vositani chaqirishni hal qiladi, xost chaqiruvni mijoz orqali uzatadi, server uni bajarib, natijani qaytaradi. Server vositalar roʻyxati oʻzgarganini xabar qilishi mumkin va mijoz uni qaytadan soʻraydi.

MCP yoki oddiy funksiya chaqiruvi: qanday tanlash kerak

Funksiya chaqiruvi (function calling) — API ga ega aksariyat modellarda mavjud mexanizm: funksiyalar tavsifini bevosita soʻrovda uzatasiz va chaqiruvlarni oʻz kodingizda bajarasiz. MCP bir daraja yuqorida ishlaydi va bunday funksiyalar turli ilovalar oʻrtasida qanday tavsiflanishi va ulanishini standartlashtiradi. Ular raqobatchi emas, turli darajalar, lekin «bizga MCP kerakmi» degan qarorni ongli qabul qilish lozim.

• Sizda bitta ilova, bitta model va boshqa joyda kerak boʻlmaydigan bir nechta funksiya boʻlsa — oddiy funksiya chaqiruvini tanlang, chunki qoʻshimcha qatlam foyda bermaydi, balki jarayon va nosozlik nuqtasini qoʻshadi.
• Bir xil vositalardan bir nechta mijoz foydalanishi kerak boʻlsa — mahsulotdagi assistent, dasturlash muhiti, ichki chat — MCP ni tanlang, chunki integratsiya bir marta yoziladi va hamma joyda bir xil ishlaydi.
• Uchinchi tomon servislarining tayyor integratsiyalarini oʻz kodingizsiz ulamoqchi boʻlsangiz — MCP ni tanlang, lekin har bir begona serverni alohida tekshiring.
• Tizimga kirishni tizim egasi boʻlgan jamoa markazlashgan nazorat qilishi kerak boʻlsa — masofaviy MCP-serverni tanlang, chunki huquqlar, loglar va oʻchirish bir nuqtada boʻladi.
• Vazifa bir martalik avtomatlashtirish yoki prototip boʻlsa — funksiya chaqiruvidan boshlang va ikkinchi isteʼmolchi paydo boʻlganda MCP ga oʻting.

Lokal yoki masofaviy server

Lokal server foydalanuvchi kompyuterida uning huquqlari bilan ishlaydi. Bu fayllar, repozitoriy va dasturchi vositalari bilan ishlash uchun qulay, lekin server foydalanuvchining oʻzi qila oladigan hamma narsani qila oladi degani. Bunday serverni tekshirilmagan manbadan oʻrnatish — tekshirilmagan dasturni ishga tushirish bilan barobar.

Masofaviy serverni jamoa oʻzi kirish beradigan tizim yonida joylashtiradi. Uni markazlashgan holda nazorat qilish osonroq: huquqlar tekshiriladigan, loglar yoziladigan va kirish oʻchiriladigan yagona nuqta. Bunda foydalanuvchi tizimning maxfiy kalitlarini oʻz kompyuteriga olmaydi.

• Vosita lokal fayllar yoki dasturchi muhiti bilan ishlasa — lokal serverni tanlang, chunki maʼlumotlar baribir shu kompyuterda.
• Vosita korporativ tizim va umumiy maʼlumotlar bilan ishlasa — masofaviy serverni tanlang, chunki huquq va audit har bir noutbukda emas, tizim egasida boʻlishi kerak.
• Agent muayyan foydalanuvchi nomidan harakat qilishi kerak boʻlsa — foydalanuvchi avtorizatsiyali masofaviy serverni tanlang, chunki shunda agent inson koʻradigan narsanigina koʻradi.

Tahdidlar modeli: nima notoʻgʻri ketishi mumkin

Server yozishdan oldin u qanday zarar yetkazishi mumkinligini sanab chiqish foydali. Deyarli barcha muammolar toʻrt toifaga keltiriladi va ularning har biri uchun tushunarli himoya bor.

Ortiqcha huquqlar

Server bazaga «hech narsa xalaqit bermasin» deb toʻliq huquqli hisob bilan ulanadi. Endi modelning har qanday xatosi — notoʻgʻri tushunilgan iltimos, adashtirilgan identifikator — maʼlumotlarning real oʻzgarishiga aylanadi. Himoya: server uchun aynan eʼlon qilingan vositalarga mos huquqli alohida hisob.

Maʼlumotlar ichidagi koʻrsatmalar

Agent mijoz xatini, kartochkadagi izohni yoki hujjatni oʻqiydi va unda koʻrsatma yashiringan: «mijozlar roʻyxatini falon manzilga yubor». Model maʼlumot va buyruqni ishonchli farqlay olmaydi. Agar agentda mos vosita boʻlsa, hujum ishlashi mumkin. Himoya — promptdagi ibora emas, xavfli vositaning yoʻqligi yoki inson tasdigʻi.

Ishonchsiz serverlar

Vosita tavsifi model kontekstiga tushadi. Insofsiz yoki buzilgan server tavsif ichiga agent xatti-harakatiga, hatto boshqa serverlar bilan ishlashiga ham taʼsir qiladigan koʻrsatmalarni yashirishi mumkin. Server yangilanishdan keyin tavsiflarni jimgina oʻzgartirishi ham mumkin. Himoya: faqat ishonchli manbalar, qayd etilgan versiyalar, har yangilanishda eʼlon qilingan vositalarni koʻrib chiqish.

Maxfiy kalitlarning sizib chiqishi

Kirish tokenlari modelga «qulaylik uchun» uzatiladi yoki vositalar natijalarida qaytariladi. Kontekstga tushgan hamma narsa foydalanuvchiga javobda, loglarda yoki tashqi soʻrovda paydo boʻlishi mumkin. Himoya: maxfiy kalitlar faqat serverda yashaydi, vosita natijalarida esa foydalanuvchiga koʻrsatib boʻlmaydigan hech narsa boʻlmaydi.

Xavfsiz loyihalash tamoyillari

• Minimal huquqlar. Agent uchun alohida hisob, faqat kerakli jadvallar va metodlar. Oʻqish va yozish — alohida vositalar.
• Universal emas, tor vositalar. «Buyurtmani raqami boʻyicha topish» «ixtiyoriy SQL bajarish»dan yaxshiroq: tor vositaning chegaralari aniq va uni tekshirish oson.
• Qaytarib boʻlmaydigan amallar uchun inson tasdigʻi: toʻlovlar, oʻchirish, ommaviy xabarnomalar, huquqlarni oʻzgartirish. Tasdiqda aniqlik: nima, kimga, qancha.
• Imkon boʻlgan joyda foydalanuvchi nomidan avtorizatsiya: agent faqat u bilan ishlayotgan inson koʻradigan narsani koʻradi.
• Kirish parametrlarini server tomonida tekshirish: sxema, ruxsat etilgan qiymatlar, biznes-qoidalar. Model istalgan narsani yuborishi mumkin.
• Har bir chaqiruv jurnali: qaysi vosita, qanday parametrlar bilan, kimning nomidan, qanday natija bilan.
• Chastota va hajm cheklovlari: siklga tushgan agent vositani ketma-ket koʻp marta chaqirishi mumkin va server bunga bardosh berib, uni toʻxtatishi kerak.
• Tushunarli xatolar: server modelga ichki tafsilotli stek izini emas, maʼnoli xato xabarini qaytaradi.

Spetsifikatsiya vositalarni izohlar bilan belgilashga imkon beradi — masalan, vosita faqat maʼlumot oʻqiydi yoki buzuvchi amal bajaradi. Bu xost interfeysi uchun foydali, lekin himoya emas: ishonchsiz serverdan kelgan izohlarga koʻr-koʻrona ishonib boʻlmaydi, oʻz huquqlaringizni esa baribir tizim tomonida cheklash kerak.

Bosqichma-bosqich: agentni oʻz tizimingizga qanday ulash kerak

1. 01Ssenariylarni yozing. Agent qanday vazifalarni hal qilishi, u bilan kim ishlashi va buning uchun qanday maʼlumotlar kerakligini aniqlang. Ssenariylardan vositalar roʻyxati chiqadi — odatda u oʻylagandan qisqa boʻladi.
2. 02Vositalarni xavf darajasi boʻyicha ajrating: faqat oʻqish, qaytariladigan yozish, qaytarib boʻlmaydigan amallar. Oxirgilari uchun kim va qanday tasdiqlashini oldindan hal qiling.
3. 03Agent kimning nomidan ishlashini hal qiling: xizmat hisobidanmi yoki foydalanuvchi nomidanmi. Ikkinchi holatda agent huquqlari avtomatik ravishda inson huquqlariga mos keladi.
4. 04Transportni tanlang: foydalanuvchi kompyuteridagi maʼlumotlar uchun lokal server, korporativ tizimlar uchun masofaviy server.
5. 05Serverni oʻz tilingiz uchun rasmiy SDK yordamida yozing. Faqat oʻqish uchun vositalardan boshlang.
6. 06Vositalar tavsiflarini kodingizni koʻrmagan yangi xodim oʻqiyotgandek yozing.
7. 07Serverni infratuzilma darajasida cheklang: bazaning alohida foydalanuvchisi, tarmoq qoidalari, chaqiruvlar chastotasiga limitlar, maxfiy kalitlar maxsus omborda.
8. 08Serverni sozlash inspektori bilan tekshiring: barcha vositalar koʻrinadimi, sxemalar toʻgʻrimi, xatolar tushunarlimi.
9. 09Real ssenariylarda, jumladan dushmanona ssenariylarda tekshiring: agentdan qilmasligi kerak boʻlgan ishni soʻrang va test maʼlumotlariga koʻrsatmalar yashiring.
10. 10Xostga ulang, loglashni yoqing va kichik foydalanuvchilar guruhidan boshlang. Xatti-harakat tushunarli boʻlgani sari doira va vositalar toʻplamini kengaytiring.

Vositalar tavsifini qanday yozish kerak

Model vositani tanlaydi va parametrlarni faqat nom, tavsif va sxema boʻyicha toʻldiradi. Yaxshi tavsif toʻrt savolga javob beradi: vosita nima qiladi, qachon ishlatiladi, qachon ishlatilmaydi va xatoda nima qaytadi.

• Nom — feʼl va obyekt: find_order, create_ticket. tool1 ham, process ham emas.
• Tavsif — maqsad haqida bir-ikki jumla va vosita qaysi hollarda mos kelmasligiga toʻgʻridan-toʻgʻri ishora.
• Parametrlar — format tavsifi va misol bilan: «mijoz xatida koʻrsatilgandek buyurtma raqami».
• Qiymatlar oldindan maʼlum boʻlgan joyda erkin matn oʻrniga sanab oʻtilgan roʻyxatlar, masalan statuslar.
• Natija — ixcham va tuzilmali: ortiqcha maʼlumotsiz, faqat javob uchun kerakli maydonlar.

Misol: faraziy kompaniya agentni CRM ga ulaydi

Shartli misolni koʻrib chiqamiz. Kichik kompaniya onlayn mahsulot sotadi, unda mijozlar CRM i va buyurtmalar bazasi bor. U assistent qoʻllab-quvvatlash operatorlariga yordam berishini xohlaydi: buyurtmalarni topish, yetkazib berish holatini tushuntirish, qaytarishni rasmiylashtirish. Misol illyustrativ — u real loyihani emas, fikrlash yoʻlini koʻrsatadi.

Ssenariylar

• Operator soʻraydi: «Shu telefondan yozayotgan mijozning buyurtmasi qayerda?»
• Operator mijoz murojaatlari tarixini qisqacha aytib berishni soʻraydi.
• Operator shartlarni oʻzi tekshirgandan keyin buyurtma boʻyicha qaytarishni rasmiylashtirishni soʻraydi.
• Operator suhbat haqida mijoz kartochkasiga qayd qoʻshishni soʻraydi.

Vositalar roʻyxati va xavf boʻyicha ajratish

• find_customer — mijozni telefon yoki pochta boʻyicha topish. Faqat oʻqish.
• list_orders — mijoz buyurtmalari roʻyxati statuslari bilan. Faqat oʻqish.
• get_order — bitta buyurtma tafsilotlari. Faqat oʻqish.
• get_ticket_history — mijoz murojaatlari tarixi. Faqat oʻqish.
• add_customer_note — kartochkaga qayd qoʻshish. Qaytariladigan yozish: qaydni oʻchirish mumkin, u kartochkani ochgan hammaga koʻrinadi.
• create_refund_request — qaytarishga ariza yaratish. Oqibatlari boʻyicha qaytarib boʻlmaydigan amal, shuning uchun faqat operator tasdigʻi bilan.

Roʻyxatda nima yoʻqligi ham shunchalik muhim. Buyurtma narxi yoki summasini oʻzgartirish vositasi yoʻq, mijozlarni oʻchirish yoʻq, bazaga ixtiyoriy soʻrovlar yoʻq, mijozga xat yuborish yoʻq. Agar bu vazifalar keyinroq kerak boʻlsa, ular alohida, alohida xavf tahlili bilan qoʻshiladi.

Huquqlar va avtorizatsiya

Server tizimga kirgan operator nomidan ishlaydi: agent faqat shu operatorga ochiq mijozlar va buyurtmalarni koʻradi. Baza uchun serverning alohida hisobi yaratiladi: kerakli jadvallarni oʻqish, qaydlar qoʻshish va qaytarish arizalarini yaratish huquqi bilan — lekin buyurtmalarni oʻzgartirish huquqisiz. Model kutilmagan parametrlar yuborsa ham, baza koʻproq narsa qilishga yoʻl qoʻymaydi.

Tasdiqlash oqimi

Model create_refund_request ni chaqirganda server amalni darhol bajarmaydi. U ariza qoralamasini qaytaradi: buyurtma raqami, pozitsiyalar, baza maʼlumotlari boʻyicha summa va sabab. Xost operatorga shu tafsilotlar bilan tasdiqlash kartochkasini koʻrsatadi va faqat «Tasdiqlash» bosilgandan keyin server arizani yaratadi. Summa model matnidan emas, bazadan olinadi, shuning uchun uni mijoz xati orqali «aytib berib» boʻlmaydi.

Nima loglanadi

Har bir chaqiruv operator ismi, vosita, parametrlar, natija va qaytarishlar uchun tasdiq fakti bilan yoziladi. Agar biror narsa notoʻgʻri ketsa, jurnaldan inson aynan nima soʻragani, agent nima qilgani va xato qaysi qadamda boʻlgani koʻrinadi.

Odatiy xatolar va ularni qanday aniqlash mumkin

• «SQL bajarish» yoki «buyruq bajarish» vositasi. Qanday aniqlash: vositalar roʻyxatini koʻrib chiqing va har biri haqida soʻrang: u orqali ssenariylardan tashqari biror narsa qilish mumkinmi? Ha boʻlsa — tor vositalarga boʻling.
• Administrator hisobi ostidagi server. Qanday aniqlash: shu hisob orqali agentga kerak boʻlmagan soʻrovni bajarib koʻring. Baza ruxsat bersa — huquqlar ortiqcha.
• Faqat promptdagi himoya. Qanday aniqlash: test muhitida agentdan qoidani buzishni soʻrang va shunday iltimosni maʼlumotlarga yashiring. Hech boʻlmasa bir marta ishlasa — kirish darajasida himoya kerak.
• Noaniq vosita tavsiflari. Qanday aniqlash: tavsiflarni kodga kirishi yoʻq hamkasbga bering va qaysi vositani qachon ishlatishni aytishini soʻrang. U adashsa, model ham adashadi.
• Juda katta natijalar. Qanday aniqlash: vosita real maʼlumotlarda nima qaytarishini koʻring. Unda yuzlab maydonlar va ortiqcha shaxsiy maʼlumotlar boʻlsa — javobni kerakli qismgacha qisqartiring.
• Kontekstdagi maxfiy kalitlar. Qanday aniqlash: model bilan yozishmalar loglaridan tokenlar, parollar va kalitlarni qidiring. Ular u yerda boʻlmasligi kerak.
• Qayd etilmagan versiyali begona server. Qanday aniqlash: xost konfiguratsiyasini tekshiring. Agar server oxirgi versiyani avtomatik tortsa, uning tavsiflari sizdan bexabar oʻzgarishi mumkin.
• Tez oʻchirish imkoni yoʻq. Qanday aniqlash: server yoki alohida vositani oʻquv tarzida oʻchirib koʻring va bu necha qadam talab qilishini kuzating.

Ishga tushirishdan oldingi chek-list

1. 01Ssenariylar yozilgan, har bir vositaga kamida bitta ssenariy mos keladi.
2. 02Vositalar oʻqish, qaytariladigan yozish va qaytarib boʻlmaydigan amallarga ajratilgan.
3. 03Serverning minimal huquqli oʻz hisobi bor va u ulardan chiqishga urinish bilan tekshirilgan.
4. 04Imkon boʻlgan joyda agent foydalanuvchi nomidan ishlaydi va faqat uning maʼlumotlarini koʻradi.
5. 05«Istalgan buyruqni bajar» yoki «ixtiyoriy soʻrov» kabi vositalar yoʻq.
6. 06Qaytarib boʻlmaydigan amallar inson tasdigʻini talab qiladi, tasdiqdagi asosiy qiymatlar esa model matnidan emas, tizimdan olinadi.
7. 07Kirish parametrlari serverda sxema va biznes-qoidalar bilan tekshiriladi.
8. 08Maxfiy kalitlar serverda saqlanadi va model kontekstiga hamda vosita natijalariga tushmaydi.
9. 09Vosita natijalari ixcham va ortiqcha shaxsiy maʼlumotlarsiz.
10. 10Har bir chaqiruv foydalanuvchi, parametrlar va natija bilan loglanadi.
11. 11Chaqiruvlar chastotasi va hajmiga limitlar bor.
12. 12Uchinchi tomon serverlari — faqat ishonchli manbadan va qayd etilgan versiya bilan; ularning vositalari koʻrib chiqilgan.
13. 13Maʼlumotlarga yashirilgan koʻrsatmalar bilan dushmanona testlar oʻtkazilgan.
14. 14Serverni yoki alohida vositani tezda oʻchirish imkoni bor.

Atamalar lugʻati

• MCP (Model Context Protocol) — SI ilovalarini vositalar va maʼlumotlarga ulashning ochiq protokoli.
• Xost — foydalanuvchi va model ishlaydigan ilova; ulangan serverlarni boshqaradi.
• Mijoz — bitta server bilan aloqani ushlab turadigan xost komponenti.
• Server — vositalar, resurslar va promptlar orqali muayyan tizimga kirishni ochadigan dastur.
• Vosita (tool) — model oʻz qarori bilan chaqira oladigan amal.
• Resurs (resource) — ilova model kontekstiga qoʻshadigan maʼlumotlar.
• Transport — xabarlarni uzatish usuli: lokal serverlar uchun standart kiritish-chiqarish, masofaviylar uchun HTTP.
• JSON-RPC — MCP dagi almashinuv qurilgan soʻrov va javoblar formati.
• Prompt injection — model oʻqiydigan maʼlumotlarga koʻrsatmalar aralashtiriladigan hujum.
• Jarayondagi inson (human in the loop) — xavfli amal faqat inson tasdigʻidan keyin bajariladigan sxema.

Xulosa

MCP integratsiyalardagi bir xil ishni olib tashlaydi: tizimni bir marta tavsiflash kifoya va undan turli SI ilovalari foydalana oladi. Lekin protokol agentga nima mumkinligini siz uchun hal qilmaydi. Bu chegarani server belgilaydi — vositalar toʻplami, hisob huquqlari, tasdiqlar va loglar orqali.

Amaliy tartib shunday: ssenariylar, tor vositalar, minimal huquqlar, yozishdan oldin oʻqish, qaytarib boʻlmaydigan amallar uchun tasdiq, dushmanona testlar, bosqichma-bosqich kengaytirish. Agent kirishini juda tez, juda ijrochi va baʼzan oʻqigan hamma narsasiga ishonadigan yangi xodimga kirish huquqini loyihalagandek diqqat bilan loyihalang.