ერთი წლის წინ კომპანიის შიდა სისტემების AI-ასისტენტთან დაკავშირება სამეცნიერო პროექტი იყო. დღეს ეს Jira-ს ტიკეტია — Model Context Protocol-მა „მიაერთე AI ჩვენი შეკვეთების ბაზას” custom-ინტეგრაციული სამუშაოდან იმად აქცია, რისი პროტოტიპის აწყობაც საშუალო დონის ინჟინერს ერთ კვირაში შეუძლია. თუ თავად პროტოკოლის ახსნა გჭირდებათ, MCP-ის განმარტება ამ თემას ფარავს.
ეს პოსტი სხვა საუბარია — ის, რომელსაც CTO-ებთან და პლატფორმის ლიდებთან ვმართავ მას შემდეგ, რაც პროტოტიპის დემო კარგად ჩაივლის. რადგან დემო ადვილი ნაწილია, ხოლო კითხვები, რომლებიც მას მოსდევს („ანუ შეგვიძლია ეს გავუშვათ?”), არის არქიტექტურის, უსაფრთხოებისა და ეკონომიკის კითხვები AI-ის კოსტიუმში.
რას ცვლის MCP სინამდვილეში გუნდისთვის?
MCP სტანდარტიზებს AI-სისტემა ინტეგრაციის მილსადენს, რაც რთულ სამუშაოს „როგორ დავაკავშიროთ”-დან „რისი უფლება უნდა ჰქონდეს მას”-ზე გადააქვს. ერთი სერვერი, რომელიც თქვენს issue tracker-ს ამხელს, მუშაობს ყველა MCP-თავსებად კლიენტში, რომელსაც თქვენი გუნდი იყენებს — იგივე ინტეგრაცია, ერთხელ დაწერილი. ეს რეალური ბერკეტია: სტანდარტამდე ყოველი AI-ზედაპირი ყოველი ინტეგრაციის თავიდან აწყობას მოითხოვდა.
რას არ ცვლის: თქვენი შიდა API-ის რეალური კონტრაქტი, ავტორიზაციის მოდელი და მონაცემთა მგრძნობელობა ახალ მილში უცვლელად გადის. MCP სერვერი არის წარმოდგენის ფენა თქვენს სისტემებზე ძალიან პირდაპირად მოაზროვნე მომხმარებლისთვის — თუ ქვემდებარე API ნებისმიერ გამომძახებელს ყველა კლიენტის შეკვეთების წაკითხვის უფლებას აძლევს, MCP სერვერი ამ შესაძლებლობას ახლა AI-სთან ყოველ საუბარს სთავაზობს. პროტოკოლმა კავშირი გახადა სტანდარტული და არა განსჯა.
სად უნდა გადიოდეს უსაფრთხოების საზღვარი?
თავად MCP სერვერში — არასდროს მოდელის კარგი ქცევისთვის მინდობილი. წესი, რომელსაც გუნდებს ვთხოვ: სერვერი ზუსტად იმას აღასრულებს, რისი უფლებაც სესიის უკან მდგომ მომხმარებელს აქვს, თქვენი არსებული ავტორიზაციით (scoped tokens, სტრიქონის დონის უფლებები), ისე, რომ სრულად დაბნეულმა მოდელმაც კი ვერ მოითხოვოს მონაცემები, რომლებზეც ადამიანს ისედაც წვდომა არ ჰქონდა. „მოდელი ჩვეულებრივ სხვა კლიენტების მონაცემებს არ ითხოვს” უსაფრთხოების პოზიცია არ არის; „token-ს სხვა კლიენტების მონაცემების წაკითხვა არ შეუძლია” — არის.
სამი კონკრეტული გადაწყვეტილება იმსახურებს დიზაინის დროს გაშვებამდე. წაკითხვა/ჩაწერის გაყოფა: read-only tools რისკის სხვა კლასია, ვიდრე tools, რომლებიც მდგომარეობას ცვლიან — დაიწყეთ read-only-თ, ჩაწერები დაამატეთ tool-ების მიხედვით ცალ-ცალკე, დამტკიცების ცხადი პროცესებით. Prompt injection-ის რეალობა: ნებისმიერი tool-ის შედეგი, რომელიც მომხმარებლის შექმნილ კონტენტს შეიცავს (ტიკეტის ტექსტი, წერილები, მიმოხილვები), შეიძლება ატარებდეს ინსტრუქციებს, რომლებსაც მოდელი შესაძლოა მიჰყვეს — ამიტომ tool-ების შედეგებს მოეპყარით როგორც არასანდო შენატანს, ზუსტად ისე, როგორც კლასიკურ ვებ-უსაფრთხოებაშია მიღებული. და ლოგირება: ყოველი tool-ის გამოძახება, არგუმენტებით, ადამიანის სესიაზე მიბმული — რადგან „რას შეეხო AI გასულ სამშაბათს” ერთხელაც იკითხავს ვინმე compliance-თანამდებობით, და პასუხი მხრების აჩეჩვა არ უნდა იყოს.
რა ჯდება რეალურად MCP-ის დანერგვა?
სერვერი ბიუჯეტის იაფი ხაზია; მის გარშემო საკონტრაქტო სამუშაო — ნამდვილი ბიუჯეტი. პირველი read-only სერვერის აწყობა კარგად დოკუმენტირებულ შიდა API-ზე მართლაც დღეების საქმეა და არა თვეების — მექანიკა კურსის ფორმატშიც ისწავლება (MCP სერვერების აწყობა ზუსტად ამისთვის არსებობს). ხარჯები, რომლებიც გუნდებს აოცებს: tool-schema-ს დიზაინი (აღწერები იმდენად ზუსტი, რომ მოდელმა სწორი tool სწორი საქმისთვის აირჩიოს — ცუდი აღწერები იძლევა AI-ს, რომელიც თავდაჯერებულად ცდება თქვენსავე სისტემებზე), evals (ტესტების ნაკრები, რომელიც ამტკიცებს, რომ tools რეალისტურ საუბრებში სწორად გამოიყენება და არა უბრალოდ 200-ს აბრუნებს) და მუდმივი ფლობა, რადგან schema-ს ყოველ ცვლილებას ზემო დინებაში ახლა მეორე მომხმარებელი ჰყავს, რომელიც შეიძლება გატყდეს.
თავად runtime-ის ღირებულება აგენტების ეკონომიკას მიჰყვება: tool-ის ყოველი შედეგი მოდელის კონტექსტის ფანჯარაში ხვდება და ფასიანია, ასე რომ სერვერი, რომელიც 200 სტრიქონს აბრუნებს იქ, სადაც 5 იკმარებდა, ჩუმად ამრავლებს თქვენს token-ის გადასახადს. შედეგის ფორმირება — ფილტრაცია, შეჯამება, პაგინაცია სერვერის შიგნით — ერთდროულად ხარისხისა და ღირებულების გადაწყვეტილებაა, და ეს არის ადგილი, სადაც პროდაქშენ LLM-აპლიკაციების დისციპლინა თავს იმართლებს.
საკუთარი ძალებით ავაწყოთ თუ გარედან მოვიწვიოთ ვინმე?
ააწყვეთ in-house, როცა ინტეგრაცია read-only-ია, ქვემდებარე API-ს ცხადი მფლობელი ჰყავს და გყავთ მინიმუმ ერთი ინჟინერი, რომელსაც LLM-ფუნქცია პროდაქშენამდე მიუტანია — პროფილი, რომელმაც იცის, რატომ არის tool-ების აღწერები მზიდი კონსტრუქცია და რისთვის არსებობს eval-ების ნაკრები. ცოდნა გროვდება: პირველი სერვერი გუნდს ასწავლის პატერნებს, რომლებსაც ყოველი შემდეგი სერვერი იყენებს ხელახლა, და ამ ცოდნის ფლობა ჯობია მის ქირაობას.
შემთხვევიდან შემთხვევამდე ხაზი დაახლოებით აქ გადის:
| სიტუაცია | ავაწყოთ in-house | ჯერ მოვიწვიოთ review |
|---|---|---|
| Read-only სერვერი ცხადი მფლობელის მქონე შიდა API-ზე | დიახ — დღეების სამუშაო, და გუნდი პატერნს თავისთვის იტოვებს | არ არის საჭირო |
| თქვენი პირველი ჩაწერისუნარიანი tool | მარტო სარისკოა | დიახ — საზღვრები წნეხის ქვეშ უნდა შემოწმდეს მანამ, სანამ ისინი პროდაქშენის ფაქტებად იქცევიან |
| რეგულირებული, კლიენტის ან ფინანსური მონაცემები | არა | დიახ — ავტორიზაციის მოდელი და injection-ისგან დაცვა გაშვებამდე უნდა იყოს განხილული |
| tool-schema-ს დიზაინი დიდ ზედაპირზე | შესაძლებელია; ელოდეთ იტერაციებს | სასარგებლოა — ბუნდოვანი აღწერები იძლევა AI-ს, რომელიც თავდაჯერებულად ცდება თქვენს სისტემებზე |
| eval-ების ნაკრები tool-ების სწორი გამოყენებისთვის | დიახ, და გრძელვადიანად ფლობა | სურვილისამებრ |
მოიწვიეთ გარე review, როცა ჩაწერებია ჩართული, როცა მონაცემები რეგულირებულია, ან როცა ინტეგრაცია ეხება სისტემებს, რომელთა ჩავარდნაც ძვირია — არა აწყობის აუთსორსისთვის, არამედ იმისთვის, რომ tool-ების საზღვრები, ავტორიზაციის მოდელი და injection-ისგან დაცვა წნეხის ქვეშ შემოწმდეს მანამ, სანამ ისინი პროდაქშენის ფაქტებად იქცევიან. ზუსტად ეს „ჯერ დიზაინ-review” ფორმაა ჩვენი AI ინტეგრაციის კონსალტინგის მომსახურება: სენიორის მეორე აზრი არქიტექტურაზე, სანამ მისი შეცვლა ჯერ კიდევ იაფია, აწყობა კი თქვენს გუნდს რჩება. გულახდილი ევრისტიკა: დემოს ერთი კვირა დასჭირდა, ამიტომ ცდუნებაა დაიჯერო, რომ პროდაქშენი კიდევ ორი კვირაა; გუნდები, რომლებიც ამას სწორად აკეთებენ, დემოდან პროდაქშენამდე უფსკრულს თავად პროექტად ბიუჯეტირებენ — იმავე უფსკრულს, რომლის დასახურადაც context engineering არსებობს.
ერთაბზაციანი ვერსია თქვენი შემდეგი ხელმძღვანელობის შეხვედრისთვის
MCP-მ დაკავშირება იაფი გახადა. მან უსაფრთხო, კორექტული, ეკონომიური დაკავშირება ზუსტად ისეთივე რთული დატოვა, როგორიც ყოველთვის იყო. პროტოკოლი უკვე სტანდარტია; განსჯა — ჯერ არა.
MCP-მ AI-ის შიდა სისტემებთან დაკავშირება იაფი გახადა; მან უსაფრთხო, კორექტული, ეკონომიური დაკავშირება ზუსტად ისეთივე რთული დატოვა, როგორიც ყოველთვის იყო, და ეს სირთულე გადაიტანა tool-ების დიზაინში, ავტორიზაციის საზღვრებში, evals-ში და შედეგების ფორმირებაში. დაიწყეთ read-only-თ, უფლებები სერვერში მომხმარებლის საკუთარი credentials-ით აღასრულეთ, tool-ების შედეგებს არასანდოდ მოეპყარით, ლოგირეთ ყველაფერი და შედეგები ისე ჩამოაყალიბეთ, თითქოს tokens ფული ღირს — რადგან ღირს. პირველი სერვერი in-house ააწყვეთ დაბალრისკიან სისტემაზე; review იყიდეთ მანამ, სანამ პირველი ჩაწერისუნარიანი ან რეგულირებული სერვერი გავა. პროტოკოლი უკვე სტანდარტია. განსჯა — ჯერ არა.
